Every serious enterprise architecture team eventually arrives at the same shape: domain-driven microservices, each with its own datastore and lifecycle, fronted by an API gateway that enforces authentication, rate limiting, and governance. It is a hard-won pattern. It survives audits. It survives data-residency requirements. It survives the arrival of the next framework.
Then AI agents show up, and the question changes from “how do we expose this service” to “how does an agent use this service correctly.” That is not a gateway problem, and it is not a microservice problem in the classic sense. It is a new one — and the answer, we’d argue, is a new kind of microservice.
A pattern every enterprise architecture team recognizes
The setup below is not a one-off. It is the shape we see again and again in enterprises that have built for scale and compliance — and it will be familiar to any architecture or API strategy lead:
- Microservices, domain-driven and independent, each with its own database, so one service’s operational issue never cascades into another.
- gRPC internally for speed, REST externally for interoperability. GraphQL often gets evaluated and set aside as too complex for external vendors.
- An API gateway — Apigee is a common choice — for management and governance, frequently locked in because a specific cloud region is required locally and public-sector work demands strict data residency.
- A security team with real veto power across dev, staging, and production, pushing validation earlier in the delivery process.
On AI, these organizations are often deliberately in the research phase: architecture maturity first, agents second. And when we describe Naftiko as “spec-driven integration for agents,” the part that lands is not the AI framing. It is the operational reality underneath it: ecosystems full of disconnected systems, the risk of losing the golden source of truth, and no good way to monitor the exchanges between them. Make integrations explicit, governable, and observable across heterogeneous systems — that is what resonates.
That is exactly the gap a capability is built to close. But to see why, it helps to stop thinking of a capability as an AI feature and start thinking of it as an architectural unit.
A capability is a microservice — a specific kind
Ask what a microservice actually is, stripped of its runtime, and you get a short list: a single-responsibility unit of business function, independently deployable, with an explicit contract, its own bounded context, and its own operational envelope. That definition does not mention Kubernetes, gRPC, or a particular language. It is an architectural stance.
An Ikanos capability satisfies every item on that list — and adds constraints that make it fit for agents:
- Single responsibility, bounded context. A capability declares exactly what it consumes from upstream systems and exactly what it exposes downstream. Nothing leaks. That is the microservice discipline, expressed as a spec.
- Independently deployable. A capability is one YAML file the engine serves directly. No compilation, no code generation, no shared application server. It scales, versions, and fails on its own — the same autonomy teams protect by giving each service its own database.
- Explicit, machine-readable contract. This is where it diverges. A classic microservice publishes an OpenAPI or gRPC contract for developers. A capability publishes a contract an agent can reason about — with business meaning, input and output shaping, authentication, and guardrails declared inline.
- Polyglot exposure from one definition. The same capability spec serves MCP for agents, REST for portals and gateways, and an Agent Skill for discovery — without writing three integrations.
So a capability is not an alternative to microservices. It is a specific type of microservice: spec-driven instead of code-driven, declarative instead of imperative, and shaped for agent consumption instead of hand-written client code. In an estate that already runs .NET, Java, and Python services behind a gateway, a capability is simply the service you reach for when the consumer is an agent — and you want that integration to be as governed as everything else.
Why this cooperates with your gateway instead of competing with it
The real constraint in these environments is rarely technical preference — it is lock-in and governance. Once a gateway like Apigee and a local cloud region satisfy data-residency rules, switching gateways becomes difficult, and rightly so. Any tool that demands rip-and-replace is disqualified before the security review even begins.
This is precisely why capabilities sit with the gateway, not in front of it. We covered the pattern in depth in You Have Apigee. Now Your AI Agents Need to Use It., and the division of labor is clean:
- The gateway keeps doing what it does well. Apigee manages proxies, enforces auth and rate limits, packages API products, and produces analytics. None of that moves.
- The capability calls gateway-managed APIs on the way in. On its
consumesside, a capability uses the gateway’s native auth — API keys, subscription keys, OAuth2 client credentials — with secrets injected per environment. The gateway still meters and governs every call. - The capability sits behind the same gateway on the way out. On its
exposesside, a capability registers as just another REST product the gateway proxies — plus an MCP surface for agents — with health checks and cache headers the gateway already expects.
Nothing about the microservice topology changes. The gateway remains the front door for governance; the capability becomes the governed, agent-ready service behind it. For a team locked into a specific cloud for sovereignty reasons, that is the whole point: the capability layer is portable across dev, staging, and production because only the environment binds change, and it never asks you to leave the gateway you were required to standardize on.
The governance the security team was already asking for
The recurring theme in these environments is control: don’t expose raw personal data, prove data stays local, pass security validation, avoid ungoverned surfaces. These are not AI objections. They are the objections a strong security function raises about any new integration — and they are exactly what a capability is designed to answer.
Because a capability is a spec, its behavior is auditable before it ever runs. What it consumes, what it exposes, what it masks, how it authenticates — all declared, all reviewable, all diff-able in a pull request. Instead of five teams hand-writing five bespoke AI integration layers that the platform team can’t see, you get one governed spec per capability that “shifts left” naturally into the review process the security team already owns. The golden source stays authoritative because the capability points at it explicitly rather than copying it. The exchanges between systems become observable because they run through a declared surface rather than ad-hoc scripts.
Where a team like this starts
A forward-looking use case we hear in exactly these environments is telling: an automated audit agent that scans code and architecture against regulatory and governance rules, scores them, and reduces manual review over time — starting mostly human, growing more autonomous as it earns trust. The expectation is always that this would be a customized solution wired into existing systems — Kafka for business events, BigQuery for data streams, and targeted queries for the inputs an agent needs — not a generic cloud service bolted on.
That is a capability-shaped problem. Each governance rule set, each system connection, each scoped query becomes a capability: a small, single-responsibility, spec-driven microservice the audit agent can call — governed by the security team, fronted by the gateway, and portable across the environments compliance demands. You don’t start by building the agent. You start by making one integration explicit, governed, and observable, and you let the surface grow one capability at a time.
If your estate already looks like this — microservices behind a gateway, a security team with veto power, hard constraints on where data lives — you don’t need a new platform. You need a new kind of service that fits the one you have.
