The Operating Model

Part IV of Between Panic and Euphoria

By Daniel Dines with Claude and GPT.

Parts I and II made the case that the model is not the whole system; Part III named the work that remains human. This part turns the case into an operating model: the deployment rules that follow from the model’s limits, the five rights that assign ownership, and the first two of the four stages through which a domain matures.

Parts IV through VII are the build guide. The first three parts made the argument; the next four are the operator’s manual. If you are an employee, read them as a map of where durable work moves. If you are a leader, read them as a build sequence. The operating model becomes a program:

We designed enterprises for humans. Now we have to design them for agents. Humans could fill in missing context because the business was built around them. Agents need that context made visible: objects, states, cases, stages, rules, permissions, gates, owners, and execution rails.

Start with one meaningful workflow. Do not start with a general question about where the company can “use AI.” Name the business objects the workflow moves, the states those objects can be in, the work people and systems perform, the decisions that choose the path, and the actions that create consequence. Then decide what the model should propose, what a human must decide, what deterministic systems should execute, and what hidden human output must be preserved or rebuilt. The workflow is the unit of design, not the model.

Four limits, four deployment rules

Part II argued that the model is powerful but not the whole system. Its four limits now become deployment rules.

1. No self — mark where the company still needs a named human

The model can pursue delegated goals. It does not originate commitments, carry standing by name, hold culture under pressure, or bear career cost when wrong.

The deployment rule is simple: use AI for delegated work, but keep named humans where the institution needs initiative, relationship, culture, and commitment.

This is not sentimental. It is operational design. In every workflow, mark the points where someone must own the call by name: customer relationships, policy exceptions, cultural lines, high-consequence overrides, unclear escalation paths.

The model can prepare the move, but it cannot become the person who owns the commitment.

2. Tokens do not bear consequences — separate language from action

A model explaining a process is not the same as a system acting inside that process. Before action, the system must know state, permission, rule, source, consequence, audit, rollback, and owner.

Tokens do not bear consequences. People do. If those are not explicit, the model should not act. A fluent recommendation is not a control. Capability is not permission. Capability says the model can produce the move. Permission says the institution allows the move, under defined authority, with evidence, preconditions, rollback, audit, and a named owner.

Permission is not accountability. Accountability requires consequence reception: if the move is wrong, the consequence must land somewhere that can change future behavior. A human gate is not real unless the reviewer sees the evidence and the consequence of approval, has meaningful control before the action, and can constrain, override, or stop the system.

3. People read the room — translate the room into review signal

People read the room: history, hesitation, tone, trust, exception, pressure, and consequence. Models need that room translated into captured institutional context.

The deployment rule is to turn every approve, edit, reject, and escalate decision into usable signal: examples, corrections, reason codes, escalation paths, permissions, workflows, tests, audit, and review data.

A click is not learning. A reasoned correction is learning. Stage three — event-triggered work with a human at the gate, defined below — matters because it captures the missing institutional context while real work is running. And teaching is real only if the system changes before the next run.

4. Good enough is not good — define the guarantee

Some work can be good enough. Exact work — payroll, a ledger, a payment instruction, a tax calculation — cannot.

Good enough for language is not good enough for execution. Never make the model the reliability boundary for work that must be correct.

The reliability boundary is the part of the system you trust when the answer must be right. Use calculators for arithmetic, databases for records, rules engines for policy checks, payment rails for payments, workflow engines for state transitions, system logs for audit.

The model can recognize the need and route the work; the deterministic system executes.

The operating model as assignments

The slogan becomes real only when rights are assigned. For every meaningful workflow, name five rights.

At low maturity, one human may hold all five rights.

At higher maturity, the model proposes, deterministic systems verify facts, a human or policy approves, automation executes, and a named business owner remains accountable.

The hard question is not whether the model can do it. The hard question is who owns it after the model does it. If nobody can answer, the workflow is not ready. If the named owner lacks meaningful control, the owner is not accountable; the owner is a crumple zone — positioned to absorb the blame without the control to prevent it.

Accountability is not attribution. A dashboard can say which agent failed; that is not enough. The person who bears the consequence must have evidence, control, and a way to change the next run. Stage three makes this concrete at the validation gate.

The four stages

Enterprise AI matures in four stages.

The stages describe how a domain learns. They do not by themselves grant permission to act. Permission comes later, workflow by workflow, through the trust-class ladder defined in Part VI. This part walks the first two stages, where the organization learns. Part V takes up the third and fourth, where consequence enters.

