Applied Capabilities: The BFF Pattern for Context Engineering

Sam Newman wrote up Backends For Frontends in November 2015, crediting Phil Calçado and the teams at SoundCloud and REA. The diagnosis was a general-purpose API backend serving every client at once, and the symptom was that it served none of them well:

“The nature of a mobile experience often differs drastically from a desktop web experience… We have less screen real estate, which means we can display less data. Opening lots of connections to server-side resources can drain battery life and limited data plans.”

The fix was not a better general-purpose API. It was to stop having a single shared backend at all: each user experience gets its own, owned by the team that owns that experience. Stewart Gleadow’s guideline is the one everyone remembers: one experience, one BFF.

Eleven years later Gartner reached for the same pattern for a consumer nobody had in 2015. In How to Enable Agentic AI via API-Based Integration (10 January 2026; paywalled):

“Builders should scope AI agents to narrow domains to reduce reasoning complexity, implement careful tool selection to minimize redundancy, and deploy agent-specific-scoped MCP servers following a back end for frontend (BFF) pattern to ensure AI agents receive only the necessary tool metadata and secure access required for their task.”

Four instructions in one clause: narrow the domain, select the tools, scope the server to this agent, and let it carry the credential. Every one is a design-time decision about what an agent is allowed to see.

Why the pattern transfers

Patterns transfer when constraints transfer, and here they map line for line.

A vendor MCP server is a general-purpose backend. It is scoped to a product — right for the vendor, wrong for your agent, because the unit of match is the use case, not the API. Stripe’s MCP server publishes around 25 tools; its OpenAPI document publishes 300-plus operations. Both are honest descriptions of Stripe. Neither describes what a payments-ops team handling renewals and dispute triage needs.

The numbers make it concrete. Those 25 vendor tools cost 5,000–8,000 tokens of catalog before the user’s question is appended. Pointed at the raw OpenAPI document, the same agent faces 150,000–300,000+ tokens — more than most models’ usable context. A curated surface exposing two task-shaped tools lands at 400–800 tokens.

And the saving is not only financial. Tool-selection accuracy degrades quickly past a few dozen descriptions — the model spends attention on near-duplicates, hallucinates parameter names, and routes through operations it never needed. Context reduction is a quality lever before it is a cost lever. Gartner’s “reduce reasoning complexity” names the same effect from the model’s side.

What changes when the frontend is an agent

The consumer cannot tell you it is confused. A mobile developer facing a bad API reads the docs or files a ticket. An agent silently picks the wrong tool and bills you for the attempt; you find out from a trace and an invoice. That raises the bar on the contract: typed parameters, descriptions that survive being read out of context, and explicit behaviour — safe, idempotent, cacheable? A human never needed those written down.

Shaping the response is not optional. In 2015, forwarding an over-large payload cost bandwidth once. Forwarding a vendor’s 60-field Subscription object to an agent costs tokens on every turn, forever, and each unnecessary field is another thing the model can latch onto.

The credential travels with the surface. Gartner’s phrase is “only the necessary tool metadata and secure access required for their task.” If the surface exposes four operations, the credential behind it should authorize four operations — and a reviewer should establish that by reading the artifact, not by watching production.

Two tiers, not one facade

Gartner also offers a second framing — “back end for agent” facades — and this is where we part company on vocabulary, deliberately.

A new acronym implies a new deployable: a service per agent, written in code. That reproduces the failure mode Newman himself flagged — duplicated aggregation logic across facades, each a container of glue code. It also reproduces the thing that makes agent deployments stall: you cannot enumerate, by reading general-purpose code, the complete set of upstream operations a credential will ever authorize. Computed URLs, branching and dynamic dispatch defeat static analysis. You end up certifying one observed run rather than the artifact.

So the noun we use is capability — the word platform engineering picked for the fulfilment slot of a path, and the word business architects have used since 2006 for a black box that declares what it does rather than how. Not a facade to be built, but a file to be written. And it comes in two tiers, which is what the BFF pattern never had a name for.

A source capability faces a system. It consumes one upstream — the homegrown CRM, the claims engine, the SaaS with a good HTTP API and no MCP server — and projects a faithful surface over it: thin domain logic, strong upstream governance. The team that owns the system publishes it once, because they know its quirks, auth and rate limits. The point is reach.

An applied capability faces a task. It draws on several upstreams — source capabilities you originated, vendor MCP servers, raw APIs — and fuses them into the handful of task-shaped tools one agent needs, with policy and sequencing applied. The point is fit.

That distinction is what the BFF pattern was missing, and it is why Newman’s duplication problem was hard. He offered two uncomfortable options: extract a shared library, or push aggregation into a downstream service. Both are couplings you then own. The two-tier split answers it structurally: the plumbing lives in the source capability, once, and the applied capability references it — from, import and as reuse another file’s consumes, aggregates or exposes block by name.

It also splits the work the way organisations are shaped. The platform team ships source capabilities on their own cadence; the team that owns an agent assembles an applied capability from whatever exists. Neither blocks the other — precisely the autonomy argument Newman made for putting the BFF under the client team’s ownership, except that here it does not cost you a duplicated codebase. And because both tiers are the same kind of file, one review path, one linter and one engine upgrade covers both.

Here is what the applied tier looks like:

ikanos: "1.0.0-beta5"

binds:
  - namespace: stripe-env
    location: "vault://secret/billing"
    keys:
      STRIPE_TOKEN: "stripe-restricted-key"   # never inline

