Agent infrastructure
API strategy
The backend for frontend pattern doesn't fit agents. Why BFF vs API gateway is the wrong debate, and what the tools layer actually needs to do differently.
The backend for frontend pattern solved a real problem: mobile apps, web apps, and partner surfaces all needed different views of the same data, and forcing one API to serve all of them produced compromises nobody liked. So teams built a BFF per client. Each frontend got a backend tuned to its shape. The pattern worked. It's still working. But when teams reach for it to serve agents, they're solving yesterday's problem with yesterday's tool.
We've watched this play out in enough agent projects to say it plainly: a BFF for agents isn't a smaller problem than a BFF for mobile. It's a different problem. And treating it like the same one is why agent projects that started with "we'll just add a BFF" end up rebuilding the layer six months later.
Sam Newman formalized the backend for frontend pattern around 2015 in a widely-cited article, describing how SoundCloud engineers — where ex-SoundClouder Phil Calçado had coined the term — split a shared API into per-client backends. The problem was clear. A mobile client wants small payloads, fewer round trips, and a UI-shaped response. A web client can handle bigger payloads and more calls. A partner API wants stability and versioning. Serving all three from one general-purpose API meant every client got a compromise.
The BFF pattern fixed that by giving each client its own backend. Each BFF knew its client. It aggregated downstream services, shaped responses, and hid complexity the frontend didn't need. It was owned by the frontend team, deployed with the frontend, and versioned with the frontend.
That's the part worth remembering. A BFF is defined by its client. The client's shape, its update cycle, its rendering constraints — all of that lives in the BFF. Change the client and the BFF changes with it.
Here's where the pattern gets misapplied. Teams building agents look at their existing BFFs — mobile BFF, web BFF, partner BFF — and reason: agents are a new client, so we need an agent BFF. Shape the responses for the model. Aggregate the calls the agent would otherwise chain. Done.
It doesn't hold up. Three reasons.
First, a BFF is designed for a known client with a stable shape. Mobile screens don't change between requests. The agent's "shape" changes every turn. What it needs from your product depends on the user's prompt, the tools already selected, the state of the conversation, and the model's plan. There is no stable UI to back. The whole premise of the pattern — one client, one backend — assumes something agents don't offer.
Second, BFFs collapse calls to reduce latency and simplify rendering. Agents do the opposite. An agent decomposes work into discrete tool calls specifically so it can reason about each result, retry the ones that fail, and chain the next call on what the last one returned. If you pre-aggregate the way a BFF does, you flatten the very structure the agent needs to reason over. You save a round trip and destroy the model's ability to plan.
Third, and this is the one that gets missed: BFFs authenticate as the client, then act on behalf of the user. Agents need to authenticate as the user, not the agent process. The delegated-auth boundary is fundamental to how agent identity works in production, and BFFs weren't built to hold it. Retrofitting per-user delegation into an existing BFF is not a small change.
Where does that leave the diagram? The comparison worth drawing isn't BFF vs API gateway. It's what each layer actually does when an agent is the caller.
An API gateway is not a BFF replacement, and neither is a fit for agents. Gateways front the APIs you already have; they don't generate the tool surface agents actually invoke. BFFs shape data for a specific UI; agents don't have one.
The layer agents need is something else. It exposes product capabilities as discrete tools, executes them under the user's identity, and stays current as the underlying product changes. That's a different job description than either pattern the industry already has a name for.
One argument we hear: fine, an agent BFF isn't the same as a mobile BFF, but the pattern still helps. Put a thin layer in front of the product APIs. Adapt payloads. Handle auth translation. Call it a BFF for agents and move on.
The layer isn't wrong. The name is. Calling it a BFF invites the mobile BFF's assumptions: owned by the frontend team, versioned with the client, updated when the UI changes. None of those apply. An agent-facing layer has to version with the product, not the client. It has to survive the fact that there is no single client to version with. And it has to compose tools the model can reason over — not aggregate calls the model can't unpack.
When we've seen teams build "an agent BFF" the right way, they end up describing something that looks nothing like a BFF. Discrete tool definitions. Per-user auth at runtime. Automated regeneration when the underlying product changes. At that point, keeping the BFF label is a naming convenience that hides an architectural difference.
Name the layer for what it is. Otherwise, the next engineer to touch it inherits the wrong mental model, and the fixes they make will be shaped by the wrong pattern.
The reason this matters commercially: teams that treat the agent-facing layer as "just another BFF" end up rebuilding it. The rebuild is where the cost of connector maintenance starts showing up on someone's roadmap.
Pontil is a Tools-as-a-Service platform. We generate the tools layer from the product's existing codebase, run those tools under the authenticated user's identity, and keep them current as the product changes. It's not a BFF and we don't sell it as one — the naming discipline matters here for the same reason it matters in the article above. The layer agents need has a different job. Treating it that way from the start is cheaper than discovering it the hard way.
If you're staring at a mobile BFF, a web BFF, and a growing agent project, don't add a third BFF to the stack. Ask a different question: what capabilities does the product expose, and how do agents reach them under the user's identity, at the granularity a model can plan over? The answer isn't a client-specific backend. It's a tools layer that versions with the product, holds delegated auth at runtime, and stays current without a rewrite cycle every quarter. Name it that way, staff it that way, and the pattern that broke the project stops being the one you keep reaching for.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
