From Copilots to Controlled Digital Operations

Abstract

Enterprises are moving from isolated copilots toward systems that coordinate work across data, applications, people, policies, and operational processes. The architectural challenge is not how to create more agents. It is how to make agent-driven work reliable enough to operate inside real organizations.

This paper proposes a Multi-Agent Orchestration Layer whose execution architecture is a Stateful Agent Graph. The graph coordinates specialized reasoning agents, deterministic services, human reviewers, enterprise systems, evidence, permissions, tasks, decisions, and persistent workflow state.

Much of the control architecture is not new. It is a durable-execution workflow engine — the lineage of BPMN, sagas, and distributed systems practice — with non-deterministic reasoning nodes inserted at the points where deterministic branching historically failed. Section 2 states plainly what is borrowed and what is genuinely different, because the differences are where the hard engineering lives: stochastic nodes, untrusted content that can influence control flow, evidence and decision provenance as a compliance requirement, model cost as a runtime variable, and graph versions that must survive their own in-flight instances.

The paper provides a fully worked execution trace with modeled cost and latency, deep treatment of four industries, implementation patterns, control models, a total-cost model, an operating model, a maturity path, a 90-day pilot blueprint, and an explicit set of conditions under which this architecture should not be built.

What this paper contributes

Most published material on agent architecture describes capability. This paper describes control. Six contributions distinguish it, and each is developed in a specific section rather than asserted in passing.

1. Inserting non-deterministic reasoning into durable enterprise workflows without surrendering control. The design question is not how to make agents more autonomous but where a stochastic node can be placed inside a proven durable-execution substrate without breaking the guarantees that substrate provides. → Sections 2, 4, 5

2. Evidence and trust as first-class workflow state. Evidence is not a log line. Every artifact carries provenance, a retrieving identity, a content hash, and a trust classification that determines how downstream nodes may use it. Trust classification is what makes the security model enforceable in code rather than aspirational in prose. → Sections 9, 12

3. Separating reasoning authority from execution authority. Agents that read untrusted content hold no write tools; components that execute consume only typed, schema-validated objects. This privilege split is the primary structural defense against indirect prompt injection, and it also produces cleaner accountability. → Sections 7, 12

4. Routing on evidence and deterministic verification rather than model confidence. Self-reported confidence scores are uncalibrated and non-stationary across model versions. Transitions should gate on evidence sufficiency, deterministic post-conditions, and independent verifier nodes. → Section 11

5. Treating model cost, graph versioning, evaluation, and recovery as production architecture concerns. Per-instance budget enforcement, version binding for in-flight instances, evaluation under non-determinism, and failure-domain isolation are architectural requirements, not operational afterthoughts. → Sections 14, 15, 16, 17

6. Providing a fit test for when agents should not be used. A reference architecture that recommends itself under all conditions is a sales document. Section 21 gives nine conditions under which something else should be built, and Appendix C scores candidate workflows against them.

Who this paper is for

CIOs, CTOs, CDOs, COOs, Heads of AI, Heads of Data and Analytics, platform leaders, risk and compliance leaders, operations executives, product leaders, and architects responsible for moving AI from experimentation into controlled enterprise execution.

A useful distinction

A copilot helps a person complete a task. An orchestrated agent system coordinates an end-to-end business process. The difference is not primarily the model; it is the architecture around the model — and the operating discipline around the architecture.

A note on figures and planning ranges

This paper contains two kinds of numbers, and they should be read differently.

Planning ranges — effort estimates, latency distributions, cost proportions — are illustrative figures based on representative enterprise workflow architecture, offered to show the shape of a quantity rather than to report measurement. They appear in Sections 17, 20, and 29 and are labeled where they occur.

Baseline and outcome figures must be measured in the reader's own environment. Every number in this paper is a hypothesis about your organization, not a finding about it. Section 29.3 explains why business cases built on borrowed figures fail.

01Why enterprise AI is moving beyond copilots

The first wave of generative AI adoption was dominated by assistants: summarize a document, draft an email, generate SQL, answer a question, explain a policy. These use cases are valuable, but they usually stop at the boundary between knowledge work and operational execution.

Real enterprise work is rarely a single prompt. It is a sequence of steps involving multiple systems, permissions, evidence, exceptions, handoffs, approvals, deadlines, and changing state. A customer dispute, loan exception, prior-authorization request, failed data pipeline, inventory shortage, support escalation, or renewal risk event can span hours or weeks and require contributions from many teams.

This creates a fundamental design requirement: an enterprise AI system must be able to reason over a process without becoming the process itself. Business state, rules, approvals, identity, audit history, and execution authority must live in durable systems rather than inside an ephemeral model conversation.

1.1 The shift from assistance to orchestration

1.2 Why "more agents" is not the answer

A system of unconstrained agents that freely converse, recursively delegate, and invoke tools can look impressive in a demonstration while becoming difficult to operate in production. The architecture must prevent five predictable problems:

• Unbounded delegation: agents create work faster than the organization can understand or govern it.
• Authority ambiguity: it becomes unclear which agent, system, or person is accountable for a decision or action.
• State loss: the workflow cannot reliably resume after interruption, model failure, timeout, or human delay.
• Evidence gaps: conclusions cannot be reconstructed from source data, tool outputs, decisions, and approvals.
• Operational fragility: changing a prompt unintentionally changes business behavior because business logic was embedded in prose rather than controlled workflow rules.

02What this borrows and what is actually new

An informed reader will recognize the vocabulary of this paper within a few pages: nodes, edges, guards, checkpoints, compensation, idempotency keys, correlation IDs, four-eyes approval, service identities. That is not accidental, and pretending otherwise would be dishonest. Most of the control architecture described here is inherited from decades of business process management and distributed systems practice.

Stating the inheritance clearly is not a weakness in the argument. It is the argument. The parts of this design that are borrowed are the parts that are already proven; the parts that are new are the parts that require caution.

2.1 What is borrowed

If an organization already runs a mature workflow engine, most of the substrate described in Sections 4, 5, and 8 already exists. The orchestration layer should be built on it rather than beside it. Section 4.3 defines the ownership boundary precisely.

2.2 What is actually different

Five properties distinguish an agent graph from a conventional workflow engine. Each one invalidates a guarantee that workflow practitioners took for granted.

1. Nodes are non-deterministic. A BPMN service task returns the same output for the same input. An agent node does not. Every downstream guarantee — unit testing, regression, replay, SLA, capacity planning — has to be re-derived under stochasticity. This is treated in Section 15.

2. Input data can influence control flow. A workflow engine reads a customer record; it does not have to consider that the customer record might contain instructions. An agent that ingests tickets, emails, logs, vendor PDFs, or customer documents is processing untrusted text with a model that also holds tool permissions. Business process management never had this threat model [13, 14, 15]. This is treated in Section 12.

3. Evidence and decision provenance is a compliance artifact. A workflow engine logs that a transition occurred. An agent graph must be able to show why a conclusion was reached, from authoritative sources, to a human reviewer or an auditor.

Note the precise formulation. The requirement is not to preserve model reasoning, and an architecture that depends on doing so is on weak ground — intermediate model reasoning is unstable across runs, unstable across versions, and not a reliable account of how an output was produced. What must be durable is the chain a business decision actually rests on: the evidence retrieved, its provenance and trust class, the conclusion drawn, the verification applied, the policy evaluated, the approval given, the action taken, and the outcome observed. That chain is reconstructable, reviewable, and defensible. Hidden reasoning traces are none of the three. This is treated in Section 9.

4. Cost is a runtime variable. A deterministic service task costs the same every execution. An agent node's cost varies with context size, retry count, evidence-loop iterations, and model routing — and can vary by an order of magnitude between an easy case and a hard one. Budgets must be enforced at runtime, not estimated at design time. This is treated in Section 17.

5. The graph does not need to enumerate every branch. This is the actual unlock, and it is worth being precise about it. Traditional workflow automation projects failed on the long tail: teams modeled the eighty percent of cases that were enumerable, and the remaining twenty percent — the exceptions, the ambiguous entity matches, the unstructured evidence, the cases that did not fit any branch — fell out of the process and back onto humans, who then also had to maintain the model. Agent nodes absorb that variance. The graph provides control; the agents provide tolerance for cases the graph designer never saw.

03The economic unit is the portfolio, not the first workflow

This section appears early because it changes how everything after it should be read.

The recurring per-case cost of an agent graph is small — typically single-digit dollars against hours of skilled human time. The build cost is not. A platform foundation with a state engine, tool gateway, identity model, audit ledger, observability, and evaluation harness is a multi-month engineering commitment before the first workflow reaches production.

