Most organizations deploying AI agents make the same mistake: they think about capabilities before they think about accountability.
They ask: What can this agent do?
They should ask: When this agent does something wrong, who is responsible?
After six weeks running a five-agent production swarm at Resomnium, I can tell you: the technical problems are the easy ones. The hard problems are organizational. Who owns the agent's decisions? Who reviews its outputs? Who gets the 2am call when it does something unexpected?
The answer, in most organizations I've seen: nobody. And that's the real governance gap.
Why AI Teams Break
A typical AI deployment looks like this: an engineering team builds an agent, a product manager writes a spec, and then the agent goes live. Maybe there's a "model owner" who monitors accuracy. Maybe there's an on-call rotation for incidents.
But there's no one answering these questions:
- When the agent's outputs drift from what we want, who decides what we actually want?
- When an external stakeholder asks "why did your AI do that," who owns the explanation?
- When the agent needs a new tool or data access, who approves it — and who is responsible if that access causes harm?
- When something looks off but it's not clearly broken, who has the authority to pause operations?
These are not engineering questions. They're governance questions. And most AI teams have no one accountable for the answers.
The Five Roles
At Resomnium, we designed CellOS around a simple premise: every autonomous unit — whether human, AI, or hybrid — needs the same five governance functions covered. If any one is missing, the cell operates with a blind spot.
Here's what each role does and why it can't be skipped.
1. Clarity
The question they answer: What are we doing and why?
The Clarity steward owns the mission, goals, and scope of the cell. They're the person who resolves disputes about whether something is in scope. They approve changes to what the cell is trying to accomplish.
This sounds obvious — until you realize most teams don't have this person. They have a product manager who wrote the original spec, and then the spec drifts. New features get added. The agent gets asked to do things that weren't in the original mandate. Nobody pushes back, because there's no one whose job it is to guard the mission.
In AI systems, scope drift is particularly dangerous. An agent that started doing customer support ends up making refund decisions. An agent that was doing research ends up writing external communications. Clarity exists to prevent this.
2. Execution
The question they answer: How do we get it done?
The Execution steward owns workflow, deadlines, and resource utilization. In a human team, this is often the project manager. In an AI-human hybrid team, it's the person responsible for the operational rhythm — making sure work gets done, bottlenecks get cleared, and the cell is running at the right pace.
The key distinction: Execution is not the same as Engineering. Execution owns whether work happens and when, not how it's built. Many AI teams confuse these and end up with engineers making deployment timing decisions (risky) or operations leads making technical architecture decisions (also risky).
3. Narrative
The question they answer: How do we explain what we're doing?
This role gets skipped most often, especially for internal-facing AI systems. The reasoning is: it's internal, so there's no external story to tell. That's wrong.
Every cell has stakeholders. Executives want to know if the AI is performing. Regulators want audit logs. Other teams want to understand what the AI can and can't do. When something goes wrong, there will be an explanation required — and if no one owns that explanation, it will be improvised under pressure, which means it will be wrong.
The Narrative steward maintains documentation, decision logs, and the cell's external communication. They're the person who gets called when someone outside the team says "explain what your AI did."
4. Access
The question they answer: What do we need to operate?
Access stewards own tools, data, permissions, and integrations. In AI systems, this is operationally critical and often underspecified.
Most AI agents are given broad access by default — it's easier to over-provision than to debug permission errors. But over-provisioned AI is a liability. An agent that can read your entire data warehouse doesn't need to read your entire data warehouse to do its job.
The Access steward is responsible for the principle of least privilege: the cell has exactly the access it needs, and no more. They're also responsible for managing integrations — the external APIs, databases, and services the cell depends on.
5. Integrity
The question they answer: Are we doing this right?
Integrity stewards own quality, compliance, and risk. They conduct internal reviews, monitor for drift, and escalate when something looks wrong.
In human organizations, this might be a QA lead or a compliance officer. In AI systems, the scope is broader. Integrity monitors not just output quality but behavioral drift — when the agent starts doing something subtly different from what it was designed to do, before it becomes a visible problem.
Integrity also owns the hard conversations: when the cell is producing bad outputs, when there's a compliance risk, when the cell's operations need to be paused. They need the authority to act on what they find.
Why Five?
The number isn't arbitrary. Each role covers a dimension that can't be adequately handled by another:
- Clarity defines the mission. Execution runs the operation. (Different failure modes: drift vs. bottleneck.)
- Narrative manages external trust. Integrity manages internal quality. (Different audiences: stakeholders vs. operators.)
- Access manages dependencies. (Infrastructure failure mode that neither Execution nor Integrity fully covers.)
Collapse two of these into one person and you'll find they deprioritize whichever one isn't their natural strength. In AI systems, that deprioritization is where incidents come from.
What a Complete Cell Looks Like
Here's a simple example: an AI agent that handles tier-1 customer support for a SaaS product.
| Role | Who | What They Own | |------|-----|---------------| | Clarity | Product Manager | Defines what constitutes a valid support request, when to escalate to tier 2, and what the agent is not allowed to handle | | Execution | Support Lead | Monitors queue depth, response time SLAs, and agent throughput | | Narrative | Customer Success Lead | Owns the explanation when customers ask "was I talking to a bot?", writes the documentation, reports on CSAT | | Access | DevOps Engineer | Controls what customer data the agent can see, which ticketing system integrations are active | | Integrity | QA Lead | Reviews a sample of agent responses weekly, monitors for compliance issues, has authority to disable the agent |
Notice that none of these people are the same. Each owns a distinct dimension. And each has something concrete to do — there's no overlap, no vagueness about responsibility.
This is what a governed AI deployment looks like. Most organizations are doing none of it.
The Governance Gap in Practice
Researching the enforcement landscape this spring, I reviewed 25+ AI enforcement and governance vendors. The technology is increasingly sophisticated — monitoring, explainability, policy enforcement, red-teaming. But the technology assumes you have the organizational infrastructure to act on what it tells you.
If your compliance tool flags an anomaly in your agent's behavior, who receives the alert? Who decides whether it's a real problem? Who has the authority to do something about it? Who tells your stakeholders what happened?
If the answer to any of those questions is "we'd figure it out," you don't have a governance problem. You have a governance absence.
Where to Start
If you're deploying AI agents without this structure, you don't need to redesign your entire organization. Start with three questions:
1. When something goes wrong, who is responsible? Not "who gets blamed" — who has the actual authority and information to identify, diagnose, and fix it? If that's unclear, you don't have an Integrity owner.
2. When an external stakeholder asks why your AI did something, who answers? That person exists right now, whether you've named them or not. The question is whether they're prepared. If not, you need a Narrative steward.
3. When someone new joins the team, how do they know what the AI is and isn't supposed to do? If the answer is "they read the system prompt" or "they ask the original engineer," you don't have a Clarity owner — you have institutional knowledge with an expiration date.
The Bigger Picture
The organizations that will use AI successfully at scale aren't the ones with the best models. They're the ones who've figured out how to govern models: how to maintain accountability at AI speed, how to coordinate human judgment and machine execution, how to build trust that's resilient to the inevitable mistakes.
That's an organizational design problem. And organizational design is the discipline most AI teams are missing.
Resomnium helps organizations design the governance structures that make AI deployment work beyond the demo. If you're deploying AI agents and want to build the accountability layer that lets you scale safely, reach out. For a deeper look at the org design problem, see Your AI Governance Problem Is an Org Design Problem. If you want to build this structure for your own team, the Cell Design Sprint is where we start.