Stage one — human asks, AI answers

The analyst asks the assistant. The model answers. The human reviews. No agent loop. No tool calling. The human carries everything.

This is where most companies started.

Stage one changes individual work. It produces visible productivity but often little organizational movement. More memos. More summaries. More code. The queue after the output often stays the same.

The employee is faster. The company may not be. That gap matters. Individual productivity is not enterprise productivity until the surrounding workflow changes.

Stage two — advanced agents, skills, tools, and business automation

Stage two is not a chatbot answering a question. It is an advanced agent running inside a harness, with a human watching.

Be precise about the word harness. The harness is not the repo. It is not the terminal. It is not the invoice system. It is not the CRM. Those are work systems or implementation tools.

The harness is the controlled environment around the agent: permissions, context, memory, logs, available tools, approval rules, execution limits, and human supervision.

In ordinary AI language, the agent uses tools. That is runtime language. It should not become the language of the business.

Business users should talk about workflows and automations.

A workflow is the description of work. It names the entities, object states, case stages where relevant, activities, decisions, gates, exceptions, owners, and consequences. It can describe work that is manual, agent-assisted, partially automated, or fully automated. The workflow is the map of the work, not the thing being called.

An automation is executable work. It is a stable workflow path, or part of one, moved onto deterministic rails. It has a trigger, sequence, rules, object-state changes, case-stage transitions where relevant, exception path, owner, audit, and failure behavior. Automation is the workflow logic turned into running machinery.

A tool is a controlled callable capability. From the IT side, it looks like a procedure the harness or automation may invoke: an API call, connector, script, query, calculation service, operational routine, or run-book. It has inputs, permissions, credentials, logs, error behavior, forbidden uses, and an owner.

From the business side, the tool is only the handle. It may retrieve a record, run a calculation, validate a policy, open a ticket, prepare an artifact, or update a system. It supports the work. It is not the workflow and not the business outcome.

In the business picture, an agent may use tools, an agent may invoke approved automations, an automation may use tools, and a workflow governs all of them.

Some agent platforms will label an automation trigger as a tool because, at runtime, the agent sees a callable handle. That is implementation language. In the business architecture, the thing being triggered is an automation, not a workflow and not just a tool.

Do not ask, “Is this a tool or an automation?” Ask what work is being described, which stable path should run automatically, and what controlled capabilities the agent or automation may use. Those controlled capabilities need tool cards.

For example, invoice exception review is a workflow: it describes the entities, object states, case stages where relevant, activities, checks, approvals, and exception paths. The invoice exception review automation is the executable path for the stable parts: retrieve the invoice, check the vendor, compare the PO, calculate variance, prepare the review packet, and route the exception. The agent may invoke that approved automation, or it may use smaller tools for individual steps under human supervision.

Stage two is where the enterprise starts turning repeated work into reusable work packages.

A skill is one of those packages. It is not just a prompt. It is a small operating manual: when to use it, what inputs it needs, which entity and metadata it touches, which system of record is authoritative, what steps it follows, what tools it may use, what automations it may invoke, what it must not do, what output it returns, and when it escalates.

A good skill library is how the map begins. A skill is the human-readable form of emerging substrate. It names the entity, metadata, system of record, activities, decisions, allowed tools, forbidden tools, approved automations, escalation rules, output format, and reason codes before all of that is formal enough to become deterministic automation.

The agent is not the durable asset. The map is. Models change. Harnesses change. Vendors change. A reusable skill library, tied to tool cards and automations, lets the institution carry its knowledge from one generation of agents to the next.

Stage two also creates the practical bridge from agent-assisted work to deterministic automation. In early use, the agent may call tools while the human watches. Over time, the repeated manual paths become visible. When a repeated path becomes stable enough, it should not remain inside a probabilistic agent loop. It should become automation.

Automation is not a bigger tool. It is the business path after the gray zone has been reduced.

This matters economically. A path running thousands or millions of times should not live forever inside a screen-driving or free-form reasoning agent. Runtime cost, latency, fragility, and audit gaps become too large. Stable work belongs on rails.

Stage two changes teams. It makes professional builders faster, brings citizen developers into work they could not previously do, and gives the enterprise practical evidence before Stage three can be safe.

The Stage-two training program

Stage-two adoption is not a software rollout. It is a work-practice change. People have to learn how to delegate to advanced agents. That is closer to managing a very fast junior colleague than using a search box.