The consequence is arithmetic rather than opinion: the first workflow almost never pays for the platform. A program justified on the labor savings of workflow one will be cancelled in month nine, and cancelling it will be the correct decision given the case that was made for it.

The economics arrive through reuse. Workflow two costs a fraction of workflow one. Workflow five should be configuration-dominant rather than engineering-dominant. Cumulative breakeven typically arrives somewhere between the fourth and sixth workflow, and arrives only if the platform genuinely amortizes — if each new workflow forks the platform instead of configuring it, breakeven never arrives at all.

Three implications follow, and they shape the rest of this paper:

• Workflow selection is a portfolio decision. Choosing a first workflow with no credible second and third behind it is choosing to fail the business case regardless of how well the first one performs. Appendix C scores reuse potential for this reason.
• Platform discipline is an economic control, not an engineering preference. Every bespoke extension made for one workflow is a charge against the portfolio.
• Marginal cost is the metric that matters. Section 27.5 makes it an explicit pilot output; Section 29 formalizes it in the TCO model.

04The architecture: Multi-Agent Orchestration Layer

The Multi-Agent Orchestration Layer sits between enterprise demand and enterprise execution. It does not replace systems of record, data platforms, workflow engines, schedulers, integration tools, ticketing systems, or human decision-makers. It coordinates them.

4.1 Six architectural planes

Two features of this diagram carry most of its meaning. Reasoning agents have no downward arrow to enterprise systems — their only output path is a typed plan object handed to the gateway. And the cross-cutting rail is not decoration: state, evidence, identity, policy, audit, observability, and cost are addressed by every plane, and no plane may bypass them.

4.3 Ownership boundary: three layers, three responsibilities

The most common dismissal of this architecture is that it is "a workflow engine wrapped around a language model." The correct response is not to deny the resemblance but to state the ownership boundary precisely, because the resemblance is the point and the boundary is the design.

Read as a sentence: durable execution decides when work runs, agents decide what the work means, and the policy and tool layer decides what may actually happen. No layer holds two of those three.

This partition is what makes the architecture difficult to collapse. Give the agent layer execution authority and you have an autonomous agent with a state file. Give the workflow layer interpretation and you are back to enumerating every branch. Give the tool layer judgment and authorization becomes a text-matching problem. The value is in the separation, not in any one component.

4.4 What the orchestration layer should own

• Workflow identity: every case, incident, transaction, request, or process instance receives a durable workflow ID.
• State: the current node, prior nodes, pending dependencies, timers, approvals, evidence, and outstanding actions.
• Graph version binding: which version of the workflow definition this instance is executing under (Section 14).
• Agent contracts: which agents may run, what inputs they receive, what outputs they must return, and what tools they may use.
• Transition rules: explicit conditions that determine whether work advances, waits, retries, escalates, or terminates.
• Human gates: approval requirements tied to risk, financial impact, customer impact, regulatory sensitivity, or production change.
• Execution boundaries: actions are performed through controlled tools and service identities rather than direct model access.
• Budget: the token, tool, time, and currency ceiling for this instance, enforced at runtime.
• Audit: a reconstructable record of inputs, outputs, evidence, decisions, approvals, tool calls, and final disposition.

05Stateful Agent Graph

The Stateful Agent Graph is the execution architecture inside the orchestration layer. A graph is a better representation than a linear chain because real workflows branch, wait, loop, escalate, invoke parallel work, and rejoin.

5.1 Nodes, edges, and state

Loop bounds deserve explicit treatment rather than being left implicit. An evidence-diagnosis cycle without a hard iteration cap is the single most common source of runaway cost in production agent graphs.

5.2 Example generalized workflow

5.3 Persistent state model

workflow_id: WF-2026-000184
workflow_type: data_incident
graph_version: 1.4.0          # pinned at instance creation
status: awaiting_approval
risk_tier: 3
tenant: EMEA-ANALYTICS
data_classification: internal
budget:
  ceiling_usd: 8.00
  consumed_usd: 1.68
  loop_iterations:
    gather_evidence: 2        # of max 3
subject:
  customer_id: CUST-48291
  system: analytics_platform
current_node: remediation_plan
evidence:
  - source: warehouse_query
    artifact_id: EV-1093
    trust: authoritative
    retrieved_by: svc-evidence-agent
    retrieved_at: 2026-08-10T08:19:04Z
    content_hash: sha256:4f2a...
  - source: pipeline_log
    artifact_id: EV-1094
    trust: corroborating
  - source: vendor_email
    artifact_id: EV-1096
    trust: untrusted          # content is data, never instruction
decisions:
  - decision: probable_mapping_failure
    evidence_refs: [EV-1093, EV-1094]
    post_condition: passed
    verifier: passed
    self_reported_confidence: 0.93   # recorded for calibration, not routed on
pending_actions:
  - action: deploy_mapping_fix
    requires_approval: true
    reversible: true
validation:
  expected: source_and_reporting_reconcile
audit:
  correlation_id: CORR-a82f...

Three fields are load-bearing and new relative to a conventional workflow record. Every evidence item carries a trust classification, because untrusted content must be handled differently at every downstream node. Every decision carries evidence references and verification results, which is what makes the decision reconstructable. And self-reported model confidence is recorded but not routed on, for reasons developed in Section 11.

The specific schema will vary by organization, but the principle is constant: workflow truth must be recoverable without depending on a model conversation transcript.

06When should something be a separate agent?

The multi-agent premise invites a fair challenge from a sophisticated reader: why have a Diagnostic Agent, an Evidence Agent, a Planning Agent, and a Verifier Agent rather than one model invoked with four prompts? The answer must be architectural rather than philosophical, because "different task" is not a reason and naming a prompt is not a design decision.

6.1 The test

A role deserves to become a separate agent when separation creates a meaningful boundary in at least two of the following dimensions. If it creates none, it is a prompt.

6.2 The Verifier as the clearest case

The Verifier Agent satisfies four boundaries simultaneously and is therefore the cleanest example in the library. It runs on a different model class, receives a deliberately restricted context, is evaluated on a different metric than the node it checks, and — most importantly — derives its entire value from independence. Merging it into the Diagnostic Agent as "a step where the model double-checks itself" destroys the property that makes it useful. Self-review inside a single context is not verification; it is the same reasoning process asked a second time.

6.3 The counter-examples

Roles that should not be separate agents, because they fail the test:

• A "Summarizer Agent" and a "Formatter Agent" with identical permissions, identical context, identical model class, and identical evaluation. One node, two prompts.
• A "Coordinator Agent" whose only function is to call other agents in a fixed order. That is a graph, and the graph should express it declaratively where it can be expressed declaratively.
• One agent per business domain when the domains differ only in retrieval content. Layer domain behavior through policy, retrieval, and tool permissions rather than through agent proliferation (Section 7).
• A "Critic Agent" that shares the full context of the work it critiques. It fails the independence test and provides the appearance of a control rather than a control.

07The enterprise agent library

A strong design uses a small set of reusable agents with narrow responsibilities rather than creating a new agent for every workflow. Domain-specific behavior is layered through policies, retrieval, tool permissions, and workflow configuration.

7.1 The privilege split

One structural rule governs the whole library, and it is the primary architectural defense described in Section 12: agents that read untrusted content do not hold write tools, and components that execute do not read untrusted content.

The Evidence Agent ingests customer emails, vendor documents, and third-party logs, and has no execution capability whatsoever. The Planning Agent proposes actions but consumes only structured, schema-validated outputs from upstream nodes. Execution is performed by the deterministic tool gateway, not by any agent.

7.2 Agent contracts

Every agent should have an explicit contract containing: purpose, required inputs, permitted tools, prohibited actions, output schema, evidence requirements, model class, token and cost budget, timeout, retry policy, escalation behavior, trust exposure, and contract version. Contracts turn agents into manageable platform components rather than prompt fragments.

Prompts should be versioned separately from contracts. Prompt tuning is frequent; contract change is a governed event.

08Deterministic execution, tools, and systems of record

The orchestration layer should prefer deterministic execution whenever an action can be expressed as an API call, database transaction, workflow-engine job, CI/CD action, script, rules-engine decision, or predefined service operation. The model proposes or selects the action; controlled software performs it.

8.1 Tool gateway

Agents should never receive arbitrary network or system access. They should call a tool gateway that exposes curated operations. Each operation is strongly typed, authorized, observable, rate-limited, and bound to a service identity.

The third row is easy to overlook and important. If the gateway decides whether to permit an action partly on the basis of a natural-language rationale supplied by the agent, then the rationale is an attack surface. Authorization must be computable from workflow state, policy, and typed parameters alone.

