From Data and APIs to Capabilities: The Abstraction the Agentic Era Is Settling On

wpnews.pro

There is a test a technical word has to pass before it becomes a business word: a CFO has to be able to say it in a sentence without being corrected.

Data passes. Chief Data Officers exist, data strategy is a board topic, and nobody in that room is asked whether they mean a row, a column, or a Parquet file. It carries a precise technical meaning and a legible business one, and the two do not fight.

API never quite passed. Twenty-five years in, it is still an acronym expanding to Application Programming Interface — three technical words, one of which is programming. Executives learned to say “our API strategy,” but the word stayed the engineers’. It names a mechanism, not an outcome.

Capability is passing right now. The interesting part is not that we think so. It is the three very different roads the agreement travelled to get here.

Road one: API design strategy named the unit #

The temptation is to say capabilities are an AI idea. They are not, and the dates matter.

In June 2023 — before MCP existed, before anyone was seriously designing for agents — Bruno Pedro asked what the unit of value in an API marketplace actually is:

“I believe the unit of value in APIs is a single capability and not the whole API… Consumers want the capabilities provided by the APIs, not the APIs themselves.”

He noticed something that reads differently now: every consumer platform had already invented its own word for the same object. Google and Apple called them Actions, Amazon Skills, ChatGPT Plugins. Four vendors, four words, one unit — and nobody was designing for agents. They were designing for consumers who wanted to do a thing, and the API was in the way.

The thread continued before agents were the reason, then accelerated once they were — with people citing each other throughout:

February 2024—Kin Lane, profiling Twilio and Stripe, sorted APIs into three tiers:resources,** capabilities**,** experiences**. Most are still*“Create, Read, Update, and Delete”; capabilities are“the buffet of API operations that empower you to do more than just CRUD.”AI appears once, as the last item in a list of consumers.April 2025—Christian Posta:“Agents don’t start with an API spec. They start with a goal and some context.”*Systems must therefore expose “a self-describing, semantically rich declaration of what a system can do, not just how to invoke it.”July 2025—Mike Amundsenpicked up Posta directly: autonomous clients “don’t just follow instructions, they observe, infer, and choose,” so an API “needs to be a menu of possibilities” rather than a list of endpoints.September 2025—Daniel Kocotcited both and turned it into method.Capability ThinkingreplacesPOST /refunds

withProcess Refund, and the API catalog with a** capability catalog**.** October 2025**—Kin Lane again, having writtenAPI capabilitysince at least 2024, dropped the first word:“I am trying to be honest about the fact that an emphasis on the API might have been holding us back.”

So within the API community this is not independent discovery. It is a documented, cross-referenced conversation between people who read each other — a weaker claim than “they all arrived separately,” and a stronger signal, because a consensus you can trace is more durable than a coincidence.

Where we sit, stated plainly. Naftiko was founded in mid-2025, between Posta’s post and Amundsen’s, on precisely this bet: that the capability, not the API, is the unit worth building a company on. We are participants in this convergence, not neutral observers of it. Every date above is checkable, and the argument should stand on those sources rather than on who is making it.

Road two: Context engineers put the word in the wire format #

The second road did not run through any of those blogs. While that conversation was happening, the people building agent plumbing reached for the same noun and made it structural. The Model Context Protocol specification describes what MCP is for — “expose tools and capabilities to AI systems” — and defines one of its three roles as

“Servers: services that provide context and capabilities.” The word is not describing the protocol from outside; it is a field inside it.

And it has just been promoted: the 2026-07-28 revision drops the old session-opening handshake and makes a clientCapabilities

declaration a required field on every single request. When a protocol moves a concept from an opening greeting to a mandatory field on every message, it is saying the concept is not a formality but the thing the exchange is about.

In December 2025, MCP was donated to the Agentic AI Foundation — a Linux Foundation initiative co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. The vocabulary is now neutral governed infrastructure, not one vendor’s format.

The word is in the protocol, but one level down

Now look at what actually gets declared in that field: elicitation

, sampling

, tools

, resources

— protocol features, not business outcomes. MCP’s clientCapabilities

answers “which parts of this protocol do you speak?”, not “what can this system do for a customer?” No CFO reads that field and learns anything about the business.

The spec itself slips between the two senses. Its security section warns that “the Model Context Protocol enables powerful capabilities through arbitrary data access and code execution paths” — that is the ordinary English meaning, the one a CFO would recognise, sitting a few pages from the strict protocol-feature sense in _meta

. Both are correct. They are simply not the same word doing the same job, and the gap between them is where the engineering lives.

So on this road the word arrives one level below where Pedro and Kocot put it. Underneath sits the HTTP API you already run, a set of operations. Above sits the agent, which needs an outcome — a Process Refund, in Kocot’s terms. MCP gives you a transport and a tool list, and leaves the elevation between them as an exercise for the implementer, which is where the wave of thin wrappers comes from. Skip it and the tool list is just the endpoint list wearing a new protocol, exactly how 38 OpenAPIs become 104 MCP tools.

This is the gap Ikanos exists to close — our open source capability engine, named for the Greek ικανός, capable. It began life as the Naftiko Framework, first released in March 2026, and took the name Ikanos on 7 May 2026: if the unit is the capability, the engine should be called after it.

One declarative file sits between the two levels. It consumes the HTTP operations — declaring every upstream call and credential binding, so the surface is inspectable before it runs — and exposes one business-shaped capability, projected to MCP for agents, REST for partners, or a Skill for onboarding. The elevation stops being implicit in glue code and becomes an artifact you review in a pull request.

The unit	Who reads it
HTTP API, consumed
Operation — `POST /refunds`
The developer who wrote it
Capability, declared
Outcome — Process Refund
Both sides of the room
MCP, exposed
Protocol feature — `tools` , `resources`
The agent runtime

A black box with its interface written down. The word in the middle row is the one the CFO can say.

Road three: Platform engineers made it the unit of the internal platform #

The third road is the one most likely to be already running inside your company — and though it comes third in this telling, by date it reached the word first.

In March 2023, three months before Pedro’s post and two years before MCP, the CNCF’s TAG App Delivery published version 1 of the Platforms White Paper. Its definition:

“A platform for cloud-native computing is an

integrated collection of capabilitiesdefined and presented according to the needs of the platform’s users.”

Not services, or APIs, or tools. Capabilities. The closing section is titled Capabilities of platforms, and the word recurs throughout as the thing a platform team curates, governs and presents — written by and for people provisioning databases and pipelines. Nobody involved was thinking about agents.

To be precise: the CNCF was naming the composition unit of an internal platform, not the consumption unit of an API — that is Pedro’s contribution, and it is genuinely his. But the noun was load-bearing in a foundation white paper before the API conversation started, which makes it harder to argue the industry reached for it because of AI.

Three years on, Thinking in Platforms makes the unit explicit. Kaspar von Grünberg — who coined the term Internal Developer Platform — and Luca Galante define the molecular unit of a platform as a path with four slots:

“A user turns up with a single intent and the path serves it end to end. The input is the ask itself… The interface is where the ask goes in, a portal, a CLI, a pull request etc.

The capability is what actually fulfills it.The output is the database that gets handed back.”

Input, interface, capability, output. Note which slot got the word: not service, not endpoint, but the fulfilment slot — the one answering “what actually does the thing.” Same instinct behind Kocot naming a capability Process Refund, reached from an entirely different starting position — and, as the next section shows, behind a naming convention that is twenty years old.

This road also carries something the other two lack: a decade of practice at writing the contract down. Kubernetes manifests declare desired state, Terraform declares infrastructure, Argo and Flux reconcile a repository against a cluster. As we worked through last week, the open question is therefore not declarative versus code but what gets declared — a manifest describes a workload at rest, while a capability has to describe an interaction: which upstream operations it can invoke, what a bound credential authorizes, and what comes back.

Three disciplines, three problems, one noun.API strategists reasoned their way to the capability as the unit ofdesign. Context engineers made it the unit ofruntime negotiation. Platform engineers made it the unit offulfilment and governance— and had it in a foundation white paper before either of the others published. None of the three needed the others to be right.

The roots are older than all three roads #

What stops this being a 2025 fashion: several disciplines have been modelling capabilities for twenty years. Agents did not invent these boundaries. They inherited them.