Train people on five practices.

1. Delegation. Give the agent the goal, context, constraints, sources, and definition of done.

Bad delegation:

Check this invoice.

Good delegation:

Prepare this invoice exception for AP review. Use the invoice, PO, vendor record, contract, prior invoices, and AP policy. Do not approve payment. Cite every factual claim. Return the exception type, missing evidence, recommendation, confidence, and proposed next step.

2. Activity judgment. Teach people what kind of work they are asking the agent to perform.

Retrieval helps the model know. Computation helps the system verify. Drafting helps the human think. Recommendation takes a position. Preparation stages the work. Action changes the enterprise. Transaction commits the change.

A business user has to know which one she is asking for. The interface may look like one button. The consequence underneath is not one thing.

3. Skill writing. Turn repeated prompts into reusable skills.

A good skill names the goal, inputs, sources, steps, tools, forbidden tools, output format, escalation rules, and reason codes. If the skill cannot be written clearly, the work is not ready for automation.

4. Tool creation. Business users should not wait for the platform team to guess what tools they need. They should write tool cards.

A tool card is where business need becomes a safe IT procedure. The business names the capability the agent or automation needs. IT defines the callable handle: inputs, permissions, credentials, system touched, output, logs, failure behavior, and forbidden use.

A tool card is not an automation design. It is the contract for a callable capability. Its job is to define what an agent or automation may use and what must never happen accidentally.

Who creates ‘retrieve_invoice’? Not the model by itself. A business user names the need. The AP process owner defines the business meaning: what counts as the invoice record, what metadata must return, which system is source of truth, and what the tool must never change. The platform or automation team implements the run-book, connector, API, or automation interface. Security and data owners approve access. The cartographer records the tool in the map of the work.

For low-risk retrieval and computation tools, trained citizen developers may build or configure them inside a governed platform. For preparation tools, the platform team must make sure nothing changes without approval. For action and transaction tools, production engineering, security, risk, and the business owner must sign off.

The boundary is consequence.

5. Workflow and automation spotting. Teach people to distinguish the description of work from the executable path.

Tool creation asks: what controlled procedure should the agent be allowed to call?

Workflow spotting asks: what work path are we describing, including its object states, case stages where relevant, decisions, gates, exceptions, and owners?

Automation spotting asks: what business work are people doing by hand that no longer needs judgment at every step?

If the work is repeated and rule-based, automate it now. Expose it to the agent only if the agent needs to invoke it, query it, or prepare inputs for it.

If the work is repeated but gray-zone, capture it as a skill and let the agent help under supervision.

If a skill becomes stable, move the stable business steps into automation and leave the exceptions with the agent and human.

If automation hits exceptions, route those exceptions back to the agent and human. Stage two explores the work, automation locks in what has stabilized, and stage three governs the loop.

This is the practical bridge from individual productivity to enterprise productivity. Stage one makes one person faster. Stage two makes teams faster when repeated work becomes workflow descriptions, skills, callable tools, and deterministic automations. These are not four names for the same thing. Stage two becomes operating leverage when the repeated paths stop living only in prompts, chat histories, and human memory and start becoming reusable work packages. Stage two is where the enterprise learns how to verify agent work at the edge.

For employees, Stage two is the practical training ground. The durable move is to learn to delegate to agents, write skills, spot automations, validate outputs, and understand the workflow underneath the work. The people who learn that layer early will be closer to the new operating system than the people who only learn to prompt for better drafts.

Most Stage-two work stays low-consequence: draft, summarize, retrieve, compute, recommend. The human still triggers the work, watches the agent, checks the output, and redirects when needed.

More mature Stage-two work can prepare an action for approval: create a draft case, update an internal note, open a proposed ticket, generate a proposed workflow, run a test automation, or assemble a review packet.

But the point of Stage two is not autonomy. The point is evidence. The enterprise learns which outputs are useful, which tools are safe, which checks are cheap, which paths repeat, which workflows are understood, and which parts of the work should become deterministic automation.

Do not confuse that with Stage three. Stage three begins when the trigger is no longer the human request but the business event, the output is a structured proposal, and the validation gate is governed.

Stages three and four are where consequence enters: the work is triggered automatically, the agent proposes, and a human validates at the gate. That is Part V.

Drafted and edited with AI assistance. The argument, the examples, and the responsibility are mine.