Market Context 9 min read

# AI Agent Governance Is Splitting Into Two Markets

A year ago, everyone was building agents. Now everyone is building governance around agents. But the word “governance” is already fracturing into two different markets. One protects systems from agent actions in the moment. The other protects systems from architectural entropy over time. Most people treat them as interchangeable. They are not.

By Theo Valmis·May 2026

A year ago, the race was to build agents. Frameworks, harnesses, orchestration loops, tool protocols. The question was whether an autonomous system could plan, call tools, write code, and finish a task without a human in the loop.

That question is mostly settled. The race now is to build governance around agents. Across open-source projects and enterprise platforms, the same instinct keeps surfacing: an autonomous system that can act needs a layer that decides what it is allowed to do. The ecosystem-wide convergence on “agent governance” is the real signal of where the market is heading.

But “governance” is already splitting into two markets. They share a word and almost nothing else. One governs execution. The other governs architecture. Conflating them is the most common mistake in the category right now.

## Runtime governance: protecting systems from agent actions

Runtime governance is the execution control plane around autonomous agents: it enforces policy on each action in real time before the action reaches its target. A distinct category of runtime agent-control tooling has emerged in 2025 and 2026, and the primitives keep recurring across projects and platforms:

- Approval and permission gates that require human confirmation before an agent takes a high-impact action
- Scoped tool permissions and least-privilege credentials
- Spend and rate limits that cap what an agent can consume
- Immutable audit trails of every tool call
- Execution policies — allow, deny, or require-approval — evaluated per action
- Kill switches that revoke an agent after repeated violations
- Human-in-the-loop escalation for actions above a risk threshold
- Trust and risk scoring that gates behavior dynamically

The anchors for this trend are real and visible: policy-enforcement layers shipping as both open-source toolkits and commercial products, runtime-authorization patterns built around the agent frameworks and tool ecosystems teams already use, browser-agent and enterprise-copilot deployments, the OWASP threat model for agentic applications, and analyst framing that treats governance, security, and cost control as a fast-growing segment of the agentic market.

This layer plays a role analogous to an API gateway. It sits in the request path and enforces policy on each action in real time — authentication, quota, schema validation, allow/deny — before the action reaches its target. The pattern is a policy enforcement point invoked before any tool call, backed by a policy decision point.

This is necessary work, and the category deserves to exist. It resembles the way an entire security and compliance layer grew up around cloud computing as the platform matured: the shared-responsibility model, posture management, configuration and access controls. The platform’s power created new categories of risk that the platform itself did not address. Runtime agent governance is that layer for autonomous execution.

Runtime governance answers one question: can this agent perform this action, right now? It is the execution control plane. For the conceptual definition, see runtime governance, and for the market argument, the runtime layer as the next AI infrastructure layer.

## Architectural governance: protecting systems from architectural entropy

Architectural governance preserves architectural intent as autonomous systems continuously modify software, operating across time and across the codebase rather than per action.

Here is what the first market does not cover. A perfectly safe agent — one that never deletes a database, never exceeds its budget, never touches production without approval — can still quietly destroy an architecture.

Runtime controls operate per action and in the moment. They are built to stop the step that drops a table, sends the email, or spends the money. But not every dangerous agent action is a dangerous step. Many are dangerous trajectories. Each change can be locally reasonable and globally inconsistent. Over many iterations, that gap compounds.

This is a different failure mode, and it accumulates across time rather than detonating in a single action:

- Architectural drift — small, individually defensible deviations that add up to a system no one designed
- Dependency sprawl — new libraries and duplicated code introduced because the agent could not see what already existed
- ADR violations — decisions the team made and wrote down, silently contradicted in code
- Broken repository invariants — boundaries and layering rules that hold in one file and not the next
- Governance propagation failures — a constraint honored by one agent or one tool, ignored by another
- Long-running session degradation — intent that erodes the further an autonomous session runs from its starting context
- Autonomous refactor drift — refactors that improve a local metric while pulling the structure off its intended shape
- Decision provenance loss — nobody can reconstruct why the system is the way it is

This is the documented and accelerating wave of architectural technical debt that AI-driven iteration is now producing. It is not the risk that a single step is destructive. It is the risk that ten thousand correct-looking steps add up to a system that no longer matches its own engineering intent.

Addressing this requires a different layer: one that operates across time and across the codebase, not per action. It is the place where architectural governance lives — preserving intent while autonomous systems continuously modify software, by treating architectural drift as something to be detected and prevented and by ensuring governance propagation reaches every agent and tool touching the repository.

Architectural governance answers a different question: after a thousand agent changes, does the system still match what the team decided it should be? That question cannot be answered one action at a time.

Two markets, one word: execution governance and engineering governance

## Why traditional monitoring fails

The instinct, when a new failure mode appears, is to monitor for it. But monitoring was built to catch a specific shape of failure: the outage, the latency spike, the error rate, the crash. Observability tells you when something stopped working.

The dangerous agent failures are not failures by that definition. They are structurally correct, syntactically valid, and operationally dangerous over time. The code compiles. The tests pass. The endpoint returns 200. The agent technically succeeded at the task it was given. And in succeeding, it introduced a forbidden dependency, crossed an architectural boundary, or contradicted a decision the team had already made.

