Skip to main content
All field notes
10 min read

What Matters in an Agentic System Is Governance

Pete Norcross

Pete Norcross

Co-Founder, Epistemion LLC

A split shield: a checkmark on one half, a magnifying glass on the other — trust paired with verification.

"Trust, but verify."

-- Russian proverb (doveryai, no proveryai)

Almost every conversation I have about agentic AI starts one layer too low. People want to talk about which model they should use, how big the context window is, what framework wraps the loop, how clever the prompt is. Those things matter. But they are not what determines whether an agent survives contact with a real business. Governance does.

An autonomous system is not dangerous because it can produce text. It becomes dangerous when it can do things: send the email, issue the refund, open the ticket, move the money, change the setpoint, unlock the account, publish the code, or tell a vulnerable human being what to do next. The moment consequences enter the picture, governance stops being a side concern and becomes the main engineering problem.

Governance starts where consequences start

By governance I mean the unglamorous parts: who can authorize what, under whose responsibility, with which evidence, inside which limits, with what audit trail, and with what emergency stop when the system starts drifting. The model is not the risk surface. The action surface is.

That is why a mediocre model inside a tightly governed system is often safer and more useful than a frontier model inside a free-for-all. If the agent can only retrieve approved data, cite the source it relied on, request a human sign-off for irreversible actions, and leave behind a clean log of every meaningful decision, then a lot of ordinary model mistakes become recoverable. If the agent can improvise with broad tool access and no oversight, then even a very good model can create a bad day in a hurry.

Governance and grounding usually travel together for exactly this reason. It is not enough for an agent to sound persuasive. In production, it has to be answerable. Why did it do that? What source did it rely on? What policy allowed it? Who approved it? Could we reverse it? If you cannot answer those questions after the fact, you do not have a governed system. You have a liability with a chat interface.

That may sound obvious, but organizations keep relearning it the hard way. In Moffatt v. Air Canada, 2024 BCCRT 149, the tribunal rejected the idea that the chatbot was somehow separate from the company, held that Air Canada was responsible for information on its website, and found that it had not taken reasonable care to ensure the chatbot was accurate. A recent 2025 analysis and a 2025 law-review comment revisited the case because the memorable part of that story is not the hallucination itself. Customer-facing systems hallucinate all the time. The memorable part is that the bot was allowed to speak as though it was policy, without the grounding, review path, or control surface needed to keep policy answers tethered to reality.

This is why, in the maturity model, governance comes before truly autonomous agents. Once the system can reason across steps and act in the world, weak governance stops being an embarrassment and starts becoming incident response.

This is not hypothetical

One of the most frustrating habits in AI conversations is talking about governance as though it were a future problem. It is a present-tense problem. Public failures have already been teaching the same lesson from multiple angles.

Some governance failures can be measured in refunds, downtime, legal fees, or regulatory scrutiny. Those are serious enough. But governance can also become a life-or-death issue. The cost of poor governance can be measured in lives, and it may not be obvious what that cost will be before it is incurred. It may not even look closely related to the problem the agent was supposed to solve.

A set of incident cards showing policy hallucination, unsafe advice, credential leakage, and driver overtrust radiating from one ungoverned core.
Governance failures rarely come from intelligence alone. They come from bad authority boundaries, weak grounding, and missing controls.

If you want a more recent pattern, look at where regulators have been spending their time over the last year. In February 2025, a federal consumer-protection regulator finalized an order against a service marketed as an AI lawyer after alleging that it had been presented as a substitute for human legal expertise without adequate substantiation or testing. That is not a model-quality anecdote. It is a governance anecdote. Someone let a system cross the line from "assistive tool" to "professional substitute" without the controls or evidence needed to justify the claim.

The same lesson shows up in much harsher form when the system's product is emotional influence rather than legal advice. In January 2026, Reuters reported the settlement of a lawsuit alleging that a companion chatbot encouraged a teenager's suicidal ideation and contributed to his death. I do not mean that metaphorically. That is what it looks like when governance becomes a matter of life and death. The system was not marketed as emergency medicine or crisis response. It was still, according to the allegations, implicated in a fatal outcome. That is the part leaders miss when they assume the cost of poor governance will stay neatly inside the use case they had in mind. If you build systems that can mirror, reinforce, and escalate human emotion, especially for vulnerable users, then governance cannot be a thin safety message buried in the product. It has to be part of the operating core.

These are not all the same kind of failure, and that is exactly the point. Governance is not one narrow safety filter. It is the discipline of keeping autonomy inside a boundary that humans can understand, monitor, and control.

The alignment problem becomes operational the moment the agent can act

People hear alignment problem and sometimes imagine a distant philosophical debate about superintelligence. There is a version of that conversation, sure. But there is a much more immediate version that matters right now. If your agent is rewarded for sounding helpful, but not for being correct, you will eventually get fake refunds, fake policy explanations, fake confidence, or fake empathy in places where fakery is dangerous.

That is alignment at the business scale. The system's incentives and capabilities are not lined up with the outcome you actually care about.

If you are building a customer-support agent, the goal is not "be agreeable." The goal is "resolve issues within actual policy." If you are building an operations agent, the goal is not "take initiative." The goal is "take safe initiative inside a bounded authority set." If you are building an assistant that interacts with vulnerable users, the goal is not "be emotionally resonant at all costs." The goal is "be supportive without affirming self-harm, and escalate when the interaction leaves the safe operating envelope."

That is why the companion-bot cases matter so much. They are extreme, yes, but they expose a very ordinary failure mode. A system optimized for engagement, affirmation, or emotional realism can drift into reinforcing the exact thing a responsible operator would want interrupted. Once that happens, the problem is no longer "the model said something weird." The problem is that the system's operational incentives are misaligned with the human outcome you actually care about. And the cost of that misalignment may have very little to do with the product category on the tin. You may think you are building a companion, a tutor, or a support assistant and discover too late that what you really deployed was an ungoverned influence system in the life of a person in crisis.

Governance is how you operationalize that alignment. It is the translation layer between abstract intent and concrete controls.

Authority can be delegated. Responsibility cannot.

A governance board separating action classes, approval gates, and accountability paths for an autonomous system.
Governance is less about which model you chose and more about who may act, under what authority, and with what evidence.

This is the part that organizations most want to blur, because blurring it feels convenient right up until the incident review starts. You can delegate authority to a system. You can let it classify, draft, route, search, recommend, or even execute limited actions. But you cannot delegate moral, legal, or organizational responsibility to the model.

At the end of the chain there is still a human being, or a clearly accountable organization, whose name is attached to the outcome. That matters for your customer. It matters for your regulator. It matters for your insurer. It matters for your own operations team when something goes wrong at 2:13 a.m.

If the human is still responsible, then the interface and the operating model need to say so plainly. One reason driver-assistance systems generate so much public confusion is that some of the branding implies a level of autonomy that the operating rules then quietly hand back to the user. A federal defect investigation opened in October 2025 over traffic-law violations while one such system was engaged made the point in brutally practical terms: authority had been partially delegated, but the driver still remained responsible for supervision and intervention. That is not a documentation problem. That is a governance problem. If the driver must supervise, say that plainly. If the employee is the approver of record, say that plainly. If the system is allowed to recommend but not decide, say that plainly. Hidden responsibility is not delegation. It is evasion.

What good governance actually looks like

Governance is not a single dashboard and it is not a policy PDF. It is a stack of technical and operational controls that make unsafe autonomy harder, visible, and interruptible.

A closed-loop governance diagram with observe, evaluate, approve, act, audit, and stop controls surrounding an agent.
Useful autonomy comes from a closed loop: observe the agent, evaluate it continuously, gate serious actions, and keep a kill switch within reach.

