Anthropic’s Building Effective Agents is the single most important reference document I have read in 2026. Inside the team here, we treat it as a week-to-week input rather than background reading. Not because it told us anything we did not already believe, but because it independently named the shape we had been building.
Anthropic calls the shape ACI. Agent Computer Interface. We call it a capability.
They are the same thing.
The interesting story is not “look, two people agree.” The interesting story is that two teams started from opposite ends of the problem — Anthropic working downward from agent design principles, Naftiko working upward from enterprise capability inventory — and arrived at the same set of design constraints. That kind of convergence is worth a public post.
What Anthropic actually says about ACI
The core argument in Building Effective Agents is that the surface a system exposes to an agent is the variable that determines whether the agent works. Not the model, not the prompt, not the orchestrator. The surface.
Anthropic frames the ACI as having several properties any agent-facing system should have:
- The right level of abstraction. Not a thin wrapper over the raw API, not a high-level “do my whole job” macro. A unit the agent can reason about end-to-end.
- Predictable inputs and outputs. Typed, named, and shaped for an agent rather than a frontend engineer.
- Deterministic surfaces. The agent should be able to predict what the call will do before it makes it, and what state will exist after.
- Observable side effects. When the agent takes action, the agent (and the human operator above the agent) should be able to see what changed.
- Documentation that doubles as the prompt. The description of the tool is the prompt the model uses to decide whether to call it.
Read those five bullets again with capability spec authors in mind. That is the entire argument we have been making about why an “MCP server is a wrapper over a REST API” is the wrong design.
What Naftiko has been building
A Naftiko capability is a YAML description of one named, typed, governable unit of work. Two halves:
- A
consumesblock — the upstream HTTP operation, message, file, or sub-capability the work actually rides on. - An
exposesblock — the MCP tool, REST endpoint, or skill the agent (or human, or composing capability) actually sees.
The two halves are deliberately separable. The consumes block is the wire. The exposes block is the contract. The two compose through a small, declarative middle that handles parameter mapping, output shaping, governance enforcement, and observability emission.
That is the same shape Anthropic is describing. Different name. Same constraints.
The side-by-side
| Anthropic ACI principle | Naftiko capability spec |
|---|---|
| The right level of abstraction for the agent | The exposes block describes the agent surface; the consumes block describes the wire underneath. They are designed independently and bound through the spec. |
| Predictable, typed inputs and outputs | Every exposes operation has typed inputs and named, shaped outputs declared in the YAML — not inherited from the upstream API’s accident-of-history schema. |
| Deterministic surfaces | A capability either fires or it does not. The Control Port logs the decision. Scripting (Python / JS / Groovy) is sandboxed and governed. No silent retries, no hidden fan-out. |
| Observable side effects | OpenTelemetry tracing, RED metrics, and audit events all flow through the Control Port out of the box. The agent’s caller, the human above the agent, and the auditor above the human all see the same event stream. |
| Documentation that doubles as the prompt | The capability YAML is the MCP tool description. The thing you write to specify the system is the thing the model reads to decide whether to use it. There is no second, drifting documentation surface to maintain. |
Five principles. One spec. Two teams arrived independently.
Why the convergence matters
Anthropic is talking to model builders and the people designing agents on top of model APIs. They are arguing that if the surface is wrong, no amount of model improvement fixes it. The surface is the design lever.
Naftiko is talking to enterprise platform teams and the people inventorying API and integration capability across F500 organizations. We are arguing that if the capability is wrong, no amount of gateway or registry investment fixes it. The capability is the design lever.
Same argument. Different audiences. Both rooted in the same observation: the unit you give an agent to work with has to be a real unit — typed, scoped, observable, governable, documented — or the rest of the stack cannot save you.
That convergence is what makes Building Effective Agents the right Q2 reference for what we do. Not because Anthropic validated us. Because we both independently identified the constraint that matters.
What this does not mean
There is some genuine confusion in the market about how MCP, ACI, and capabilities relate. The clarification:
- MCP is the wire protocol. It is how a tool surface gets reached. The shape of the bytes on the network.
- ACI is the interface contract. It is what a good tool surface looks like, regardless of how it is reached. The shape of the agreement.
- A capability is the unit of work. It is what gets exposed through an ACI-shaped interface, transported over MCP (or REST, or whatever).
These are three layers, not three competing claims. You can build an MCP server that ignores ACI principles entirely — most current MCP servers do, because they are auto-generated wrappers over existing REST endpoints. You can build an ACI-shaped tool surface and transport it over something other than MCP — REST, SKILL, gRPC, whatever fits. You can describe a capability without committing to either yet — that is what the Naftiko spec does, deliberately, so the same capability can expose itself across MCP and REST and SKILL adapters from one YAML.
The layering matters because when people ask “how is Naftiko different from MCP?” the honest answer is that the question is shaped wrong. MCP is the wire. We are the unit of work. We use MCP. We also use REST. We will use whatever the agent transports of 2027 turn out to be, because the capability is the durable thing and the wire is the disposable thing.
What to do with this
If you are building agents and you have been bumping into the limits of tool-per-endpoint, read Building Effective Agents. The ACI section will tell you what good looks like.
If you are building the system the agents call into and you have been bumping into the limits of “wrap the REST API and call it an MCP server,” read the Naftiko Framework wiki. The capability spec will tell you what good looks like.
If you read both back-to-back, you will notice the same five principles showing up in different vocabularies — because two independent groups working on the same problem from opposite ends arrived at the same answer. That is rare in this space and worth paying attention to.
The wire is the easy part. The unit of work is the design problem. Anthropic and Naftiko are saying that, in different words, at the same time.
