The Stainless deal tells you where the easy wins are headed. Turning an OpenAPI spec into a TypeScript SDK, a Python client, and an [MCP server](https://konghq.com/blog/engineering/mcp-servers-guide)MCP server is going to be a button. That's good. It lowers the activation energy for getting an agent to call your APIs, and it means the long tail of internal services finally becomes reachable without a quarter of bespoke engineering work per system.

What it does not do is answer the harder questions that show up the day after the MCP server is live. We call this the generation-to-governance gap.

Who is allowed to call this tool, and under what conditions? What happens when an agent loops on a high-cost endpoint? Which model called which tool on behalf of which user, and can you prove it to an auditor six months from now? When a downstream API changes its rate limits, do all your agents degrade gracefully, or do they fail in correlated ways at 3 a.m.? When your CFO asks why the AI line item tripled last quarter, can you attribute spend to a team, a use case, or a specific agent?

These are runtime governance questions. They are not solved by better SDK generation. They are solved by an enforcement layer that sits in the path of every agent-to-tool and agent-to-model call, applies policy, captures telemetry, and produces the audit trail and cost data the business needs.

That layer is what we mean when we talk about AI connectivity. It's a different category from what gets generated at build time, and the gap between the two is going to widen as MCP server creation gets easier. More connectors, called by more agents, against more models, with no governance in between, is not a state any enterprise wants to operate in for long.

There's a quieter assumption baked into the build-time tooling story that deserves to be pulled out into the open. Spec-to-SDK generation assumes the path from agent to system/context is always a request/response API call. For some interactions, it is. For real agentic systems in production, it is likely going to be one of three.

The other two are real-time subscription to events and accessing memory.

**1. Real-time data as the agent trigger**

Agents need to be triggered, not just called. A payment failing, a customer ticket being filed, a sensor crossing a threshold, a contract approaching renewal: most of the high-value moments an agent should act on are things that happen, not things you ask about.

That requires event streams, brokers, and the routing and filtering logic to get the right signal to the right agent without flooding it. None of that lives in an OpenAPI spec, and none of it gets generated by a CLI.

**2. Memory as the agent's continuity layer**

Agents also need to remember. They need durable context that persists across turns, sessions, and other agents — past decisions, retrieved documents, customer history, the state of a long-running workflow. That memory has to be fast to retrieve, governed by the same access controls as the underlying data, and consistent across the agents that share it. Right now, memory lives in various kinds of systems (i.e., key-value stores, vector databases, etc.). We think that will continue, but we also have a strong point of view that the event broker — specifically Kafka — has a major role to play here, too. A durable, replayable, and real-time-accessible log of information is essentially exactly what multi-agent memory will need. 

But regardless of what tools and technologies get used for these communication patterns, the right way to think about an agentic system is that all three will need to be present at once. An event triggers an agent. The agent calls a few APIs and reads from memory to decide what to do. It takes an action through another API. It writes the outcome back to memory. Another event arrives, and the cycle continues. Pull any one of the three out, and the system stops working. Treat any one as an afterthought, and the system stops scaling.

This matters for the build-time-versus-runtime split because it widens the generation and governance gap further. SDK and MCP server generation handles a slice of one of the three. The runtime layer has to handle all of them, govern them with a consistent policy model, and produce a single coherent picture of what every agent did, on behalf of whom, using which tools, against which data, for what cost. That is not a problem any spec-generation tool is positioned to solve, and it is not a problem that gets easier as the number of agents and the volume of traffic climbs.

The other trend worth naming: model vendors are going to keep pulling more of the connectivity stack inside their own platforms. Anthropic is doing it with Stainless. OpenAI is doing it with the Agents SDK and the Responses API. Google is doing it with Agent Builder. AWS is doing it with Bedrock AgentCore. Each one is optimized for its own runtime, its own SDKs, its own connector catalog, its own developer experience.

For a developer building a prototype against one model, this is great. For an enterprise running production workloads, the calculus is different. Most large organizations are already multi-model. They have Claude in some places, GPT in others, Gemini somewhere else, open-weight models behind the firewall for sensitive workloads, and a long tail of fine-tuned and domain-specific models attached to specific business processes. None of that is going away. If anything, the number of models in production per enterprise is climbing.

That means the connectivity layer that actually governs an enterprise's AI traffic cannot be owned by any single model vendor. The control plane has to be neutral by construction. It has to treat Anthropic, OpenAI, Google, AWS Bedrock, Azure AI Foundry, and a self-hosted Llama deployment as peer endpoints, applying the same policies, capturing the same telemetry, and producing the same cost and audit data regardless of which model handled the request.

This is not an argument against Anthropic improving its developer experience. It is an argument that the runtime governance layer is a different job, and one that needs to sit above any specific vendor's stack.

If you're a platform team trying to figure out what to actually build, the picture is getting clearer.

The build-time layer — SDKs, MCP server scaffolding, spec-to-client tooling — is consolidating, and increasingly, some of it will come from your model vendor. Use it. It will save your developers real time.

The runtime layer is where the governance, security, observability, and monetization decisions get made. That is the layer enterprises need to own, and it is the layer that needs to be neutral across models, across agent frameworks, and across the MCP servers and APIs your agents are calling. AI gateways, agent gateways, context infrastructure, registries, and metering all live here. They are not optional add-ons. They are the difference between a demo and a system you can run a business on.

The companies that get this split right are going to move faster, spend less, and ship agentic systems their security and finance teams actually approve of. The ones that conflate the two layers, or assume their model vendor will hand them a complete answer, are going to find out the hard way that generating a connector and governing a connector are very different problems.

We're going to keep building for the second one. The frontier labs can have the first.