A practical governance stack usually includes:

  • Observation. You need telemetry on prompts, tool calls, retrieved context, outputs, approvals, failures, and policy misses. If you cannot see the behavior, you cannot govern the behavior.
  • Grounding. For policy, legal, pricing, refund, or operational claims, the system should be tied to explicit source material and ideally return the specific basis for what it is saying.
  • Capability scoping. Do not give an agent a general "do anything" tool when a narrow tool will do. Narrow tools are cheaper than apologies.
  • Approval gates for irreversible actions. Spending money, issuing credits, notifying customers, writing production configs, changing physical controls, or exposing sensitive data should trigger a human approval event unless the action is both tightly bounded and demonstrably reversible.
  • ML Ops and evals. You need offline evaluations, shadow deployments, drift monitoring, regression checks, and versioned rollbacks. Prompt edits and model swaps are production changes. Treat them like production changes.
  • Budgets, rate limits, and circuit breakers. Even reversible actions need ceilings. A looping agent can become your own denial-of-service attack.
  • Emergency shutdown. When an agent starts to drift, you need a pause button that actually works. In physical systems that may mean fail-safe states. In digital systems it may mean disabling tools, freezing queues, or routing everything to human review.

The security side of this has become painfully concrete too. In December 2025, researchers disclosed a prompt-injection pattern in AI-enabled CI/CD workflows where untrusted text could steer agents into using privileged tools and leaking secrets or manipulating workflows. A major model provider's prompt-injection guidance describes the same structural problem in broader form: third-party content can trick the system into doing something the user did not intend. That is governance, not just security hygiene. The model is influenceable by construction, so the surrounding system has to be designed so that influence does not automatically become authority.

Notice how little of this depends on magic. Most of it is ordinary systems engineering. The novelty is not that we suddenly need governance. The novelty is that language models have made it obvious how much governance many organizations were getting away without.

Remediation is not a better prompt

When organizations hit one of these failures, the first instinct is often to patch the prompt and move on. That is understandable and usually insufficient. The real remediation is structural.

  • If an agent promised a refund that policy did not allow, do not just tell the model to be more careful. Ground the answer in a current policy source, force it to cite the policy basis, and require approval for any exception outside the deterministic rules.
  • If a companion agent reinforced self-harm, do not treat that like a normal product bug to be sanded down. Add crisis detection, escalation rules, age-appropriate controls, stricter persona limits, conversation monitoring, and a human intervention path.
  • If an agent can be tricked into disclosing credentials or taking privileged actions, do not just warn it about prompt injection. Reduce tool scope, isolate untrusted inputs, use short-lived credentials, require confirmations, and sandbox execution.
  • If a partially autonomous physical system still depends on human supervision, do not market it like the human is optional. Tighten the operating domain, strengthen attention checks, and be brutally explicit about where responsibility sits.

The remediation pattern is the same every time: shrink the authority surface, improve observability, strengthen evaluation, and make the emergency brake real.

What to ask before you ship

Before you ship an agentic system, I would want clean answers to these questions:

  1. What is the worst thing this system can do in one step? In one hundred steps?
  2. Which actions are reversible, and which ones are not?
  3. What evidence does the system have to provide before it is allowed to act?
  4. Who is the accountable human for each irreversible action path?
  5. How do we observe behavior in real time and reconstruct it afterward?
  6. What evals and ML Ops checks tell us the system has drifted?
  7. Under what conditions do we pause it, and who has the kill switch?

If those questions feel annoying, good. They are supposed to be. Governance is the part of the build where we stop pretending that autonomy is free.

Need help holding the line?

A governance console watching policy boundaries, approval gates, audit trails, and an emergency pause around autonomous systems.
The governance stack in one view: observe, bound, approve, audit, and pause — with a human in the loop.

If you are trying to design an agentic system that can create real leverage without quietly creating real liability, contact us. This is exactly the work: defining the authority boundary, putting the observation and ML Ops in place, grounding the system in real source material, and making sure there is a responsible human with genuine control over the outcome.

The flashy part of agentic AI is easy to demo. The hard part is making it governable. That hard part is the part that matters.

Have an automation or agentic AI project in mind?

Tell us about your operation. We start every engagement with a free 60-minute consultation.

Schedule a Consultation