I have been having a lot of conversations with enterprise teams about capabilities lately. Fifteen-plus active design-partner conversations at this point — different industries, different regulatory regimes, different starting points, different tech stacks. What I expected to see was a wide spread of distinct problems, each company surfacing its own peculiar dysfunction.
What I am actually seeing is convergence.
Four problems keep showing up in every serious conversation, regardless of who I am sitting with. Governance. Reuse. Agent orchestration. Compliance. The same four. Across F500 healthcare. Across financial services. Across retail and industrial. Across the big-four consulting firms. Across hyperscaler partners. The technology choices vary. The maturity varies. The org chart varies. The four problems do not.
That convergence is the most useful data signal I have right now, and it is worth a public post.
1. Governance
What I keep hearing is some version of this sentence: “We do not have a missing platform. We have ten of them. What we do not have is a way to enforce policy where the consumer actually shows up.”
EY frames it as governance-at-scale for agent runtimes. Palo Alto Networks frames it as 405 API operations across 36 APIs that need to be standardized and consistently governed without breaking the consumer contracts they already have. Chase and the rest of the financial-services pipeline frame it as audit-grade visibility into who called what and why. JPMorgan’s published 2026 Tech Trends frame it as “governance must shift from centralized control to federated guidance.”
The common thread is that nobody is asking for another gateway. They have gateways. They have catalogs. They have policy engines. What they do not have is a way to put governance at the place the agent or the human actually consumes the capability — close enough to the consumer that the policy can be enforced before the call, not after, and detailed enough that the policy can change without rebuilding the upstream API.
That is what we mean when we say governance belongs at the consumption layer. The conversations all keep landing there.
2. Reuse
What I keep hearing here is: “We already built that. Three teams already built that. Nobody can find it.”
Ford has decades of API investment and the same internal capability has been re-implemented across at least three business units I can identify. Cvent is consolidating event-platform integrations that grew up in parallel across acquisitions. Schneider Electric has stood up an internal MCP server registry specifically because they realized their teams were independently exposing the same underlying systems three different ways. Aramark, Medtronic, Penske — same pattern.
The internal MCP registry pattern is interesting because it is the right instinct pointed at the wrong layer. A registry of MCP servers tells you what tools exist. It does not tell you what capabilities exist — the semantic unit a builder is actually shopping for. If your registry lists fourteen MCP servers and three of them expose “create-purchase-order” with different shapes, you have inventoried the duplication, not solved it.
What enterprises are reaching for is a capability layer above the MCP servers — one where “create purchase order” is a named, typed, governable unit, and the three MCP exposures underneath are implementation details. Capabilities are the unit of reuse. Registries are the surface.
3. Agent Orchestration
What I keep hearing: “Our agents need to do twelve things. We can wire each one to a tool. We cannot reason about the whole.”
The tool-per-endpoint approach to building agents scales linearly with how many endpoints you have. The right abstraction scales differently. Microsoft M365 Copilot DevX, Salesforce, and the agentic teams at every consulting partner I talk to all run into the same wall: stitching tools together at the agent layer means the agent has to carry the orchestration logic in its prompt context, and that logic does not survive a model swap, a tool rename, or a context-window squeeze.
What they actually want is a composition unit one level above the tool. Something where “run the quarterly close” is one capability, and the eleven downstream operations that capability invokes are described once, governed once, and traced as a unit. That is what Anthropic’s Building Effective Agents calls the right level of abstraction, and it is what we have been calling capability composition since the spec started. Same problem from two directions.
The orchestration the enterprise is asking for is not a workflow engine. It is a typed, named, observable unit at the layer the agent can actually reason about — which is one above the raw tool, and one below the business process.
4. Compliance
What I keep hearing: “We have a data residency requirement, an audit requirement, a model-vendor requirement, and a regulator-specific reporting requirement. They all want different artifacts.”
AXA is a financial-services compliance conversation about cross-border data flow. KPMG is a professional-services conversation about evidence packages for client engagements. The Vanguard inbound is about how a regulated asset manager produces a defensible record of every model-mediated decision. The IHE inbound is about healthcare interoperability and the audit trail that has to follow every PHI access.
Compliance is multiple problems wearing the same coat. The trick is realizing that almost every compliance artifact a regulator or auditor or client asks for can be derived from the same underlying source: a machine-readable description of what the system can do, who is allowed to do it, what got called, with what inputs, against which data, returning what outputs, with what observable side effects.
That description is the capability. Compliance is what happens when the capability is well-described enough that the auditor can read it.
What the convergence actually means
When the same four problems recur across F500 healthcare, financial services, retail, industrial, big-four consulting, and hyperscaler partners, you do not get to call it a coincidence. It is a market signal.
The signal is that enterprise teams have stopped looking for another platform and started looking for a missing layer. The layer sits above the existing gateways and catalogs and MCP servers. It is one where governance is enforced at the point of consumption, where reuse is measured at the capability rather than at the wire, where agents reason about composed units rather than raw tools, and where compliance falls out of the description rather than being bolted on afterward.
That is the layer Naftiko is building, and it is the layer the conversations keep landing on. The fact that fifteen-plus independent enterprises arrived at the same four problems without coordinating with each other is — honestly — the most validating thing that has happened to the thesis in months.
If your conversations are landing somewhere different, I would love to hear it. If they are landing in the same four places, that is the signal that the work we are doing in the open at naftiko.io is the work you should be paying attention to.
The four problems are not going to solve themselves at the gateway layer. They have not, and they will not. The layer above is the one that matters now.