Tradition	The unit	Originally for
Business capability modeling (

Business capability	Model what a business function does, versus how it does it
LLMs reason at business intent, so capability maps stop being static PDF diagrams and become machine-readable catalogs
Domain-Driven Design
Bounded context	Stop designing systems as collections of data services	The boundaries that stopped CRUD sprawl produce the token-efficient actions agents select from most reliably
Gartner’s composable enterprise (Dec 2019)
Packaged Business Capability	Bundle data, logic and services into one outcome-shaped block for human teams	A PBC boundary — Process Return, Verify Fraud Risk — is already the right shape for an MCP server to expose
Voice and app ecosystems
Action, Skill, Plugin	Give a non-technical consumer one thing they can do
The first mass-market proof that consumers want the job, not the API

The oldest entry rewards a close read. In February 2006, Ulrich Homann published A Business-Oriented Foundation for Service Orientation — the definition later adopted by the Business Architecture Guild, the OMG’s Business Architecture SIG, and the Business Architecture Institute. Read it against everything above:

“A capability models

whata business function does — its externally visible behavior (versus howit does it, its internal behavior)…Pay EmployeesandShip Productare examples of capabilities… The capability is essentially ablack box.”

What-not-how. Externally visible behaviour. A black box with a declared contract. One of his section headings is literally Capabilities Expose Interfaces. And note the naming convention: Pay Employees in 2006, Gartner’s ** Process Return** in 2019, Kocot’s

in 2025 — verb-plus-noun, business-legible, twenty years apart without coordination.

Process RefundHomann even names the tension context engineering rediscovered: a capability must be “sufficiently descriptive to understand how a function fits in the business… yet summarize enough to provide the stability required.” That is right-sizing, written two decades before anyone was counting tokens.

Each tradition drew a boundary for a human reason, and that boundary turns out to be correct for a machine consumer too. Homann argued that capabilities “remain stable while the processes, or business implementations, change” — precisely why they survived into an era he was not writing for. Gartner’s PBC, in the December 2019 note that coined the term, is the same idea packaged for assembly: an “encapsulated software component that represents a well-defined business capability, recognizable as such by a business user and packaged for programmatic access.” That is the CFO test and the machine-readable contract, in one sentence, six years early. DDD’s bounded contexts were drawn to keep a domain model coherent; the coherence is what makes the resulting action describable in a sentence a model can act on. Nobody redrew these lines for AI. AI arrived and found them already drawn.

Amundsen quotes Irakli Nadareishvili on the through-line: “The first step in breaking the data-centric habit is to stop designing systems as a collection of data services, and instead design for business capabilities.” Aimed at microservices architects; applies unmodified to anyone pointing an agent at an API today. Homann’s own reason for writing was to stop service orientation repeating the architectural mistakes of the past — SOA was technically correct and semantically empty without a business foundation. Twenty years on, “wrap the API in an MCP server” is the same move in a new protocol: correct on the wire, silent about what the system can actually do.

So business architects, API strategists, platform engineers and AI engineers have ended up using the same word for the same object. Vocabulary usually fragments as it crosses disciplines; here it converged.

The practical consequence: if you maintain a business capability map, have invested in DDD boundaries, or bought into composable PBCs, you are not starting from zero on agent readiness — you are holding a draft. What those artifacts lack is not the right decomposition; it is a machine-readable contract and a governed runtime. A much smaller gap than it looks, and a far better starting position than an OpenAPI document with three hundred endpoints in it.

Why data is the right parallel, and API the cautionary one #

The move from data and APIs to capabilities is not a ladder of increasing sophistication. It is a repeating pattern about what gets exposed when a new consumer shows up.

|---|---|---|---|
New consumer |

Look at the last row. A first-wave API failure was silent — you published endpoints, nobody built anything, and the cost was an opportunity you never saw. An agentic failure is loud and expensive: agents do call your API, they call it wrongly, they retry, and the bill lands on your rate limits and your customer’s token spend at once. That is why the word matters commercially rather than just editorially.

What SaaS businesses did last time, and have to do again #

In the 2010s, adding a REST API was not an engineering decision. It was a business development decision — it let partners embed your product, let customers extend it, raised switching costs, and turned a product into a platform. The artifacts became standard: an OpenAPI document, a developer portal, SDKs, an API key, a sandbox, a partner program.

The second wave is the same commercial logic aimed at a consumer that cannot read your documentation.

SaaS businesses added APIs to accelerate business development and ecosystem integration. They are under the same pressure a second time — to become capabilities that agents can discover, understand, and use.

Being callable is becoming a distribution requirement in exactly the way being integrable was a decade ago. If an agent cannot use your product, your product is invisible to the fastest-growing category of software consumers. Not deprioritized — invisible.

Most vendors’ current answer is “we shipped an MCP server for our API.” Right instinct, insufficient answer, for a reason we worked through in detail: a projection that faithfully mirrors an API inherits the API’s size and shape. A vendor with 300 endpoints who publishes 300 tools has reproduced the connector-catalog problem inside their own product, and inflicted it on their own customers — who now pay tool-selection cost, oversized payloads, and retries, metered against that vendor’s own rate limits.

Kocot names the failure mode a busy product team will walk into: “The biggest risk is treating Capability Thinking as a relabelling exercise. Renaming ‘Customer Table API’ as ‘Customer Management Capability’ without abstraction adds no value.”

The portal splits — it does not disappear #

Kocot has a second question that makes this actionable: when the consumer is an agent, is a developer portal still a portal?

If an agent logs into a portal, browses a catalog, reads documentation written for a person, copies a credential out of a settings page, and improvises an integration from what it inferred — you have automated the human workflow rather than rethought it. Every step exists to make an API comprehensible to a human; none to make it reliable for a machine. Take each function and ask what it becomes. The functions survive; the interface does not.

Portal function, for a human	What it must become, for an agent
Catalog and search
Machine-readable discovery of capabilities, with semantics attached to the task, not the resource
Documentation
The contract itself: typed operations, declared inputs, outputs, errors, side effects
Access request
A scoped grant against a declared surface, issued to an identity
Credentials
An injected binding the agent never handles
Try-it console
A safe execution target the agent can exercise before it is trusted
Rate limits and plans
Declared budgets, quotas, and attribution enforced at the boundary
Changelog
A diffable contract that surfaces breakage before it ships

Read down the right-hand column. That is not a portal with better markup. It is a capability surface.

The human-facing portal stays, because humans still evaluate, buy, and debug. Alongside it, the provider now owes the agent consumer a second, machine-native surface — a governed capability, not a rendered page.

Keep your portal for the humans. Publish capabilities for the agents.

Who is best placed to write them #

The API era never had to answer this, because there was only one author.

The provider knows the API’s real semantics, its undocumented behaviour, the safe defaults, which operations are dangerous, and — critically — which handful of jobs customers actually hire the product to do. That last one is the most valuable input to a right-sized capability, and it is exactly what a portal’s tutorials encode and an OpenAPI document does not. The consuming enterprise knows the other half: the task, the tenant, the policy, the identity, and which subset is in scope.

Both are right, and you need not choose — provided the unit is a declarative artifact. A vendor-published capability is a first-party starting point a consuming team can narrow under its own governance without forking. A pre-built connector cannot do that, because the consumer cannot reshape it. Neither can an integration synthesized at runtime, because there is no artifact to start from.

And because the capability is a spec, one authored artifact serves every consumer and stays diffable when the API changes. A vendor hand-writing an MCP server alongside a REST API is maintaining two surfaces that will drift.

Say it in plain words #

One last thing, and it is why this is a post rather than a spec update.

We spent real time this month debating what to call the layer between an agent and the systems it reaches. We had a coinage — an acronym, three letters, the usual. Every replacement we tested collided with something already in this market: a frontier lab’s term, a major vendor’s iPaaS, a hyperscaler’s messaging service. Three candidates, three collisions, and a pattern worth naming:

The acronym was never carrying weight. It was only ever a compression of a phrase we already write out.

So we retired it and did not replace it. The layer is the capability and that is not cosmetic. Capabilities exist to bridge the business and technology spheres, and an acronym is a barrier at exactly that boundary — it signals insider vocabulary to the business reader and invites the technical reader to decode rather than understand. Plain “capability” travels across the room. A three-letter initialism stops at the architects.

Which brings it back to data. Data won because a board member and a database engineer can both say it and mean something true. Capability is unusually well placed to clear that bar: business architects have used it since 2006, the CNCF and API strategists both arrived at it in 2023, and context engineers wired it into the wire format in 2025. The word already lives on both sides of the room.

Data earned that. API never quite did. Capability can.

The takeaway #

The pattern repeats. Every era exposes a new abstraction when a new consumer arrives. Data for programs, APIs for developers, capabilities for agents.Three roads, one word — and only one of them AI-native. API design strategy made the capability the unit of design (Pedro,June 2023); platform engineering made it the unit of fulfilment (the CNCF’s*“integrated collection of capabilities”,March 2023). Both predate the agentic era. MCP is the exception that proves the point: built for agents from the start, it still** reached for the existing wordrather than coining a new one, and now requires it on every request. Agents inherited the boundaries.Homann defined a business capability in 2006**as modellingwhata function does versushow*— a black box that exposes an interface. Gartner’s PBCs and DDD’s bounded contexts say the same thing for different audiences. If you have that work, you are holding a draft: what is missing is a machine-readable contract and a governed runtime, not the decomposition.SaaS businesses face the second wave now. Being callable is becoming a distribution requirement the way being integrable was a decade ago — and mirroring your whole API as tools reproduces the catalog problem inside your own product. The portal splits rather than disappears: humans keep it, agents get a governed capability surface.Both sides can author, if the unit is declarative. The provider knows which jobs customers hire the product to do; the consuming enterprise knows the task, tenant and policy. A declarative capability lets the second narrow the first without forking — which a pre-built connector or a runtime-synthesized integration cannot.Use plain words. Bridging business and engineering is the whole point of the abstraction. Do not put an acronym on it.