Most production workflows only work because experienced people keep them alive. They know which CRM fields are outdated and which Slack messages cannot wait until tomorrow. None of this usually appears in the workflow diagram, but the business depends on it every day.

AI agents change that approach. Once an agent starts planning and executing steps on its own, the weak parts of the workflow become much harder to hide. And now, the judgment that used to sit in someone’s head has to be designed into the system: rules, permissions, escalation paths, approval points, and exceptions. Otherwise, the agent will not fix the ambiguity. It will simply execute it faster.

That is the job of an AI operating model. It is not another transformation framework or a slide with five pillars and a futuristic icon in the middle.

It is a working specification for how AI enters the business. What work can the agent do? Which systems can it read from? Where is it allowed to write? When does a human approve the next step? And who owns the result when the workflow is finished?

Without that specification, you are not really deploying agents into production. You are letting a system with judgment, uncertainty, and tool access operate inside the business without clear contracts.

What an AI Operating Model Means

In a traditional operating model, people use software to execute work. In an AI operating model, people, agents, and software systems execute work together.

In this model, businesses decide how work moves between a human, an agent, a CRM, an approval step, a monitoring layer, and sometimes a customer-facing system.

Before a company starts building agents, it should understand a few basic things about the system it is about to create. These questions are not a complete methodology. But they are the kind of questions we use when helping clients turn an AI idea into something that can survive inside a real workflow:

1. Scope: Exactly what work can the AI agent perform?
2. Access: Which systems of record and tools can it touch?
3. Approval: Which decisions require human-in-the-loop authorization?
4. Exceptions: What is the protocol when the agent is uncertain or blocked?
5. Ownership: Who is legally and operationally responsible for the result?

Deloitte's State of AI in the Enterprise 2026 shows the same problem at scale. AI access is growing faster than business redesign. More employees are using AI, and most companies expect to customize agents around their own processes, but far fewer report deep business transformation.

That is the gap an AI operating model is meant to close. It turns AI adoption into operational design: workflows, access rules, governance, infrastructure, roles, and metrics that can actually support agents in production.

Designing the Operating Model 

Redesigning the enterprise for agentic work requires a layered approach where governance, architecture, and operations are treated as inseparable.

1. Workflow Map: Define the Work Before the Agent

The first deliverable is the workflow itself, not the agent. Before any model is chosen or a prompt is written, the team needs a documented description of the work the agent will perform. It includes: 

• Trigger event
• Input data on which the work depends
• Decision points along the way
• Systems the work writes to
• Human approval gates that punctuate it

This sounds basic, and it isn't. The workflows that look simplest on a slide are usually the ones that survive in production through undocumented human judgment. A lead qualification workflow that runs cleanly in a kickoff meeting becomes, in practice, a sequence of small judgment calls about which records to merge and which leads to skip as duplicates of accounts already in the pipeline. The map has to capture the workflow as it runs, not as it appears in the SOP.

A useful workflow map is also a scope contract. Anything outside the documented trigger, inputs, decision points, systems, and approvals is outside the agent's authority. When the agent encounters a case the map does not describe, the right behavior is to escalate, not to improvise.

That constraint is what makes the agent's behavior reviewable later. Without a documented map, reviewing the agent's actions later requires reconstructing the workflow from the team's memory of it.

The map is the operational artifact. It is what a development team can implement, what a CTO can review, and what a compliance officer can audit. Until it exists, none of the downstream design decisions can be made with confidence.

2. Data and Context Layer: A Trusted Version of Reality

The workflow map defines what the agent is supposed to do. The data and context layer determines what the agent has to know to do it. Agents do not infer business reality from scratch. They operate on what they can read at runtime. If the data they read is incomplete or contradictory across sources, the agent's actions inherit those problems.

Two failure modes are worth naming. The first is direct: the agent reads a stale field and acts on it. The second is subtler. The agent reads correct data, but the data does not include the context a human would have used to interpret it.

A customer's NPS score in isolation looks like a metric. The same score read alongside the customer's contract value, recent support tickets, and renewal date looks like a decision input. The agent operates on whatever context the data layer chose to surface, and no more.

Most production data lives across three or four systems of record, maintained by different teams, on different refresh cycles, with different definitions of what counts as authoritative. The agent does not know any of that. It reads what the integration layer surfaces and operates on it as ground truth.

That’s why the data layer has to handle memory. Memory in the agent sense is broader than session state. It is the mechanism by which agents accumulate context across runs and avoid restarting from zero on every invocation. Four kinds matter:

A note on graph-based memory, which is where most agent architectures eventually run into trouble. Vector similarity is good enough for "find similar passages" but not for "trace this entity's relationships across five hops." For an agent operating on a multi-tenant SaaS platform, a regulated FinTech workflow, or any system where entities have meaningful relationships to each other (customer → contract → invoice → payment → renewal), graph-aware memory is what makes multi-step reasoning reliable.

3. Scope and Authority

Two decisions sit underneath what most teams call "what the agent does." The first is the scope of the class of work the agent is assigned. The second is authority: how independently it is allowed to act on that work. These look similar from outside the system, but they are different problems and require different controls.

On scope, departmental framings ("a finance agent," "a sales agent," "a support agent") tend to fail in production because they describe an organizational unit, not a unit of work. 