8.2 Systems of record remain authoritative

The agent graph should reference and update authoritative enterprise systems rather than create a parallel shadow operating model. Customer state belongs in the CRM or customer platform. Financial transactions belong in the ledger or core platform. Clinical records belong in the designated clinical system. Deployment truth belongs in source control and CI/CD. Work-item truth belongs in the case or ticket system. The orchestration layer coordinates these systems and retains process evidence; it does not replace their authority.

09State, memory, evidence, and context

9.1 Four kinds of information should be separated

"Memory" should not be a single opaque store containing everything an agent has ever seen. Enterprise memory must be scoped by workflow, user, tenant, sensitivity, purpose, retention policy, and authority.

Working context in particular should be treated as disposable. If information matters beyond the current node, it should be promoted into state or evidence explicitly, with a schema. Anything that survives only in a conversation buffer is, by definition, not recoverable and not auditable.

9.2 Evidence and decision provenance

Every material conclusion should reference the evidence that supports it. A diagnostic agent should not merely say "the pipeline is filtering data." It should point to the model definition, observed counts, lineage path, and relevant log or configuration that led to the conclusion.

The provenance requirement is deliberately scoped to evidence and decisions, not to model reasoning. What must be durable and reconstructable is:

That chain answers the questions a reviewer, auditor, or regulator actually asks: what did you know, where did it come from, what did you conclude, who checked it, who authorized it, what did you do, and did it work. Intermediate model reasoning answers none of them reliably and should not be represented as a control.

9.3 Evidence carries provenance and trust

Trust classification is not bureaucracy. It is the mechanism that makes Section 12's defenses enforceable in code rather than aspirational in prose.

9.4 Tenant, data, and jurisdiction isolation

For regulated and multi-tenant environments — which is to say, for the industries in Sections 20 through 25 — the memory and evidence model needs isolation controls at least as strong as those applied to the underlying systems of record. The orchestration layer aggregates data across systems, which means it can silently become the weakest link in a data-protection posture that is otherwise sound.

The last row deserves emphasis. Platforms that accumulate resolved patterns as reusable knowledge create a path by which one customer's operational specifics can surface in another customer's workflow. The curation step in Section 9.1 is a data-protection control, not a quality control.

10Human-in-the-loop control model

Human involvement should be risk-based rather than universal. Requiring approval for every step destroys the value of automation; allowing unrestricted autonomous execution creates unacceptable risk.

10.1 Approval must be part of the graph

Approval is not a message sent outside the workflow. It is a first-class node with an approver, decision scope, evidence package, expiration, delegation rules, and recorded outcome. The workflow should remain paused until the decision is resolved or an escalation path is triggered.

10.2 What an approval package must contain

The failure mode here is approval theater: a reviewer who clicks approve because the interface offers no basis for doing anything else. An approval node should present, at minimum:

• The proposed action, as a typed diff or concrete parameter set — not a prose description
• The evidence the conclusion rests on, with provenance and trust class visible
• What the verifier checked and whether it passed
• The expected outcome and how validation will confirm it
• What happens on rollback, and whether rollback is possible
• What the reviewer is not being asked to certify

Approval rate above roughly ninety-five percent with median review time under a minute should be read as a control failure rather than a success metric. It usually means the gate is placed where risk is not, or that the package is not decision-shaped.

11Routing on evidence, not self-reported confidence

Many agent-graph designs gate transitions on a model-reported confidence score: proceed if confidence exceeds some threshold, escalate otherwise. This is a weak point that deserves to be named rather than inherited.

11.1 The problem

Self-reported confidence from a language model is a generated token sequence, not a calibrated probability. Calibration is a well-studied property of neural classifiers and a poorly behaved one at scale [16, 17, 18]. In practice, self-reported confidence is:

• Poorly calibrated, and typically overconfident in exactly the cases that matter — plausible-looking reasoning over incomplete evidence
• Sensitive to prompt phrasing, so a wording change intended as cosmetic can shift the distribution of scores and therefore the routing behavior of a production workflow
• Non-stationary across model versions, so a vendor upgrade silently re-tunes a business control
• Compressed, clustering in a narrow band that makes threshold selection arbitrary

A threshold like confidence >= 0.85 looks like a control. It is closer to a coin weighted by an unknown amount in an unknown direction.

11.2 Better routing signals

Route on properties that can be checked deterministically or corroborated independently.

The strongest of these is the deterministic post-condition, because it converts a reasoning claim into a testable one. Wherever a workflow can be designed so that a hypothesis implies a checkable prediction, it should be.

11.3 If you want to use confidence, earn it

Self-reported confidence can become usable, but only as a calibrated instrument:

1. Record the score on every case without routing on it.
2. Bin scores against replay outcomes over at least several hundred completed cases per workflow type.
3. Publish the reliability curve. If the 0.9 bin resolves correctly seventy percent of the time, the number is not a probability and should not be used as one.
4. Re-validate on every model version change and every material prompt change, as a promotion gate.
5. Only then permit routing, and only in combination with an evidence-sufficiency check.

Record the score from day one regardless. Calibration data is cheap to collect and impossible to reconstruct retroactively.

12Security: injection, identity, and the minimum control set

The primary security objective is to ensure that model intelligence never implies model authority. Authority must come from enterprise identity, policy, workflow state, and explicitly granted tool permissions.

12.1 The threat this architecture creates

Conventional workflow engines process data. Agent graphs process text that a model will act on, and much of that text arrives from outside the trust boundary: customer emails, vendor invoices and PDFs, third-party ticket comments, scraped web content, log lines containing user-supplied strings, file names, document metadata.

Indirect prompt injection is the resulting risk: content retrieved as evidence contains instructions, and an agent holding tool permissions follows them [13]. It is recognized as a leading risk class for LLM-integrated applications [14] and has been demonstrated against tool-using agents under realistic conditions [15]. It is not solved by better prompting. It should be treated the way SQL injection is treated — as a class of vulnerability mitigated structurally, not by asking the interpreter to be careful.

12.2 Structural defenses

12.3 Minimum control set

12.4 Regulated-industry posture

In regulated environments, the architecture should be mapped to the organization's existing control framework rather than introducing an independent "AI governance" universe [19, 20, 21]. The same access-control, change-management, record-retention, incident-management, third-party-risk, privacy, segregation-of-duties, and approval policies should apply to agent-driven work.

The exception worth negotiating early is model version management. Most control frameworks assume that a dependency changes only when the organization changes it. A hosted model upgraded on a vendor timeline breaks that assumption, and the treatment — pinned versions, contractual notice periods, regression before promotion — should be agreed with risk and compliance before the first workflow reaches production, not after.

13Model and vendor abstraction

A graph that is tightly coupled to one model vendor inherits that vendor's roadmap, pricing, availability, and deprecation schedule as business risk. The coupling is easy to create accidentally, because vendor-specific capabilities are convenient and their traces spread through prompts, output parsing, and tool definitions until the abstraction that existed on paper no longer exists in code.

The abstraction boundary is the agent contract. A node declares a model class and a set of requirements; the model registry resolves that to a specific provider, model, and version. Nothing in the graph definition names a vendor.

13.1 Required capabilities

13.2 Model policy as configuration

model_policy:
  classes:
    small:
      requirements: [structured_output, low_latency]
      max_cost_per_1k_tokens: 0.0015
      residency: [us, eu]
    standard:
      requirements: [structured_output, long_context]
      residency: [us, eu]
    frontier:
      requirements: [structured_output, long_context, strong_reasoning]
      residency: [us, eu]
      data_classification_max: internal

  bindings:
    - class: small
      primary: {provider: A, model: m-small, version: "2026-05-01"}
      fallback: [{provider: B, model: n-compact, version: "2026-04-12"}]
    - class: frontier
      primary: {provider: A, model: m-large, version: "2026-06-30"}
      fallback: [{provider: B, model: n-large, version: "2026-06-02"}]
      fallback_policy: degrade_to_human_if_unavailable   # no cross-region failover

  constraints:
    - data_classification: restricted
      allowed_providers: [A]
      allowed_regions: [eu]
      fallback_permitted: false

The fallback_permitted: false line is the important one. Resilience and data protection can conflict, and the conflict must be resolved in configuration rather than in the moment. A fallback that moves restricted data to a different jurisdiction is a control failure wearing a resilience costume.

13.3 What not to abstract

Abstraction has a cost, and over-abstraction produces a lowest-common-denominator platform that cannot use any model well. Two pragmatic limits:

