Shift*Academy

Shift*Academy

Designing a Capability Interface

How discoverability may become the next layer of organisational design.

Cerys Hearsey's avatar
Cerys Hearsey
Jun 30, 2026
∙ Paid

Over the past decade, organisations have invested heavily in understanding themselves. Capability mapping, in particular, gave leaders something that organisational charts and process models never quite managed: a stable view of what the enterprise could actually do, expressed in terms that persisted across restructures, technology changes and shifting priorities. It made organisations more legible to the people working inside them.

Enterprise AI is arriving into that landscape and exposing a limitation that capability mapping was never designed to solve.

A capability map can tell you that a Customer Insight capability exists, who owns it and how mature it is. What it cannot tell you is how to engage with it: what information it requires, what outputs it produces, what decisions it can make and when escalation is needed. For years, those questions were answered through relationships, experience and institutional memory. People learned how to navigate the organisation by working inside it.

Agents cannot do that. They require capabilities to be discoverable and understandable in ways that don’t depend on knowing the right person or having spent years in the building. Increasingly, organisations need to build interfaces to interact with them.

The Potential of Capability Interfaces

As the AI ecosystem has been expanding, there has been a growing focus on discovery. As agents become capable of performing increasingly complex tasks, a practical challenge emerges: before an agent can act, it must first understand what tools, services and capabilities are available to it. It needs a way to discover them, understand their purpose, determine their requirements and know how to invoke them safely.

This challenge sits behind much of the recent interest in protocols such as MCP, agent registries, shared service architectures and AgentOps platforms, all attempting to make capabilities discoverable and usable by machines. It turns out organisations have always had a version of this problem. Employees know expertise exists somewhere but struggle to find it, functions duplicate work because they cannot easily discover what another part of the enterprise already provides. Humans compensate through relationships and organisational folklore. Agents cannot.

This is where standardised capability interfaces could be useful. A capability interface sits between the existence of a capability and its use. A capability map might tell you that a Customer Insight capability exists. A capability interface would tell you what the capability does, what information it requires, what outputs it can provide, which policies govern its use, which decisions it can make, when human approval is required and how it connects to other capabilities.

At first glance, this looks like little more than better documentation. The more interesting possibility emerges when capability interfaces begin interacting with one another. A single capability interface makes a capability easier to discover and use. A network of capability interfaces makes capabilities easier to combine, and that shift, from understanding individual capabilities to coordinating combinations of them, is where the idea becomes strategically significant.

Why Most Organisations Stop at Mapping

If capability interfaces seem like a natural evolution of capability mapping, it raises an obvious question: why are they not already being extended?

Part of the answer is that mapping and interfacing solve fundamentally different problems. A capability map is primarily descriptive: it helps the organisation understand itself, provides a common language for strategy and transformation, and can remain relatively stable once created. A capability interface is operational. It must describe not only what a capability is, but how it can be used, which requires a very different level of organisational clarity.

Who owns the capability? What services does it provide? What decisions can it make autonomously, and when should work be escalated? What policies and controls apply? Many organisations struggle to answer these questions consistently, not because the capability does not exist, but because much of the knowledge remains implicit. Organisations typically operate through a mixture of formal structures and informal agreements. Processes exist on paper, but exceptions are handled through experience. Responsibilities are documented, but authority is negotiated in practice.

Humans are remarkably good at working around this ambiguity, but agents do not have the tools to do that. As organisations begin deploying more sophisticated agent systems, these hidden assumptions become increasingly visible. An agent cannot rely on organisational folklore or infer decades of accumulated context from a hallway conversation. The boundaries, rules and expectations must be made explicit.

This is why many early agent initiatives eventually encounter organisational rather than technical constraints. The challenge is rarely that the model cannot perform the task. The challenge is that the organisation has not fully codified how the task should be performed, what authority exists, what information is required, and how the work connects to the wider system. Capability interfaces force these questions into the open, and in doing so, they reveal something uncomfortable: the limiting factor for many agentic organisations may not be intelligence, but organisational clarity.

In practice, this diagnostic function may prove as valuable as the interfaces themselves. Some organisations will discover they have more capabilities than they realised. Others may discover that what appeared to be a capability was really a collection of relationships, tacit knowledge and informal agreements held together by a handful of experienced people.

What a Capability Interface Might Look Like

The easiest way to understand capability interfaces is to imagine the difference between knowing a service exists and knowing how to engage with it. Most organisations have a Customer Insight capability, but if an employee, team or agent attempts to use it, they typically rely on experience to answer the basic questions: what to provide, what outputs to expect, what can be decided automatically and what requires human involvement. A capability interface makes those answers explicit. For Customer Insight, it might look like this:

Over time, a capability interface can also become a feedback loop. Teams and agents that engage with a capability are well-placed to report on whether it performed as expected, where the interface was unclear and what edge cases the documentation didn’t anticipate. Building a lightweight feedback mechanism into the interface, even something as simple as a rating and a comment field, means the interface improves with use rather than drifting out of date.

The more forward-looking possibility is that each capability interface becomes associated with its own agent: a custodian that can answer questions about the capability, help other agents understand how to interact with it correctly, handle edge cases that fall outside the documented rules and escalate to the human owner when something genuinely novel arises. Rather than a static specification, the capability becomes something closer to a service with a representative, one that can negotiate, clarify and adapt on behalf of the team that owns it.

The same interface works for a human, a team or an agent, which is where the idea becomes strategically significant. Most organisations already possess the capabilities required to deliver complex outcomes. The challenge is rarely their absence. More often it is the difficulty of coordinating them across functional boundaries: a customer onboarding journey spanning Sales, Legal, Compliance, Finance and Operations; a product launch requiring Marketing, Research, Procurement and Support. Today that coordination runs through meetings, relationships and project structures, people acting as translators between functions.

As agent systems become more capable, a different model begins to emerge. Instead of coordinating people, organisations increasingly coordinate capabilities. The outcome becomes the organising unit, and the question shifts from “which department should own this?” to “what combination of capabilities is required to achieve this outcome?” Agent orchestration platforms, shared agent networks and outcome-oriented systems are all pointing toward this pattern: capabilities become building blocks, and interfaces become the mechanism through which those building blocks are discovered and connected.

If You’re Serious About Capability Interfaces

Capability interfaces are unlikely to emerge through a large-scale transformation programme. Like many organisational innovations, they are easier to discover through experimentation than through design.

Read on for details on four practical exercises that will help you get ready or get started, regardless of your organisation’s state of agentic AI maturity.

User's avatar

Continue reading this post for free, courtesy of Lee Bryant.

Or purchase a paid subscription.
© 2026 Shiftbase Ltd · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture