By the end of 2026, 40% of enterprise applications will feature AI agents. Not chatbots. Not copilots. Agents that plan, execute, call APIs, modify databases, send communications, and make thousands of decisions per hour without a human in the loop for each one.

Most organisations have no governance model for this. None.

Their AI governance frameworks were built for an advisory world: human asks, model answers, human decides. That pattern is breaking. An agent doesn't wait for your approval on every action. It acts. And the failure modes are categorically different. A bad model answer causes a human to make a bad decision. A bad agent action causes a system to do something harmful — at machine speed, at scale, potentially irreversibly.

From Output Review to Behavioural Governance

Traditional AI governance treats the model like a consultant. You review its outputs before they go live. You run bias tests on its training data. You establish an approval board for high-risk use cases.

This made sense when AI produced recommendations. It makes no sense when AI produces actions.

Consider the difference. A recommendation system suggests a product to a customer. The customer clicks or doesn't. An agentic system sees a customer churn signal, generates a retention offer, sends it via email, updates the CRM, and schedules a follow-up call — all in under a second. There is no human review step. There is no approval gate. The governance model must shift from "did we review the output?" to "did we design the behaviour?"

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph LR
    subgraph ADVISORY ["Advisory Governance"]
        AD1["Human asks"] --> AD2["Model answers"] --> AD3["Human decides"] --> AD4["Audit the output"]
    end
    subgraph AGENTIC ["Agentic Governance"]
        AG1["Agent observes"] --> AG2["Policy evaluated"] --> AG3["Agent acts + logs"] --> AG4["Circuit breaker monitors"]
        AG4 -.->|"deviation"| AG1
    end
    style ADVISORY fill:#2a1a1a,stroke:#ff6b6b,color:#ffffff
    style AGENTIC fill:#0a2a1e,stroke:#00ff88,color:#ffffff
    style AD1 fill:#1a2540,stroke:#ff6b6b,color:#ffffff
    style AD2 fill:#1a2540,stroke:#ff6b6b,color:#ffffff
    style AD3 fill:#1a2540,stroke:#ff6b6b,color:#ffffff
    style AD4 fill:#1a2540,stroke:#ff6b6b,color:#ffffff
    style AG1 fill:#1a2540,stroke:#00ff88,color:#ffffff
    style AG2 fill:#1a2540,stroke:#ffb347,color:#ffffff
    style AG3 fill:#1a2540,stroke:#00ff88,color:#ffffff
    style AG4 fill:#1a2540,stroke:#00ff88,color:#ffffff

Three structural gaps show up in almost every agentic deployment I review.

Scope defined by prompts, not architecture. Teams control what an agent does by crafting increasingly elaborate prompts. This is governance by prose. Prompts drift. Context windows truncate. A junior engineer refactors the prompt and suddenly the agent has access to a production database it shouldn't touch. Scope must be enforced by system design — hard permission boundaries, not careful wording.

Accountability diffused across teams. The data science team built the model. The engineering team wrapped it in an API. The product team defined the use case. The compliance team reviewed it once, six months ago. When the agent makes a damaging decision at 3 AM on a Sunday, nobody owns the outcome. Each team had a slice of responsibility. Nobody had the whole.

Monitoring without a feedback loop. Organisations collect logs of what their agents did. They build dashboards showing failure rates. They review incidents in weekly standups. This is historical record-keeping, not governance. Knowing that an agent caused a problem last Tuesday does not prevent it from causing the same problem this Tuesday. Governance requires a mechanism that changes behaviour, not just documents it.

The Jazz Analogy

Jazz improvisation looks like pure freedom. A soloist plays whatever they feel. But the freedom is built on structure. The chord progression, the tempo, the form — these constraints are what make improvisation possible. Remove them and you don't get more creativity. You get noise.

Agentic autonomy works the same way. The constraint is what creates the freedom. An agent that can do anything is an agent that will eventually do something catastrophic. An agent that operates within a well-designed constitution can act decisively, safely, and at scale.

The organisations that get this wrong treat autonomy as the absence of rules. The organisations that get it right treat autonomy as the product of rules.

The Agentic Constitution

