What agent frameworks actually govern, and what they leave to you

Agent platform field notes, three of eight. Notes one and two argued that the trust root must be yours and that “connected” is not “sovereign”. This one is about the frameworks themselves, because the first question every team asks is “which one”, and it is the wrong question until you know what “which one” decides for you.

The axis

I evaluated more than a hundred agent frameworks, orchestrators, gateways and runtimes for a governed platform for Dutch local government. Most comparisons rank them on developer experience, ecosystem size or benchmark scores. For a regulated buyer those are secondary. The question that matters is narrower:

Of the decisions a regulator, an auditor or a citizen will eventually ask about, which does the framework take, and which does it leave to you?

I use five such decisions, the same five that define the governance spine from note one:

1. Identity and delegation. Who is this agent, on whose behalf does it act, and what is it allowed to do that the person is not?
2. Policy enforcement. Where do the rules run, and can the model talk its way past them?
3. Approval binding. When a human must approve, what exactly are they approving, and can the plan change after they do?
4. Tool mediation. Who decides whether a tool call executes, and is that decision default-deny?
5. Evidence. What record survives, who wrote it, and can it be edited?

Here is my reading of six frameworks on that axis. The reading is current to mid-2026, based on their published documentation and my own hands-on work with the first four. Treat it as a map, not a verdict; these projects change monthly.

Microsoft Agent Framework

The merger of AutoGen’s orchestration patterns and Semantic Kernel’s enterprise plumbing, generally available since April 2026, with both predecessors now in maintenance mode. If you are a .NET shop, this is the default.

What it governs: a lot of the plumbing. Filters on every model and tool call, first-class telemetry, native MCP and A2A, and, through the hosted option, per-session sandboxed execution with an automatically issued directory identity per agent and no stored secrets. That last part is real governance: an agent with its own identity, scoped by a tenant, is a precondition for everything else.

What it leaves to you: the identity is strongest when the hosting is Microsoft’s. Run it self-hosted and you keep the filters and the protocols but you build the identity model, the approval binding and the evidence store yourself. Filters are also hooks inside the runtime; they are enforced by the runtime, which is exactly the thing note one said cannot be your trust root. I adopted it as the runtime for my platform and placed the policy gate behind an interface the framework does not own. That is not a criticism. It is the correct division of labour, and the framework’s own interfaces make it possible.

LangGraph

The low-level graph runtime under the LangChain family, 1.0 since October 2025. State as a typed object, nodes and edges, checkpoints at every step.

What it governs: durability and interruption. The checkpointer means a run can pause for a human, be inspected, resume, or replay from any point. That is the best primitive for approval binding in the open-source field, because the approval can be attached to a specific checkpoint rather than to “the conversation”.

What it leaves to you: everything about what the human is approving. The graph will stop and wait; it does not know whether the plan revision it resumes is the one that was approved. Policy is code in nodes, which means it is enforced wherever you put it and nowhere else. Identity is whatever your application passes in. Evidence is the checkpoint store, which is a database you own, which is good, but it is a store of state, not a tamper-evident record of decisions. You will write that layer.

OpenAI Agents SDK

Small, opinionated, and the fastest way to a working multi-agent system on OpenAI models. Agents, handoffs, guardrails, sessions.

What it governs: input and output guardrails that run in parallel with the agent, and handoffs as a first-class mechanism, which at least makes delegation explicit rather than implicit.

What it leaves to you: the guardrails are evaluated by the SDK, in process, usually by another model call. That is a convention, not a control, in the sense of note one. More structurally, the SDK’s runtime contract is tightened around the provider’s own hosted primitives: threads, files, stores, tools. Every one of those is a provider dependency you will have to qualify, pin and record as a route, and the SDK gives you no help with the evidence side. For a frontier-connected use case it is a fine engine. It cannot be the governor.

Claude Agent SDK

The programmatic form of Claude Code: the same agent loop, tool system and permission model, exposed as a library.

What it governs: tool permissioning, and it governs it well. Fine-grained allow and deny rules per tool, hooks before and after every tool call, sandboxed execution, and a visible audit of what the agent did. Of the six, this is the one that treats “may this tool run” as a first-class question rather than a callback.

What it leaves to you: the harness is bundled and provider-bound. The permission decisions are enforced by the harness, so the same trust-root caveat applies, and the identity in play is the API key, not a principal your directory knows. I use it daily, under my own written rules, as a coding agent inside a pipeline that holds the merge and production keys elsewhere. That is the right place for it: an excellent governed worker, not the governor.

Google ADK

Code-first, multi-language, and since ADK 2.0 in May 2026, a deterministic workflow runtime with human-in-the-loop checkpoints, built-in evaluation and native telemetry export.

What it governs: evaluation. ADK ships trajectory and response evaluation as part of the toolkit, which is rarer than it should be. If you believe, as I do, that nothing changes in production without passing its evaluation set, ADK gives you that discipline out of the box. The workflow runtime also gives you the same checkpoint-based approval primitive as LangGraph.

What it leaves to you: identity, policy outside the prompt, and evidence, with the same self-hosted-versus-hosted asymmetry as Microsoft’s framework. The most governed configuration is the one on Google’s own agent engine. Elsewhere you build the spine.

CrewAI

Role-based crews with goals and backstories, plus event-driven flows. Popular, fast to prototype, weekly releases.

What it governs: the division of labour between agents. The team metaphor is readable and makes the intent of a multi-agent system legible to non-engineers, which has real value in a workshop.

What it leaves to you: all five decisions. There is no identity model, no policy layer outside the prompt, no approval binding, tool access is as broad as the tools you hand over, and evidence is logging. That is not a flaw for its intended use. It is a reason not to confuse “we have a crew” with “we have a governed agent”.

The pattern

Lay the six side by side and one shape appears. The frameworks govern the parts of the problem that live inside the run: orchestration, interruption, per-call hooks, tool permissions. The parts that live around the run, who the agent is, which rules bind it regardless of runtime, what exactly was approved, and what record survives, are left to you in every case, and are strongest only when you accept the vendor’s hosting as the trust root.

That is the build-versus-buy answer in one sentence: buy the runtime, build the spine. Any of the first five is a reasonable runtime for the right stack. None of them is a governor, and none of them claims to be, once you read the documentation on this axis rather than on the feature list.

Conway’s law has a corollary for agent platforms: a framework governs exactly the decisions its vendor had to make, and leaves you the ones its vendor could bill someone else for.

What I cannot prove

Four of these I have run in anger; two I know from documentation and from other people’s experience in my research base. Versions move fast, and the hosted governance features of the two large vendors in particular are evolving quarterly. Some of what I file under “leaves to you” today will be a product feature next year. The axis will still hold; the entries will not.

What to do with this

Before your next framework decision, write the five questions above on a whiteboard. For each candidate, answer “framework”, “vendor hosting”, or “us” in every row. The framework you choose matters less than how many rows say “us” and whether anyone has been given the budget to build them.

Next note: MCP gateways, and where policy, identity and egress really get enforced when every tool is a server.

Nobody expects the governance questions. Their chief weapon is identity. Identity and evidence. Their two chief weapons are identity, evidence and approval binding. Amongst their weaponry are such elements as policy and tool mediation. I shall come in again.

References

The allusions and quotations in this piece, with their origin:

• Melvin Conway, “How Do Committees Invent?” (1968): organisations design systems that mirror their communication structures.
• Monty Python’s Flying Circus (BBC, 1970), the Spanish Inquisition sketch: “Nobody expects the Spanish Inquisition” and the escalating list of chief weapons.