• Do not abstract prompts to a vendor-neutral intermediate format. Prompts should be versioned per model binding and regression-tested per binding. A prompt that works identically across providers is usually a prompt that works well on none of them.
• Do not promise hot-swappable models. Changing a model binding is a change-controlled event with a regression gate, not a runtime toggle. The abstraction exists to make substitution possible and governed, not instantaneous.

14Versioning a graph that is already running

This is the operational problem that most reference architectures omit and most implementation teams discover at the worst possible moment: it is Thursday, four hundred workflow instances are paused at approval nodes, some created eleven days ago, and a change to the graph is ready to deploy.

14.1 Bind the version at instance creation

The default rule is that a workflow instance executes under the graph version it was created with, recorded in state, for its entire life. New instances get the new version. In-flight instances complete under the old one.

This requires that multiple graph versions be resident simultaneously, that agent contracts and prompts be resolvable by version, and that the platform report the version distribution of open instances. It is more infrastructure than a single-version deployment, and it is the difference between shipping weekly and shipping quarterly.

14.2 Change classes

The distinction in the middle of that table is deliberate: graph logic is pinned; policy is not. If a control requirement changes — an approval threshold drops, a data-residency rule tightens, an action is prohibited — it must apply to work already in progress. An architecture that pins policy alongside logic will, sooner or later, execute an action the organization has already decided to forbid.

14.3 Operational rules

• Set a maximum instance age. Instances that outlive their graph version's support window are escalated to humans, not silently migrated.
• Maintain a deprecation window per version, with a dashboard of open instances by version.
• Treat state schema changes exactly as database migrations: reviewed, reversible, tested against real instance data.
• Never mutate a running instance's graph version except through an explicit, logged migration with a named owner.
• Include multi-version behavior in the evaluation suite, not just current-version behavior.

15Observability and evaluation under non-determinism

15.1 One correlation ID across the workflow

Every workflow should carry a correlation ID through the agent graph and every integrated system. This creates a single trace from request to evidence, reasoning output, tool execution, downstream system result, human approval, and final disposition.

15.2 Evaluation when the system is not deterministic

A conventional regression suite asks whether output equals expected output. That question is not well formed here, and treating it as though it is produces a suite that passes on Tuesday and fails on Wednesday with no code change.

Measure distributions, not instances. Run each golden case n times (five is a reasonable floor) and set thresholds on pass rate rather than on a single result. A case that passes four times in five is a different engineering object than one that passes five in five, and the difference should be visible.

Score dimensions separately. Collapsing quality into one number hides the tradeoffs that matter:

Treat model upgrades as change events. Pin model versions. Run the full regression suite before promotion, and expect that some workflows will need prompt or threshold adjustment. Budget engineering time for this on a recurring basis; it is a permanent operating cost of the architecture, not a one-time migration.

Build an adversarial subset. Golden cases drawn from clean historical examples measure the easy path. The suite should also contain: missing evidence, contradictory evidence, stale data, ambiguous entity matches, out-of-scope requests, cases whose correct answer is escalation, and injection canaries.

Do not evaluate on the cases you built with. The set used during development is a development artifact. Hold out a genuinely separate evaluation set and refresh it as production cases accumulate [12].

Keep shadow mode permanently available. Shadow evaluation is usually treated as a pilot phase. It is more useful as a standing capability: a sampled percentage of live cases run through a candidate configuration alongside production, continuously.

16Resilience and failure-domain isolation

Graceful degradation is easy to write into an architecture document and difficult to exercise in production. This section names the specific failure domains an agent graph must survive, and what containment looks like in each.

The organizing principle is that every failure should be bounded to the smallest possible domain: one instance, one tool, one tenant, one workflow type, one model provider — never the platform.

16.1 Failure domains

16.2 Quarantine as a first-class state

Most workflow platforms have "failed" and "completed." Agent graphs need a third terminal-adjacent state.

A quarantined instance is one that has failed repeatedly in a way that automated retry will not resolve. Quarantine freezes state, stops all automated activity, assigns a named owner, records the failure history, and removes the instance from SLA and throughput metrics while keeping it visible in a queue that someone is accountable for draining.

Quarantine matters because the alternative behaviors are both bad. Infinite retry burns budget and pollutes metrics. Silent failure loses work that a customer or regulator believes is in progress. A quarantine queue with an owner and an age metric makes the failure visible and finite.

16.3 Replay and manual recovery

• Replay should be possible from any checkpoint, with the caveat that agent nodes will not reproduce identical outputs. Replay is therefore a recovery mechanism and a debugging aid, not a determinism guarantee. State transitions and tool calls replay deterministically; reasoning does not.
• Manual recovery must be a designed path, not an escape hatch. Every workflow type should specify what an operator does when the graph cannot proceed: what state they can see, what they can edit, what they cannot edit, what gets logged, and how the instance is closed.
• The fallback path must be exercised. A degradation path that has never been run in anger does not work. Include provider-outage and store-unavailable scenarios in game-day exercises alongside the standard incident drills [10].

16.4 Standard resilience patterns

• Checkpoint after every material state transition so a workflow can resume rather than restart.
• Use idempotent tools and idempotency keys to prevent duplicate actions during retry.
• Distinguish transient failures from logical failures; retry only the former.
• Bound every loop explicitly and escalate on exhaustion rather than allowing recursion.
• Persist external dependency status and reawaken workflows when dependencies change.
• Provide compensation steps for reversible actions and manual recovery paths for irreversible ones.
• Degrade gracefully: if an agent or model is unavailable, preserve state and route to human processing.

17Latency and unit economics

Cost and latency in an agent graph are emergent rather than designed. They should be measured per node from the first pilot day, because the intuitions people bring from deterministic systems are usually wrong in both directions.

17.1 Where the time actually goes

Model inference is rarely the bottleneck. In an instrumented workflow, machine time typically distributes roughly as follows:

And machine time is typically a minority of wall-clock time. Human approval wait dominates end-to-end latency in almost every governed workflow. An architecture that optimizes inference speed while leaving approval routing untouched is optimizing the wrong term.

17.2 Where the money actually goes

Cost per case is driven by three multiplicative factors: context size, node count, and retry or loop iterations. The third produces the surprises, because it is bimodal — most cases traverse the graph once, and a small tail loops repeatedly on ambiguous evidence.

Report cost as a distribution, never as an average. A workflow with a $2 median and a $40 ninety-ninth percentile is a very different operational proposition from one with a $4 median and a $6 tail, even though the second looks worse on a mean.

Practical levers, roughly in order of return:

1. Bound loops. The single largest cost lever. Cap evidence-diagnosis cycles and escalate on exhaustion.
2. Route models by node. Intake classification, entity resolution, verification, and documentation rarely need a frontier model. Diagnosis and planning usually do.
3. Summarize evidence before it enters reasoning context. Passing raw logs into a diagnostic node is the most common cost mistake, and long contexts degrade quality as well as economics [22].
4. Cache aggressively on policy lookups, entity resolution, and reference data.
5. Terminate early. A workflow that can determine at intake that it is out of scope should exit at intake.
6. Enforce per-instance budget ceilings at runtime, with escalation on breach rather than silent continuation.

17.3 The honest build cost

The recurring per-case cost of an agent graph is usually small. The build cost is not, and business cases that omit it are the reason many of these programs lose credibility in year two.

Illustrative planning ranges for an organization starting without an existing durable-execution platform:

Organizations with a mature workflow engine already in production can compress the first row substantially — often by half — which is a strong argument for building on what exists rather than beside it (Section 4.3).

18Worked example: a data incident, end to end

Abstractions are easy to agree with and hard to act on. This section traces a single workflow instance through the graph with cost, latency, and human-touch figures.

18.1 The case

Monday, 08:14. An automated reconciliation check flags that the EMEA revenue dashboard reports 12.3% lower booked revenue for the prior week than the source order system. Finance close is Thursday. Three teams have historically been involved in incidents of this shape: analytics engineering, the data platform team, and the finance systems analyst who reported it.

Baseline, over 340 comparable incidents: median 6.5 hours elapsed, frequently spanning a business day boundary; 4.2 hours of human touch time across two to three people; 31% required a second investigation pass after an initial incorrect diagnosis.

18.2 The trace

Totals: 58 minutes wall clock. 21 minutes of machine time. 11 minutes of human attention, from one person. $2.44 in model, retrieval, and compute spend.

18.3 What this example is meant to show

The loop fired, and that is the system working. The first hypothesis was wrong. A deterministic post-condition caught it rather than a confidence score, and the loop bound guaranteed it could not run away. Traces where nothing goes wrong are not evidence of anything.

