When most people in the API space hear the word governance, they picture a Spectral ruleset. They picture a linter in a CI/CD pipeline rejecting a pull request because someone used a request body on an HTTP GET, or because a path was not plural, or because a description field was empty. That is governance, and I have spent a lot of time building out the OpenAPI governance toolchain that does exactly this. But I have come to believe that this picture is far too small, and that we are in the middle of discovering a whole other half of governance that has almost nothing to do with rules and everything to do with what you choose to show. I have started calling it context engineering, and I am increasingly convinced that context engineering is governance — just governance pointed at the consumer instead of the producer.
Here is what I mean. Say you have a real API with two hundred operations and a schema with three hundred fields. That is your producer surface, and you can lint it all day long. Now an agent shows up and wants to do one job — book a meeting, reconcile an invoice, pull a customer record. The naive move, and the move I see everywhere right now, is to hand the agent the whole thing: all two hundred operations, all three hundred fields, the entire graph, and let the model figure out which parts it needs. That is not just a performance problem, though it is that too. It is a governance failure, because you have made no decision about what this consumer should be able to see and do. You have abdicated the single most important governance question there is — what is this consumer allowed to consume — and outsourced it to a probability distribution.
The disciplined move is the opposite. You sit down and you tailor the surface. You decide that this agent, for this job, gets six tools and forty fields, shaped and named and described for exactly the task in front of it. You strip out the operations that are irrelevant. You collapse the fields that would only confuse. You rewrite descriptions so a model reads them the way a careful human would. That act — the deliberate narrowing of a large capability down to precisely what a given consumer needs — is a governance act in every sense that matters. You are setting policy. You are drawing a boundary. You are deciding what is in scope and what is out of scope for an actor operating against your system. The fact that you are doing it with an overlay or an MCP tool definition instead of a Spectral rule does not make it any less governance. If anything it makes it more governance, because it is closer to the actual risk.
This is why I keep pushing back when people tell me governance equals rules. Rules are the producer-side half. They keep your own house consistent — they make sure your two hundred operations look and behave like they came from the same organization. But rules say almost nothing about the consumer. A perfectly linted API with a flawless Spectral score can still hand an agent three hundred fields it has no business touching. The ruleset never asked the consumer question. Context engineering is where the consumer question finally gets asked, and it is the half of governance we have barely started to build tooling for. I wrote a while back that we had governed APIs for the builders and now had to govern them for the consumers, and that governing what agents are allowed to consume is the actual frontier. Context engineering is the practice that lives on that frontier.
And it is real work with real stakes. Every field you leave in the context is a field the agent can leak, misinterpret, or act on. Every operation you leave exposed is a capability the model can invoke when it should not. The surface you hand an agent is the surface it will use, and models are extraordinary at finding the one path you forgot to close. So the person who carefully trims a schema down to the minimum viable context for a task is not doing a performance optimization or a prompt-engineering trick. They are doing least-privilege. They are doing scope management. They are doing the exact same job the security and governance people have always done, wearing different clothes, using different artifacts, and mostly not being recognized for it because it does not show up as a rule in a pipeline.
This ties straight back to the argument I made about GraphQL being governance by default and about MCP being last-mile plumbing. The schema is the foundation. The rules keep the foundation clean. And context engineering is the act of deciding which slice of that clean foundation each consumer gets to stand on. Three different disciplines, one continuous idea — that governing an API is the ongoing work of deciding what is exposed, to whom, and why. The Spectral ruleset is one instrument in that work. It is not the whole orchestra, and if we keep telling people that governance is just linting, we are going to keep watching teams hand agents the entire building and wonder why things go wrong.
So I would ask everyone building for agents right now to notice what they are already doing. Every time you trim a tool list, rewrite a description for a model, or decide a field does not belong in the context, you are governing. Name it. Treat it with the same seriousness you treat your producer-side rules. Because the consumer-side half of governance is where the next several years of this work actually lives, and context engineering is its first and most important practice.