The fix is not more review boards. It is five design decisions made before deployment, embedded in the system's architecture, and enforced automatically.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph TB
    Const["The Agentic Constitution"]
    Const --> S1["1. Scope Definition
Whitelist, not blacklist"]
    Const --> S2["2. Permission Boundaries
Tied to human authority"]
    Const --> S3["3. Human-in-Loop Tiers
Low / medium / high risk"]
    Const --> S4["4. Ownership Model
Single named owner"]
    Const --> S5["5. Feedback Loop
Behaviour-changing, automated"]
    style Const fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style S1 fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style S2 fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style S3 fill:#1a2540,stroke:#ffb347,color:#ffffff
    style S4 fill:#1a2540,stroke:#00ff88,color:#ffffff
    style S5 fill:#1a2540,stroke:#00ff88,color:#ffffff

1. Scope Definition. What can this agent do, and just as importantly, what can it never do? Not in a prompt. In code. Hard boundaries on data access, API endpoints, and action types. If the agent's job is customer retention, it does not get write access to pricing tables. Period. Scope should be defined as a whitelist, not a blacklist. Blacklists grow. Whitelists constrain.

2. Permission Boundaries. Who or what does the agent act on behalf of? With what authority? A human employee has a role, a manager, a budget limit, and an employment contract that creates legal accountability. An agent has none of these unless you design them in. Permission boundaries must map to human accountability structures. The agent doesn't get to spend company money. A human with a spending limit does, and the agent acts within that limit.

3. Human-in-Loop Design. Not every decision needs human review. But some do. The mistake is making this a binary choice: either the agent acts alone or a human approves everything. The right approach is tiered. Low-risk, high-volume actions run autonomously. Medium-risk actions trigger asynchronous review (the human checks within an hour, not within a second). High-risk actions block until a human explicitly approves. The thresholds must be defined in advance and tied to business impact, not technical complexity.

4. Ownership Model. Every agent must have an owner. Not a committee. A single person whose job performance is tied to that agent's outcomes. The owner decides when to deploy, when to update, when to shut down. They carry the pager. If the agent causes harm, they are accountable. This sounds harsh. It is less harsh than the alternative: harm happens, and nobody is accountable because "it was the system's fault."

5. Feedback Loop. What happens when the agent fails? Not just logging. A mechanism that changes the agent's behaviour. This could be automatic retraining on corrected examples, a rules engine that updates constraints based on incident patterns, or a circuit breaker that shuts the agent down when error rates exceed a threshold. The key is that the feedback loop is automated and architectural, not procedural and human-dependent.

What This Looks Like in Practice

A Nordic insurance firm I advised last year had deployed an agentic claims processing system. The agent could approve claims up to €5,000, flag suspected fraud for review, and initiate payouts. It worked well for six months. Then a configuration error gave it access to a pricing model it shouldn't have seen. It started adjusting claim valuations based on pricing predictions. Nobody noticed for three weeks.

Their fix wasn't to add more human reviewers. It was to implement the Constitution. Scope was narrowed to a whitelist of approved actions. Permission boundaries were tied to underwriter authority levels. A circuit breaker was added: if the agent's approval rate deviated by more than 15% from the historical baseline, it paused and alerted the owner. The owner was named. Their bonus was tied to agent performance metrics.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#1a2540', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ffffff', 'lineColor': '#ffffff', 'background': '#0a0f1e', 'mainBkg': '#1a2540', 'nodeBorder': '#ffffff', 'edgeLabelBackground': '#1a2540'}}}%%
graph LR
    A["Agent observes
claim"] --> B{"Scope check"}
    B -->|"out of scope"| X["Block + alert"]
    B -->|"in scope"| C{"Risk tier"}
    C -->|"Low: €< 1k"| D["Auto-approve + log"]
    C -->|"Medium: 1-5k"| E["Async review"]
    C -->|"High: > 5k"| F["Human approval"]
    D --> M["Monitor baseline"]
    E --> M
    F --> M
    M -->|"deviation > 15%"| Pause["Circuit breaker"]
    style A fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style B fill:#1a2540,stroke:#ffb347,color:#ffffff
    style X fill:#1a2540,stroke:#ff6b6b,color:#ffffff
    style C fill:#1a2540,stroke:#ffb347,color:#ffffff
    style D fill:#1a2540,stroke:#00ff88,color:#ffffff
    style E fill:#1a2540,stroke:#00ff88,color:#ffffff
    style F fill:#1a2540,stroke:#00ff88,color:#ffffff
    style M fill:#1a2540,stroke:#00d4ff,color:#ffffff
    style Pause fill:#1a2540,stroke:#ff6b6b,color:#ffffff

The system didn't become slower. It became safer. And paradoxically, because the constraints were clear, the engineering team became more willing to give the agent additional autonomy in areas where the boundaries were well-tested.

Autonomy Needs a Constitution

Governance must be designed in, not reviewed in. A one-time approval process cannot govern a system making thousands of decisions per day. The organisations that treat agentic AI as a technology problem will find themselves with powerful systems they cannot control. The organisations that treat it as a design problem — embedding governance into the architecture itself — will find that constraint creates the conditions for safe, scalable autonomy.

Build the constitution before you deploy the agent. Not after the first failure.

Sources

Daniel Piatkowski Data & Analytics veteran shaping AI-native enterprises elicify.ai