Validation caught a side effect the plan did not anticipate. Two downstream extracts needed re-running. A workflow that ended at execution would have closed the incident and created a second one.

Human attention dropped far more than elapsed time did. 4.2 hours to 11 minutes of attention; 6.5 hours to 58 minutes elapsed. Approval wait was 27 of those 58 minutes — nearly half the wall clock and almost none of the cost. This is where routing and delegation design pay off, not model selection.

The per-case cost is not the interesting number. $2.44 against 4.2 hours of skilled analyst time is a rounding error, and quoting that ratio proves nothing about whether the program is worth running. The relevant arithmetic is in Section 29.

19Cross-industry workflow pattern: exception to resolution

Many enterprise processes share the same underlying shape even when the domain language differs.

20Banking and financial services

Banking is a strong fit for stateful agent orchestration because work is document-heavy, rules-heavy, exception-heavy, highly auditable, and distributed across specialized teams. The architecture should augment existing credit, risk, fraud, compliance, servicing, and core systems rather than bypass them.

Commercial loan origination orchestration

Current-state friction: Relationship managers, credit analysts, underwriting, legal, collateral, operations, and approvers exchange documents and status across multiple systems; missing items and exceptions create long cycle times.

Agent-graph pattern: Intake creates the case; Entity Resolution maps borrower, guarantors, and facilities; Evidence gathers financials and historical exposure; Policy identifies required documents and constraints; Diagnostic identifies missing or inconsistent data; Planning creates conditions and a work queue; authorized humans make credit decisions; Documentation assembles the evidence and decision record.

Control boundary: Credit approval, pricing exceptions, covenant waivers, legal terms, and funding remain under authorized human or rule-based control.

Injection surface: Borrower-supplied financial statements and third-party appraisals are untrusted content. Evidence agents ingesting them hold no write tools.

Measures: Application-to-decision time, exception aging, missing-document rate, analyst touch time, rework rate.

KYC and customer due-diligence case orchestration

Current-state friction: Analysts manually collect entity data, ownership evidence, screening results, risk signals, and periodic-review requirements.

Agent-graph pattern: Agents coordinate evidence collection, entity resolution, document completeness, rule application, discrepancy identification, case summarization, and reviewer queues. Deterministic screening and official risk systems remain authoritative.

Control boundary: No autonomous final regulatory disposition; high-risk matches and beneficial-ownership discrepancies require authorized review.

Injection surface: Corporate registry extracts, customer-supplied ownership documents, and adverse-media text.

Measures: Case cycle time, evidence completeness, analyst review time, false-positive handling time, overdue reviews.

Payments and transaction exception operations

Current-state friction: Failed, held, duplicate, mismatched, or unreconciled payments create queues across operations, fraud, customer support, and finance.

Agent-graph pattern: The graph resolves payment, account, and customer; gathers processor and ledger evidence; categorizes the exception; checks policy; proposes next action; invokes bounded correction tools where permitted; validates ledger state; and documents disposition.

Control boundary: Release of funds, fraud disposition, material reversals, and customer-impacting financial actions require explicit authority.

Why this is a strong first candidate: high volume, clear baseline, mostly reversible corrections, deterministic validation against the ledger, and a named operational owner. It scores well on every dimension in Appendix C.

Measures: Exception aging, straight-through resolution rate, duplicate recovery, manual touches, reconciliation breaks.

Regulatory reporting and data-quality exception management

Current-state friction: Reporting teams spend disproportionate effort tracing source fields to reported aggregates, investigating reconciliation breaks, chasing data owners, documenting lineage, evidencing controls, and managing sign-off — under fixed regulatory deadlines that do not move when the data is late. Much of the work is not analysis; it is assembly.

Agent-graph pattern: This workflow uses the full library and is the clearest demonstration of why the agent roles are separated (Section 6). Intake receives the break from a reconciliation control. Entity Resolution maps the reported field to its data domain, owning team, and control ID. Lineage Agent traces source-to-report across the warehouse, transformation layer, and reporting model. Evidence Agent assembles counts at each stage, recent schema and code changes, job history, and the applicable regulatory instruction text. Diagnostic Agent classifies the break — source data quality, transformation defect, timing and cut-off, mapping or reference-data change, or legitimate business movement — and tests each hypothesis with a deterministic post-condition. Validation Agent confirms reconciliation after remediation. Documentation Agent produces the evidence package and control artifact that the certification process consumes.

Control boundary: Regulatory sign-off remains with the accountable executive and the established certification process. Production data changes follow normal change control. The graph does not determine whether a movement is reportable; it assembles the evidence on which that determination is made.

Injection surface: Third-party and vendor data feeds, and regulatory instruction documents ingested as text. Both are untrusted content by the classification in Section 9.3.

Why this matters strategically: it connects AI orchestration directly to data governance rather than treating them as separate programs. Lineage, evidence, reconciliation, ownership, and attestation are exactly the capabilities regulators already expect an institution to demonstrate, and they are exactly the capabilities this architecture produces as a by-product of operating. An organization that builds this workflow improves its data governance posture whether or not the automation ever advances beyond tier 1.

Measures: Break resolution time, reconciliation pass rate, manual certification effort, repeat break rate, lineage coverage, late submissions, control-testing exceptions.

Also applicable

Loan servicing and covenant monitoring, where covenant dates, borrower reporting, insurance, and collateral tracking span spreadsheets, inboxes, and servicing systems, with waivers and default actions remaining human-controlled.

21When not to build this

A reference architecture that recommends itself in all conditions is a sales document. The following conditions should lead an organization to build something else, and recognizing them early is worth more than any implementation guidance in this paper.

The process is fully enumerable. If every case fits a branch you can specify, you want a workflow engine and rules. Adding non-deterministic nodes to a deterministic problem buys variance, cost, and an evaluation burden in exchange for nothing.

Volume is low. Below roughly two hundred instances per year, per workflow, the engineering and operating cost will not amortize under any realistic assumption. Improve the human process, or provide a copilot.

The work lives in one system. If a single application holds the data, the rules, and the actions, use that application's automation. An orchestration layer earns its cost by crossing boundaries.

There are no APIs. If the work is performed by humans clicking through interfaces with no programmatic surface, this architecture becomes RPA with a language model attached, and inherits RPA's brittleness without shedding its maintenance burden. Fix the integration problem first.

Every action is irreversible and high-risk. Where no action is safely reversible and every step requires authorized approval, the graph adds ceremony without adding throughput. Use tier 0 and 1 assistance — evidence assembly and recommendation — and leave execution human.

Latency requirements are sub-second. Agent graphs operate on timescales of seconds to minutes per node. Real-time decisioning paths need models deployed inline, not orchestrated.

There is no baseline. If the organization cannot state today's cycle time, touch count, error rate, and cost, it will not be able to demonstrate improvement, and the program will be evaluated on impressions. Instrument first, build second.

There is no named process owner. Workflows without an accountable owner produce automation that nobody maintains and nobody defends when it fails.

The honest answer is process redesign. Some processes are slow because they encode organizational history rather than necessity. Automating a five-handoff approval chain that exists because two teams do not trust each other preserves the dysfunction and adds a maintenance cost to it. Simplify first; automate the durable core.

22Healthcare

Healthcare operations combine fragmented data, complex payer and provider rules, sensitive information, time pressure, and significant manual coordination. The highest-value early uses are administrative and operational rather than clinical.

Prior authorization orchestration

Current-state friction: Staff gather payer requirements, clinical documentation, codes, coverage data, forms, and status updates across portals and systems.

Agent-graph pattern: The graph resolves patient, payer, and service; retrieves coverage and authorization rules; checks documentation completeness; assembles the submission package; routes missing-information tasks; submits through approved interfaces; monitors status; and escalates denials or requests for information.

Control boundary: Clinical necessity statements, peer-to-peer discussions, and regulated clinical determinations remain with authorized professionals.

A note on the evidence loop: payer rules change frequently and are often published in unstructured form. The rule set should be treated as versioned evidence with a freshness requirement, not as static knowledge baked into a prompt.

Measures: Authorization cycle time, preventable denial rate, staff touches, missing-document rate, status-chasing effort.

Claims denial management

Current-state friction: Denials require classification, evidence retrieval, coding and payment-policy review, appeal preparation, payer follow-up, and learning across thousands of cases.

Agent-graph pattern: Agents classify denial reason, gather claim, remit, order, and documentation evidence, identify known patterns, apply policy, draft appeal and supporting tasks, monitor deadlines, route specialist review, and feed recurring causes into operational improvement.

Control boundary: Coding changes, attestations, clinical statements, and final submissions follow established authorization and compliance rules.

