Governance Is Not a Feature of Your Agent Framework

There is a recurring framing for governance of autonomous AI action that I keep pushing back on: that governance should live inside the agent framework as a module, plugin or built-in feature of whichever orchestration system the team has standardised on. The framing is intuitive, and it is also exactly the architecture that makes governance brittle in the ways that matter most when an audit or migration finally happens. When governance is implemented inside the framework, it inherits the framework’s lifecycle. That can sound like an implementation detail. Operationally, it turns governance into a vendor-controlled surface.

Frameworks change. APIs evolve, configuration formats shift, features are added and removed on a release cadence driven by vendor priorities. If governance is embedded in the framework, then governance behaviour changes when the framework changes, whether or not anything in the governance requirements has actually changed.

It helps to picture the architecture before walking through the test. The framework produces tool calls. The governance system evaluates those tool calls before they execute. Between the two sits an adapter, a translation layer that converts the framework’s tool-call representation into a canonical fact set the governance system can evaluate. Three components, three jobs. When the framework changes, the adapter changes; the policies, the evaluation function and the evidence chain stay where they are. When governance is embedded inside the framework instead, those three jobs collapse into one and a framework upgrade changes governance behaviour whether anyone authorised it or not.

The Separation Test Is Operational

The working test for whether governance is actually independent does not depend on what the architecture diagram claims. It is this: can the team change the framework — upgrade it, reconfigure it, replace it entirely — without altering what governance allows or denies?

If the answer is yes, the governance system is doing its job at the right layer. It evaluates actions, renders decisions and produces evidence regardless of which framework happens to have produced the tool call. Governance is independent infrastructure.

If the answer is no, if upgrading the framework changes what is allowed or denied without anyone changing a governance policy, then what the team has is not governance. It is a framework feature, and it is governed by the framework vendor’s priorities rather than by the organisation’s. A vendor’s release notes can change permissions. A vendor’s deprecation can remove an enforcement point. A vendor’s restructure of a configuration schema can make a policy unparseable until the schema is migrated. None of those is a governance event; all of them change governance behaviour.

If governance cannot be described without naming the framework, it does not exist independently of it.

What Collapses When Governance Is Embedded

The cost surfaces in several places, and all of them trace back to the same coupling. Naming each surface is the cleanest way to see it.

Lifecycle coupling. Governance configuration changes when the framework changes. Policy formats, permission schemas and audit-log structures end up tied to framework versions, and a framework upgrade becomes a governance migration whether or not anything in the governance requirements actually moved.

Vendor dependency. The governance system’s behaviour depends on the framework vendor’s implementation. Bugs in the framework’s governance module are governance bugs the organisation cannot fix on its own timeline; deprecated features are governance regressions the organisation did not approve.

Portability loss. If the organisation migrates to a different framework, or runs agents across more than one, governance has to be reimplemented for each. Policies cannot be shared cleanly. Evidence formats diverge. The governance posture starts varying by framework rather than by policy.

Testing opacity. The governance system’s behaviour ends up tested by the framework vendor against the vendor’s idea of correct, not by the organisation against its own. If the vendor’s tests pass while governance behaviour quietly changes, the failure may stay invisible until an audit finds it.

Evidence absence. Framework-native governance may log decisions, but the logs are not cryptographically chained, not independently verifiable, and not bound to a specific policy version and delegation state. A checkpoint records state; it does not record authorisation. Without tamper-evident evidence, the governance claim cannot be falsified, which means it cannot really be defended either.

Independent Infrastructure Survives Framework Change

Governance as independent infrastructure means the governance system exists outside the framework. It does not import the framework’s libraries, version with its releases, or use the framework’s configuration format as its own. The framework’s job is to produce tool calls. The governance system’s job is to evaluate those tool calls before they execute. The boundary between the two is an adapter, a translation layer that converts the framework’s tool-call representation into a canonical fact set that the governance system can evaluate. The adapter is framework-specific. The evaluation is framework-agnostic.

When the framework changes, the adapter changes. When the organisation migrates to a different framework, a new adapter is written. The policies, the evaluation function, the evidence chain and the decision logic stay where they are.

Governance Semantics Should Survive

The framework’s quality is not the issue. Frameworks optimise for capability and ergonomics, evolving on vendor timelines; governance optimises for constraint, evolving on policy timelines. The two have different concerns and different lifecycles, and that is why they should not share an implementation.

Three observations follow naturally from the test I started with. If a framework upgrade changes what governance allows without anyone changing a policy, governance is coupled to the framework. If removing the framework makes governance disappear, governance was never a separate control to begin with. If replacing the framework requires the policies to be rewritten, governance was never independent of it. Independent governance survives all three of those operations because its semantics live in policy, delegation, evaluation and evidence, not in the framework’s release notes.

Governance that depends on the framework is not independent governance. It is a framework feature.