capability:
  consumes:
    - import: stripe
      from: ./shared/stripe.yml    # the source capability, owned elsewhere
      # every upstream operation this credential will ever reach
      # is enumerated there, and nowhere else

  aggregates:
    - display: "Billing Ops"
      namespace: billing-ops
      flows:
        assess-subscription:
          description: "Renewal brief for one customer"
          semantics:
            safe: true
            idempotent: true
            cacheable: true
          inputParameters:
            customer-id:
              type: string
              required: true
          steps:                       # sequenced server-side,
            get-subscription:          # off the model's critical path
              type: call
              call: stripe.list-subscriptions
              with:
                customer: ""
            get-disputes:
              type: call
              call: stripe.list-disputes
          mappings:                    # the shape the task needs,
            - target: renewal-date     # not the vendor's 60-field record
              value: "$.get-subscription.current_period_end"
            - target: open-disputes
              value: "$.get-disputes.data.length"

  exposes:
    - type: mcp                        # the agent's surface
      port: 3001
      namespace: billing-copilot
      tools:
        assess-subscription:
          description: "Assess a customer's subscription before a renewal call"
          ref: billing-ops.assess-subscription

    - type: rest                       # the same flow, for the portal
      port: 3003
      namespace: billing-api
      resources:
        subscriptions:
          path: "/subscriptions"
          operations:
            assess-subscription:
              method: GET
              inputParameters:
                customer-id:
                  in: path
                  type: string
              ref: billing-ops.assess-subscription

Four properties fall out of writing it down rather than coding it up:

• The surface is enumerable. Follow the import and consumes is the complete list of upstream operations. A reviewer can establish what a credential authorizes before it is bound.
• The shaping is reviewable. Curation happens in a diff, in a pull request — not inside an inference on every turn, and not inside a container nobody reads.
• One artifact serves every consumer. The same aggregates project to MCP for the agent and REST for the portal. The duplication BFFs accepted was never in the logic — it was in the transport, and a projection removes it.
• Deploying it is not building a service. The transaction cost Newman worried about — “I might reconsider if the cost of deploying additional services is high” — is what decides whether you get one surface per agent or one shared surface for all of them. A file is cheap enough to have the strict version.

One experience, one BFF was always right and often lost to deployment cost. If the unit is a declared file that a linter checks and a catalog tracks, one task, one applied capability is affordable in a way one experience, one service never quite was.

Composition is where the round-trips go

There is a second half to Newman’s piece that gets quoted less, and it matters most for agents:

“For organisations using a large number of services… it will be common for a single call in to a BFF to result in multiple downstream calls to microservices.”

Substitute model round-trip for network call and the economics get sharper. Three upstream calls composed inside the surface is one exchange with the model. Three tools exposed separately is three exchanges, three sets of intermediate JSON dragged through the context window, and three chances for the model to drop a correlation identifier.

So “rightsize the toolset” and “compose server-side” are the same instruction from two angles. You cannot get from 25 tools to 2 by deletion alone — the work the other 23 did has to go somewhere. It goes into the aggregate, where it runs deterministically, in parallel where the data flow allows, under a declared timeout.

Newman’s failure-mode question transfers too. He asked whether a BFF should fail the whole response when only the inventory service is down, or degrade gracefully. For an agent the question is sharper, because a partial response the caller cannot interpret is worse than an error: the model will confidently reason over the gap. Declare what a partial result looks like, or return the failure.

What this does not solve

It is a warm path. An applied capability requires knowing the task shape in advance. When an agent hits something nobody anticipated, it needs the broad catalog — and then the right move is to capture what it did and turn it into one, so the expensive route runs once per task type rather than once per request. Curation and discovery are not rivals; discovery is how you find out which applied capability to write next.

Narrow scope has a cost. Scoping agents to narrow domains means more applied capabilities to own — the same trade the BFF pattern made in 2015. It only pays if each artifact is cheap to author, review and retire, which is the argument for the source tier doing the heavy lifting once.

The takeaway

• The pattern is not new; the consumer is. A vendor MCP server is a general-purpose backend, and an agent is a mismatched client with a tighter budget than any phone ever had.
• The constraints map cleanly. Screen size becomes context window. Battery and data plan become tokens per turn. Chatty downstream calls become model round-trips.
• Gartner is describing design-time work. Narrow the domain, select the tools, scope the server, scope the credential — none of that is something a protocol does for you.
• Say capability, not a new acronym — and say which tier. A source capability faces a system; an applied capability faces one agent’s task. Both are the same kind of file, so one review path covers both.
• The two tiers answer Newman’s duplication problem. Declaring the plumbing once and importing it is neither a shared library nor a downstream service.
• Composition is the other half. Rightsizing to two tools only works if the work the other twenty-three did moves server-side.
• One task, one applied capability. Make the unit a file and the strict version becomes the cheap version.

Newman’s conclusion still holds, with one word swapped:

“The simple act of limiting the number of consumers they support makes them much easier to work with and change.”

Limit the number of tools an agent sees and you get the same result, for the same reason. Then write it down, so somebody can check.

Further reading

• 🧱 Pattern: Backends For Frontends — Sam Newman, November 2015
• 📊 How to Enable Agentic AI via API-Based Integration — Gartner, 10 January 2026 (paywalled)
• 🧩 Agents undid twenty years of API curation. Put it back with capabilities.
• 🏗️ Platform engineering and context engineering converge on the same unit
• 🔍 Dynamic tool discovery and the limits of finding the right tool
• 🎙️ Voice assistants and the 200-tool bottleneck
• 🎓 Track 1 — context engineering, hands on · ⚙️ Ikanos