Measures: Denial overturn rate, days in A/R, appeal cycle time, preventable-denial recurrence, manual minutes per denial.

Eligibility and benefits exception management

Current-state friction: Eligibility responses are incomplete, inconsistent across payers, or contradict the coverage on file. Staff re-verify manually, often by phone, and errors surface later as denials or patient billing problems.

Agent-graph pattern: The graph resolves patient, payer, and plan; retrieves eligibility responses across available interfaces; compares against registration data and the coverage on file; classifies the discrepancy — termed coverage, plan change, coordination of benefits, demographic mismatch, or payer response defect; prepares correction tasks; and validates that downstream registration and claim state reconcile after correction.

Control boundary: Changes to patient financial responsibility, coverage determinations, and anything affecting patient billing require authorized review.

Measures: Eligibility-related denial rate, re-verification volume, registration correction rate, downstream billing errors.

Provider directory accuracy

Current-state friction: Directory data drifts continuously — locations, panel status, specialties, affiliations, and accepting-new-patients flags — and inaccuracy carries regulatory exposure as well as patient-access consequences. Verification is manual, cyclical, and rarely complete.

Agent-graph pattern: The graph monitors directory records against authoritative sources (credentialing, contracting, claims activity, practice management), detects discrepancies and staleness, classifies the likely cause, generates outreach and verification tasks, tracks responses, and updates the directory through approved interfaces with a full evidence trail per change.

Control boundary: Contractual status, panel participation, and credentialing state remain governed by the systems and committees that own them. The graph detects and evidences discrepancies; it does not decide participation.

Why this fits well: claims activity provides a deterministic corroborating signal — a provider billing regularly from a location is evidence about that location — which makes post-condition testing viable in a domain where most evidence is otherwise self-reported.

Measures: Directory accuracy rate, stale-record age, verification cycle completion, regulatory findings, patient-access complaints.

Provider onboarding and credentialing operations

Current-state friction: Teams collect licenses, attestations, payer enrollment data, background items, facility records, expirations, and approvals.

Agent-graph pattern: Agents manage checklist state, retrieve and validate documents, identify gaps and expirations, create tasks, track external dependencies, prepare reviewer packets, and maintain a complete audit trail.

Control boundary: Credentialing committee decisions and regulated approvals remain human-controlled.

Measures: Time to credential, incomplete packet rate, expired-item incidents, staff follow-up effort.

Also applicable

Referral coordination: resolving referral context, checking prerequisites, requesting missing documentation, coordinating authorization status, and creating scheduling-ready state — with the explicit boundary that agents do not provide clinical diagnosis or treatment recommendations. Measures: referral leakage, time to schedule, incomplete-referral rate, handoff delays.

Revenue-cycle reconciliation: persistent cases across eligibility, registration, coding, charge, claim, payment, and reconciliation exceptions, with financial adjustments beyond threshold requiring approval. Measures: queue aging, rework, first-pass resolution, net collection impact.

Claim status follow-up: monitoring outstanding claims across payer interfaces, classifying status responses, distinguishing genuine pends from processing noise, and escalating aged claims before timely-filing deadlines. Measures: days in A/R, aged-claim volume, timely-filing write-offs, follow-up touches per claim.

23Retail

Retail combines high transaction volume, thin operating margins, distributed physical operations, fast-moving inventory, and complex supplier and logistics networks. Agent graphs are particularly useful for exception management where deterministic systems already exist but humans spend their time reconciling across them.

Flagship: inventory exception resolution

Current-state friction: Point-of-sale, ERP, warehouse management, ecommerce order management, and vendor systems disagree about how much of a SKU exists at a location. The disagreement is routine; determining why is not. An analyst or store team must decide whether a shortage is demand, shrink, a delayed receipt, an in-transit transfer, an integration sync failure, a unit-of-measure or master-data error, or a mis-scan at receiving — and each cause implies a different correction. The determination is judgment-heavy, the evidence is spread across five systems, and the cost of getting it wrong is either an unnecessary write-off or a persistent phantom-inventory problem that suppresses replenishment.

This is a canonical case for the architecture because the systems are deterministic and well-integrated while the diagnosis is not. Rules engines resolve the clear cases; the residue is what consumes human time.

Entities resolved: SKU, location, vendor, purchase order, transfer order, and the applicable inventory policy for that category and location.

Evidence gathered:

Diagnosis classes: demand spike, shrink, delayed or short receipt, in-transit transfer not yet posted, integration sync failure, master-data or UOM error, mis-scan at receiving, allocation held by an unfulfilled order.

Each class carries a deterministic post-condition. A sync failure predicts that two systems disagree by exactly the volume of unposted transactions in a specific window; a UOM error predicts a discrepancy that is an exact multiple of the case pack. Testing the prediction is what distinguishes this from a plausible guess.

Plan options: replenishment trigger, inter-store or DC transfer, inventory adjustment, cycle count task, vendor query or chargeback, master-data correction, integration reprocessing.

Approval: value-threshold based. Adjustments below a category-specific threshold execute under tier 3 with sampled approval; material write-offs, high-value adjustments, and anything with financial-statement impact require named authority. The threshold is policy and is therefore evaluated at gate time, not pinned to the graph version (Section 14.2) — a decision that matters at year-end when thresholds tighten.

Validate: re-reconcile across POS, ERP, WMS, and OMS after execution; confirm that the correction did not create a downstream allocation or replenishment side effect; confirm the SKU-location position is consistent in all four systems.

Injection surface: vendor ASN documents, supplier portal text, and free-text notes from store staff.

Measures: out-of-stock duration, exception aging, inventory accuracy, phantom-inventory rate, manual touches per exception, unnecessary write-off rate, lost-sales exposure.

Also applicable

24SaaS

SaaS organizations have dense telemetry and mature APIs but still rely heavily on human coordination across support, engineering, customer success, sales, billing, security, and product operations. The API maturity makes this the fastest domain in which to reach a working graph; the coordination burden is what makes it worth doing.

Flagship: production incident and enterprise support escalation

Current-state friction: A high-severity customer escalation and a production incident are the same workflow observed from different ends. Both require assembling account context, entitlements, telemetry, logs, configuration, recent deployments, dependency ownership, and known-issue history under time pressure — while simultaneously communicating with a customer whose tolerance is decaying. The assembly work is substantial, repetitive, and performed by the most expensive people in the organization, at the moment when their attention is most valuable.

This workflow mirrors the architecture unusually cleanly, which makes it a good first build as well as a good explanatory example.

Intake: ticket, alert, or both. The graph correlates them rather than running two instances — a customer escalation and the alert for its underlying cause resolve to one workflow ID via idempotency on the affected service and time window.

Resolve entities: tenant, account, environment, service, service owner, entitlement and support tier, contractual commitments, and the customer's deployed configuration and version.

Evidence gathered:

Diagnose: the hypothesis space is usually product defect, configuration, data condition, capacity, dependency failure, or usage pattern outside supported bounds. Recent-change tracing is the highest-yield signal and should run first. Post-conditions are unusually strong here: if a deployment caused the failure, the error signature onset should align with the rollout window on the affected fleet, and that alignment is checkable rather than arguable.

Plan: workaround, rollback, configuration change, forward fix, capacity action, or escalation to engineering — plus the communication plan, which is part of the plan rather than an afterthought. Each option declares reversibility, blast radius, and validation criteria.

Approve: production mutations remain under environment-specific change authority and incident-command policy. Read-only diagnostics execute at tier 3 under pre-approval. Rollback is often pre-approved for a named set of services; forward fixes are not. Customer-facing commitments and root-cause sign-off require authorized humans.

Execute: pre-approved diagnostics and rollback through the tool gateway under a service identity scoped to the affected environment. Engineering work items opened with the assembled evidence attached — which is where much of the value lands, because the interrupt to an engineer arrives complete rather than as a request to go and look.

Validate: service-level recovery confirmed in telemetry and customer-level validation confirmed with the customer. These are different checks and the second is frequently skipped, which is how incidents get closed twice.

Document: timeline, evidence package, RCA draft, customer communication draft, action items with owners, and a knowledge article routed for review.

Control boundary: production changes, security-sensitive actions, contractual commitments, and root-cause sign-off require authorized humans.

Injection surface: this is the highest-exposure workflow in the paper. Customer-supplied log exports, ticket free-text, and attachments are all untrusted content, and they arrive during an incident when review attention is lowest. The privilege split (Section 7.1) is not optional here.

Measures: MTTD, MTTR, time to first useful diagnosis, engineering interrupts per incident, interrupt completeness, communication latency, customer update frequency, reopen rate, action-item completion.

Also applicable