A finance agent that handles "everything finance-related" inherits the ambiguity of the finance function itself. Production-grade scoping ties an agent to a specific responsibility: research a counterparty before a deal closes, classify an incoming ticket against a defined taxonomy, and validate a transaction against compliance rules. 

Each responsibility comes with its own inputs, outputs, and failure modes. Where workflows need multiple steps, several specialized agents coordinate. Each remains scoped to a single reviewable unit of work.

In authority, the relevant question is where the team draws the threshold for accepting autonomous action. Four tiers cover most production deployments:

Scope and authority together define what the agent is for and how much independence the team grants it at each phase. Without those decisions made up front, agent rollout becomes a continuous improvisation in which engineers, ops, and the business renegotiate the agent's role every time something goes wrong.

4. Boundaries and Runtime Control

Once an agent has scope and authority, the next decision is where it can reach and what stops it when it goes wrong. Teams decide the boundary at design time and runtime control enforces it when the agent encounters edge cases the team did not anticipate.

The framing that gets this right is treating a deployed agent as a digital insider with write access. The team that ships the agent has granted internal API privileges to a non-deterministic actor. That requires the architectural discipline used for human privileged access, plus several controls specific to agents.

Four controls do most of the work in production:

Two practices sit alongside the controls:

• Red teaming. Probes for vulnerabilities specific to agents: indirect prompt injection through retrieved documents, tool-call manipulation, exfiltration through legitimate channels.
• Liability assignment. The organization that defined the agent's authority and controlled its environment carries the result when something fails.

Both decisions have to be made before the agent ships. Skipping either one leaves the team improvising in production.

5. Measurement Model: Workflow Improvement over AI Activity

Once an agent is in production, the question becomes whether the workflow has improved. Most teams answer this with the wrong metrics. Token usage and adoption rates measure how much the AI was used, not whether the work got better.

Useful measurement separates outcome metrics (was the workflow better?) from operational health metrics (is the agent behaving as designed?). Both matter, and they require different instrumentation.

Read metrics against the autonomy tier:

• Shadow. Track agreement rate. Does the agent's suggestion match what the human would have done? Low agreement is a calibration signal, not a deployment failure.
• Supervised. Watch approval rate and time-to-approval. Reflexive approvals mean the human is rubber-stamping. Slow approvals mean the workflow is no faster than the manual one.
• Guided. Containment rate and override rate. A high override rate means the boundary is wrong.
• Autonomous. Outcome quality against the business KPIs that the workflow already had.

What the operating model should not measure: how much AI was used. Adoption metrics tell the team that AI is being touched, not that it is producing better work. Make the operational metrics the primary scorecard.

6. Accountability Model: Names on the Hook

Accountability decides who answers for the system when it isn't working. Without that decision made up front, autonomous failures get distributed across the model provider, the platform vendor, the integration team, and the business unit until no one carries the result. Accountability diffusion is the predictable end state when ownership is left undefined.

The operating model assigns named individuals to specific roles. Four cover most production deployments:

Two structural notes about how these roles relate:

• Business Owner and Technical Owner are dual-key. Together, they decide whether the agent ships, expands scope, or moves to a higher autonomy tier. Neither can act alone.
• Data Owner and Model Oversight are specialist functions. They report to one or both of the dual-key owners, depending on the organization's structure.

A practical test: when the agent produces an unexpected outcome, the team should be able to name within five minutes which of these four roles owns the response. If the answer requires a meeting to figure out, the accountability model is not in place.

The six decisions covered in this section define the operating model: workflow, data and context, scope, authority, runtime control, and measurement. Naming the owners is what makes those decisions enforceable.

A CEO/CTO Decision Filter: Are You Ready for an AI Operating Model?

Before building or scaling an agent, run the operating model through a diagnostic. Six questions, one per design decision. The aim is to surface gaps that should be closed before deployment, not to gate the project.

The filter is a diagnostic, not a gate. Teams that can answer all six confidently can ship an agent. Teams that can't have a clear specification of what to design before they do.

Conclusion

The framework above is most useful as a map, not as a project plan. Few organizations need to redesign the entire operating model at once. Most need to apply the six decisions to a single workflow, ship the resulting agent, learn what the framework missed in their specific context, and then expand from there.

Choosing the right first workflow matters more than choosing the right model. The strongest candidates have three properties: high enough volume to make automation worthwhile, well-enough documented to be scoped without months of discovery, and a contained enough blast radius that a failure costs effort rather than customers or compliance posture. In Codebridge's delivery practice, the typical first workflows look like:

• Compliance triage in a regulated FinTech workflow, where the agent classifies cases and routes the ambiguous ones to humans
• Patient intake or scheduling in a HealthTech platform, where the agent reads structured records and surfaces the cases that need clinical review
• Knowledge retrieval inside a tax or legal advisory team, where the agent pulls relevant precedent and lets the specialist make the judgment

Before development begins, the six design decisions should be written down in one place. Not a 40-page strategy deck. A specification short enough to be read in one sitting, naming the workflow, the data the agent will read, the scope and authority tier, the boundaries and runtime controls, the success metrics, and the four named owners. Once that document exists, the build work is buildable. Without it, the team is shipping against assumptions no one has agreed to.

The advantage in the agentic era will be operational. Production software has long run on a hidden subsidy of human judgment. Agents move that work onto the documented system, which means the documented system has to be worth running on. The operating model is what makes it worth running on.