Monitoring sees none of this, because nothing broke. The signal monitoring is built to detect — a thing that failed — never fires. The violation is invisible to a layer that only watches for outages.

Observability does not create reliability by itself; it makes reliability achievable at high deployment velocity by shortening how long it takes to detect, diagnose, and recover. It is genuinely good at that. It is simply the wrong instrument for architectural violation, which produces no incident to detect. This is the distinction explored in why observability is not governance.

An agent can satisfy every runtime check and pass every monitor while quietly violating engineering intent. That gap is precisely where architectural governance has to operate.

## Governance becomes infrastructure

This pattern is not new. Governance layers emerge naturally once a platform becomes powerful enough to create risks it does not address itself.

As cloud computing matured, a security and compliance layer grew up around it — not designed in from day one, but pulled into existence by the platform’s own power. As continuous delivery accelerated how fast software shipped, observability matured alongside it as the complementary discipline that made high-velocity releases survivable. Each infrastructure wave produced a governance layer once the underlying capability outran the controls around it. That is the argument in the next AI infrastructure category is governance.

Autonomous software systems are now at that point. The capability — agents that plan, execute, persist state, and iterate across long-running and multi-agent workflows — has outrun the controls. The result is a governance layer that has to be infrastructure, not a checklist: present in the AI-native SDLC, reachable from the execution loop, and expressed as verification contracts the system can evaluate rather than prose a human is supposed to remember.

This is also why the discipline of harness engineering — building the execution layer between models and production — keeps arriving at the same conclusion: a harness that can do more needs a governance layer that holds intent across everything it does.

## Why enterprises will need both

The two markets are not competitors. They are complements, addressing two genuinely different risks.

Runtime governance prevents dangerous actions. It is the execution control plane that stops the agent from doing the irreversible thing in the moment. Architectural governance preserves system integrity over time. It is the engineering control plane that keeps a system matching its own design as autonomous iteration compounds.

An enterprise running autonomous systems needs both, for the same reason it needs both an API gateway and a code architecture. One protects the request. The other protects the structure that serves every request.

- Execution governance — per-action, real-time, protecting systems from what an agent does right now
- Engineering governance — longitudinal, repository-wide, protecting systems from what a thousand agent changes do over time

Choosing one and calling it “agent governance” leaves half the risk uncovered. A safe agent can still produce an unmaintainable system. A well-architected system can still be wrecked by a single unsafe action. Both layers have to exist, and they have to be understood as different layers solving different problems.

Enterprises need both: execution governance and engineering governance

The next generation of AI infrastructure probably is not another model layer. It is the governance layer sitting around autonomous systems — runtime governance protecting systems from agent actions, and architectural governance protecting systems from architectural entropy. Treat them as the same market and you will under-build exactly the half you cannot see failing.

## Frequently asked questions

What is runtime agent governance?+
Runtime agent governance is the execution control plane around autonomous agents. It enforces policy on each action in real time: approval and permission gates, scoped tool permissions, spend and rate limits, immutable audit trails, allow/deny execution policies, kill switches, and human-in-the-loop escalation. Its job is to protect systems from dangerous agent actions in the moment, much like an API gateway enforces policy on each request before it reaches its target.
What is architectural governance?+
Architectural governance preserves architectural intent while autonomous systems continuously modify software. It operates across time and across the codebase rather than per action, detecting and preventing architectural drift, dependency sprawl, ADR violations, broken repository invariants, and loss of decision provenance. Its job is to protect systems from architectural entropy that accumulates as agents iterate, ensuring the system still matches what the team decided even after thousands of locally reasonable changes.
What is the difference between runtime and architectural AI agent governance?+
Runtime governance handles execution-time risk per action: it constrains what an agent is allowed to do right now so a single step cannot cause immediate harm. Architectural governance handles accumulating, longitudinal risk: each agent change can be locally reasonable yet globally inconsistent, and over many iterations this compounds into drift, sprawl, and violated decisions. Runtime controls operate in real time at each tool boundary; architectural governance operates across time and across the whole codebase. They are complementary layers, not substitutes, and enterprises running autonomous systems need both.
Why is agent monitoring not enough?+
Monitoring and observability are built to detect outages, latency, errors, and crashes: things that stop working. But the most dangerous agent failures are structurally correct, syntactically valid, and operationally dangerous only over time. The code compiles, the tests pass, the agent technically succeeds, and in succeeding it introduces a forbidden dependency or contradicts an existing architectural decision. Because nothing broke, monitoring never fires. Observability shortens detect-and-recover time at high velocity, but it cannot see architectural violation, which produces no incident to observe.
Related governance concepts

- Runtime Governance

  The execution control plane that enforces policy on each agent action in real time.

- Architectural Governance

  Preserving architectural intent as autonomous systems continuously modify software over time.

- Architectural Drift

  Small, locally reasonable deviations that compound into a system no one designed.

- Governance Propagation

  The same compiled constraints reaching every agent, tool, and runtime surface.

Related operational essays

- Agent Runtime Governance

  The runtime layer as the next AI infrastructure layer.

- Why Observability Is Not Governance

  Monitoring sees outages; it cannot see architectural violation.

- Runtime Verification Is Not Architectural Verification

  Sandbox safety protects a run; architecture must hold over time.

- The Next AI Infrastructure Category Is Governance

  Every infrastructure wave creates a governance layer.