25Insurance

Insurance may be the strongest single fit for this architecture among the industries in this paper, and for a specific reason: the last-twenty-percent problem described in Section 2.2 is more acute here than anywhere else. Data arrives from many counterparties in inconsistent formats, allocation and coverage logic is rules-heavy but contract wording resists full enumeration, the work is document-dense, and the audit expectations are high. Rules engines handle standard cases well and fail on precisely the cases that consume expert time.

Injection surface across all of these: cedent submissions, broker slips, loss runs, and third-party bordereaux are untrusted content by classification, arriving in volume and in formats that require extraction before use.

A note on evidence in this domain: contract wording is authoritative evidence but is not machine-comparable in the way a ledger balance is. Workflows in this domain should be designed so that the graph assembles and cites wording rather than interpreting it, with interpretation remaining a tier 4 human determination. That constraint is a feature: it keeps the highest-judgment, highest-liability work where accountability already sits, while removing the assembly burden that surrounds it.

26Operating model and organizational design

A production agent platform is both a technical platform and an operating model. The organization needs clear ownership for the workflow substrate, domain workflows, tools, controls, and model behavior.

The last role is frequently omitted and frequently fatal. Under non-determinism, evaluation is not a phase; it is a standing function with a recurring workload driven by model releases, prompt changes, and drift.

26.1 Central platform, federated workflows

A practical pattern is a central orchestration platform with federated domain ownership. The central team builds the runtime, identity model, tool gateway, model registry, audit, observability, shared agent library, evaluation framework, versioning, and deployment standards. Domain teams own workflow definitions, business rules, acceptance criteria, and operational outcomes.

The boundary should be enforced economically: if a domain team can ship a workflow without central engineering time, the platform is working. If every workflow requires platform changes, the platform is a framework in name only and the portfolio economics in Section 3 will not materialize.

27Implementation roadmap and 90-day pilot

The pilot has two objectives, and the second matters more. The first is to demonstrate that one workflow works. The second is to produce credible evidence about what the next five workflows will cost (Section 3).

27.1 Weeks 1–2: discovery and workflow selection

• Select one workflow with meaningful volume, measurable baseline, bounded risk, accessible data, reversible actions, and a named owner. Score candidates using Appendix C.
• Identify the credible second and third workflows now. A first workflow with nothing behind it fails the portfolio test regardless of its own merits.
• Map current state: triggers, systems, people, handoffs, wait states, exceptions, approvals, evidence, and failure modes.
• Measure the baseline before building anything. Cycle time, touch count, touch minutes, error and rework rate, cost per case.
• Define the smallest useful outcome: faster triage, better evidence package, fewer manual touches, or bounded automated action.
• Create a historical evaluation set with normal cases, edge cases, known failures, policy exceptions, and cases whose correct answer is escalation.

27.2 Weeks 3–4: platform and control design

• Define workflow-state schema, correlation ID, graph version binding, agent registry, model registry, tool contracts, policy gates, audit model, budget ceilings, and environment boundaries.
• Integrate the minimum systems needed; avoid building a universal connector platform before proving value.
• Implement read-only agents first, establish evidence provenance and trust classification, and stand up the evaluation harness before the first reasoning node ships.
• Agree model version pinning, upgrade handling, and data-residency constraints with risk and compliance.

27.3 Weeks 5–6: core graph build

• Implement intake, entity resolution, evidence, diagnosis, verification, planning, validation, and documentation nodes.
• Add deterministic tools with typed contracts, service identities, idempotency, and full logging.
• Add human approval nodes with decision-shaped evidence packages, escalation paths, timeout policy, loop bounds, and recovery checkpoints.
• Add quarantine handling and the manual recovery path — before they are needed, not after.
• Add injection canaries to the evaluation set.

27.4 Weeks 7–10: controlled pilot

• Replay historical cases, measure quality as a distribution across repeated runs, and fix systematic failure modes before live use.
• Run live in shadow or recommendation mode; compare agent outputs with human resolution.
• Introduce low-risk execution only where error cost is low, action is reversible, and validation is deterministic.
• Exercise the degradation path deliberately at least once.
• Review workflow traces weekly with platform, domain, and risk owners — including the traces that failed.

27.5 Weeks 11–12: evaluation and scale decision

The final row is the pilot's most important output. A pilot that succeeds on workflow one while providing no evidence about marginal cost has not answered the question that determines whether the program should continue.

27.6 Scale path after the pilot

The fastest path to enterprise value is horizontal reuse: keep the shared platform stable, add tools and agent capabilities only when reusable, and configure additional graphs using the same control model. The platform should become more standardized as the number of workflows increases, not more bespoke. If workflow four requires as much platform engineering as workflow one, stop and fix the platform before adding workflow five.

28Common failure modes and anti-patterns

29Business case, total cost, and measurement

The business case should be calculated at the portfolio level with workflow-level evidence, not justified with generalized statements about AI productivity.

29.1 The TCO model

ANNUAL BENEFIT  (per workflow)
    avoided touch time            × value of capacity actually released
  + reduced rework and repeat incidents
  + cycle-time value               (only where speed has a named consequence)
  + error and loss reduction
  + avoided leakage or downtime
  + incremental conversion or retention   (only where attributable)

ANNUAL COST  (per workflow)
    workflow build, amortized
  + workflow maintenance
  + model, retrieval, and infrastructure spend
  + human review burden            (approval time × approval volume)
  + exception burden               (cases the system fails to resolve,
                                    including cases it makes harder)

ANNUAL COST  (shared, once)
    platform build, amortized
  + platform operation             (FTE: upgrades, regression, drift,
                                    versioning, quarantine queue)

PORTFOLIO NET  =  Σ (workflow benefit − workflow cost) − shared platform cost

The two lines most often omitted are the human review burden and the exception burden. A workflow that resolves seventy percent of cases cleanly has not eliminated thirty percent of the work — it has changed its shape, and sometimes made it harder, because the residual cases are the difficult ones and they now arrive with a partial machine analysis that a human must evaluate before trusting.

29.2 Illustrative portfolio arithmetic

The figures below are illustrative planning values, not measurements. They are included to show how the arithmetic behaves, not what it will produce in any specific organization.

Assume a shared platform cost of roughly $260k per year (amortized build plus operating FTE), workflow cost of roughly $27k per year each, and workflow benefits that vary with the process automated:

Breakeven arrives at workflow five in this model. It moves substantially with two variables: the operating FTE (a platform run at half an FTE breaks even roughly two workflows earlier) and marginal workflow cost (if workflow four still costs what workflow one cost, breakeven never arrives).

Neither variable is a modeling assumption. Both are engineering and operating choices, made early, that determine whether the program succeeds.

29.3 Measurement categories

29.4 Avoid fake ROI

Do not assign dollar values to "hours saved" unless the organization can explain what capacity is actually released or what outcome improves. The strongest business cases connect reduced effort to measurable throughput, avoided hiring, faster revenue realization, lower loss, reduced downtime, improved collections, or improved service levels.

Four disciplines:

• Quote distributions, not averages. Cost and cycle time are both long-tailed.
• Count the human time the system creates, not only the time it removes.
• Report the failed cases. A workflow that resolves seventy percent cleanly may be excellent, but the business case must be built on seventy percent.
• Do not borrow another organization's numbers, including the ones in this paper.

30Enterprise maturity model

Organizations should not skip levels by granting autonomy before they have state, evidence, evaluation, identity, versioning, and operational ownership. More autonomy should be earned through measured reliability and stronger controls.

Two diagnostics for level 4, both answerable from telemetry rather than estimate: can the organization state the cost distribution and verifier pass rate of every production workflow from last month? And can it state what its most recent model version change cost in engineering time? An organization that cannot answer both is operating at level 3 with level 4 ambitions.

31Closing perspective

The most important architectural insight is that enterprise agent systems should be designed as operating systems for work, not as collections of clever conversations. Models are powerful reasoning components, but durable enterprise execution requires far more: state, identity, evidence, rules, permissions, deterministic tools, human accountability, recovery, observability, versioning, and disciplined workflow design.

Most of that list is not new. It is the accumulated practice of workflow engineering and distributed systems, and the honest framing of this architecture is that it inserts non-deterministic reasoning into a proven control structure at the specific points where deterministic branching has always failed — the ambiguous entity, the unstructured document, the exception nobody modeled. That is a narrower claim than "AI transforms operations," and a more defensible one.

It is also a claim with conditions attached. This architecture is expensive to build, expensive to evaluate, and wrong for a substantial class of processes. The organizations that succeed with it will be the ones that were honest about which category their processes fall into, that measured a baseline before building, and that judged the program on the cost of workflow six rather than the demo of workflow one.

For organizations evaluating this approach, the most effective first step is not a broad AI transformation program. It is a carefully chosen workflow, measured end to end before anything is built, rebuilt as a governed agent graph, evaluated against that baseline, and then used as the foundation for a reusable enterprise capability.

The same design method can be applied company by company: discover the operating workflow, measure it, identify the systems and evidence, define durable state, separate reasoning from execution, encode governance, build the smallest useful graph, and scale through reusable platform primitives.

APPENDIX AReference workflow contract

Each production workflow should have an explicit contract. The following structure is intentionally technology-neutral.

APPENDIX BExample agent-graph specification

Illustrative pseudo-YAML for a generic operational exception workflow. Routing uses evidence sufficiency, deterministic post-conditions, and independent verification rather than self-reported confidence; every loop is bounded; policy is evaluated at gate time.

workflow:
  name: operational_exception_resolution
  version: 1.4.0
  owner: operations_platform
  risk_tier: 2
  version_binding: pin_at_creation
  max_instance_age_days: 30

  budget:
    ceiling_usd: 8.00
    on_breach: pause_and_escalate

  reliability:
    quarantine_after_failures: 3
    degradation_path: preserve_state_route_to_human

  state:
    required:
      - workflow_id
      - graph_version
      - tenant
      - data_classification
      - subject
      - status
      - evidence
      - decisions
      - budget
      - audit

  nodes:

    intake:
      agent: intake_agent
      model_class: small
      tools: [case_read]
      idempotency_key: [source_system, source_id]
      next: resolve_entities

    resolve_entities:
      agent: entity_resolution_agent
      model_class: small
      tools: [reference_lookup]
      on_success: gather_evidence
      on_ambiguous: human_triage
      on_failure: human_triage

    gather_evidence:
      agent: evidence_agent
      model_class: standard
      tools: [system_read, logs_read, document_read]
      write_tools: none              # privilege split: reads untrusted content
      egress: none
      trust_exposure: untrusted
      freshness_window_minutes: 60
      loop_bound:
        max_iterations: 3
        on_exhausted: human_triage
      next: evidence_sufficiency

    evidence_sufficiency:
      type: deterministic_check
      requires:
        - required_sources_present
        - within_freshness_window
        - entity_ids_resolved
      transitions:
        - when: passed == true
          next: diagnose
        - else: gather_evidence

    diagnose:
      agent: diagnostic_agent
      model_class: frontier
      tools: [read_query, lineage_lookup, post_condition_test]
      outputs:
        - hypothesis
        - evidence_refs
        - post_condition_result
        - self_reported_confidence   # recorded for calibration, not routed on
      transitions:
        - when: post_condition_result == pass
          next: verify
        - when: output == insufficient_evidence
          next: gather_evidence
        - else: human_triage

    verify:
      agent: verifier_agent
      model_class: small
      context: [conclusion, cited_evidence]   # no conversation history
      transitions:
        - when: supported == true
          next: plan
        - else: human_triage

    plan:
      agent: planning_agent
      model_class: frontier
      input: structured_only                  # never raw untrusted text
      output_schema: typed_plan_object        # drawn from tool catalog only
      requires_per_step: [reversibility, compensation, validation_criteria]
      next: risk_gate

    risk_gate:
      policy: execution_policy
      evaluated: at_gate_time                 # policy is never pinned
      transitions:
        - when: risk_tier <= 2 and reversible == true
          next: execute
        - else: human_approval

    human_approval:
      approver_role: authorized_operator
      package:
        - typed_diff
        - evidence_with_provenance_and_trust
        - verifier_result
        - post_condition_result
        - expected_outcome
        - rollback_plan
        - out_of_scope_statement
      expiry_hours: 48
      on_expiry: escalate
      next_on_approve: execute
      next_on_reject: document

    execute:
      executor: deterministic_tool_gateway
      authorization: workflow_state_and_policy
      idempotency: required
      step_level_completion: recorded
      on_partial_failure: compensate_per_plan
      next: validate

    validate:
      agent: validation_agent
      model_class: standard
      checks: [expected_result, side_effects, downstream_reconciliation]
      transitions:
        - when: passed == true
          next: document
        - else: remediation_or_rollback

    document:
      agent: documentation_agent
      model_class: small
      tools: [case_update, knowledge_write]
      knowledge_write_requires: curation_review   # cross-tenant leak control
      terminal: true

APPENDIX CUse-case selection scorecard

Score candidate workflows from 1 (weak) to 5 (strong). Early pilots should favor high-value, high-measurability, data-accessible, reversible workflows with bounded risk.

Three dimensions are decision-critical and worth calling out. Case variance scores low for fully enumerable processes, because those should be built with a workflow engine (Section 21). Validation determinism matters because a workflow whose outcome cannot be automatically checked cannot safely be granted execution authority above tier 2. And reuse potential is the portfolio dimension from Section 3 — a workflow that creates no reusable asset must justify itself entirely on its own return, which few can.

Selected references

The architecture in this paper draws on established work in workflow management, distributed systems, reliability engineering, machine learning systems, LLM security, and AI governance. The following is a reading list for readers who want the foundations rather than an exhaustive bibliography.

Workflow and process management

1. Object Management Group. Business Process Model and Notation (BPMN), Version 2.0.
2. van der Aalst, W. M. P. and van Hee, K. Workflow Management: Models, Methods, and Systems. MIT Press, 2002.
3. Amazon Web Services. AWS Step Functions Developer Guide — durable state machines and execution history.
4. Temporal Technologies. Temporal Documentation — durable execution, workflow determinism, and replay.

Distributed systems and reliability

5. Garcia-Molina, H. and Salem, K. "Sagas." ACM SIGMOD, 1987.
6. Helland, P. "Life beyond Distributed Transactions: An Apostate's Opinion." CIDR, 2007.
7. Hohpe, G. and Woolf, B. Enterprise Integration Patterns. Addison-Wesley, 2003.
8. Nygard, M. Release It! Design and Deploy Production-Ready Software. Pragmatic Bookshelf, 2007 — circuit breakers and stability patterns.
9. Amazon Builders' Library. Making retries safe with idempotent APIs.
10. Beyer, B., Jones, C., Petoff, J. and Murphy, N. R. Site Reliability Engineering. O'Reilly, 2016.

Machine learning systems in production

11. Sculley, D. et al. "Hidden Technical Debt in Machine Learning Systems." NeurIPS, 2015.
12. Breck, E. et al. "The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction." IEEE Big Data, 2017.

LLM and agent security

13. Greshake, K. et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." ACM Workshop on Artificial Intelligence and Security (AISec), 2023.
14. OWASP. Top 10 for Large Language Model Applications.
15. Debenedetti, E. et al. "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents." NeurIPS Datasets and Benchmarks, 2024.

Calibration and model behavior

16. Guo, C., Pleiss, G., Sun, Y. and Weinberger, K. Q. "On Calibration of Modern Neural Networks." ICML, 2017.
17. Desai, S. and Durrett, G. "Calibration of Pre-trained Transformers." EMNLP, 2020.
18. Kadavath, S. et al. "Language Models (Mostly) Know What They Know." arXiv, 2022.

Governance and control frameworks

19. National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0), 2023.
20. ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system.
21. European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act).

Agent design and context behavior

22. Liu, N. F. et al. "Lost in the Middle: How Language Models Use Long Contexts." TACL, 2023.
23. Yao, S. et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR, 2023.
24. Anthropic. "Building Effective Agents." Engineering blog, 2024.

About the Author

Sammy Orangkhadivi is an enterprise AI and data architecture leader focused on designing and operationalizing AI systems for complex business environments. His work centers on multi-agent orchestration, Stateful Agent Graphs, agentic workflows, AI governance, enterprise automation, and the integration of AI reasoning with data platforms, APIs, workflow engines, and systems of record.

His primary interest is the transition from AI copilots and isolated agents to controlled digital operations: durable, measurable systems in which specialized AI agents reason over complex work, deterministic software executes governed actions, evidence and workflow state persist across the process, and human authority remains embedded at the appropriate risk boundaries.

His work spans financial services, healthcare, SaaS, insurance, data and analytics operations, and other environments where AI must operate across fragmented systems, complex rules, human approvals, regulatory constraints, and high volumes of operational exceptions.

He focuses particularly on the architecture required to move AI from experimentation into production: agent orchestration, workflow-state design, evidence and decision provenance, model and tool governance, human-in-the-loop controls, evaluation under non-determinism, security boundaries, observability, and the economics of enterprise-scale AI automation.