Skip to content
Agentic Engineering Fieldbook

Business Process and Operations Agents

Business processes are full of work that appears suitable for agents: read a request, gather missing facts, route a case, draft a response, update a system, wait for approval, follow up, and recover when something goes wrong. Unlike a single chat, these processes have state, owners, deadlines, external effects, and audit obligations.

The danger is treating an adaptive agent as the process itself. A model can help interpret, draft, classify, and coordinate. It should not silently become the authority that defines the process, commits external effects, forgets approvals, or decides exceptions without accountable ownership.

Thesis

Section titled “Thesis”

Business-process agents are safest when model-mediated work sits inside a governed process model: deterministic workflow systems own durable state, commitments, timers, approvals, and recovery, while the agent handles interpretation, drafting, routing, and exception triage within explicit authority.

The accepted outcome is progress in a business case, not merely a completed conversation. The system should be able to show where the case is, who owns it, what evidence supports the next transition, which actions have committed, and what happens if the agent cannot continue.

A process agent needs a case model

Section titled “A process agent needs a case model”

Before adding an agent, define the case:

  • objective and business value;
  • initiating actor, affected parties, and accountable owner;
  • current state and allowed transitions;
  • required evidence for each transition;
  • deadlines, service objectives, and expiry behavior;
  • approvals and exception authorities;
  • external systems and side effects;
  • compensation, correction, and audit requirements.

Without this model, the agent’s plan becomes the process. That is fragile. The model may skip a required approval, rerun an irreversible operation, send a message before evidence is complete, or continue work after authority has expired.

The case model does not need to be heavyweight BPMN for every task. A lightweight state machine may be enough for an internal workflow. The important point is that durable process state lives outside the model context, and transitions are accepted by deterministic controls or responsible actors.

Separate workflow control from model discretion

Section titled “Separate workflow control from model discretion”

Business-process agents combine two different kinds of control:

  • deterministic workflow control: timers, queues, retries, approvals, state transitions, idempotency, audit, and recovery;
  • model-mediated discretion: interpreting documents, summarizing evidence, selecting a routine path, drafting communication, or identifying an exception.

OpenAI’s agent-building article describes tools, guardrails, handoffs, and human intervention as agent-system concerns (OpenAI, 2026). Durable workflow platforms such as Temporal describe persisted workflow execution, activities, retries, and replay as control mechanisms around long-running work (Temporal Workflow Execution). BPMN tooling such as Camunda provides a vocabulary for tasks, events, gateways, user tasks, and compensation (Camunda BPMN documentation).

The pattern is to let deterministic workflow own “what state may change” and “when.” Let the agent help decide “what does this input mean” or “which eligible next step should be proposed” when evidence and authority allow it.

External effects require transition proposals

Section titled “External effects require transition proposals”

In business operations, external effects include:

  • creating or closing a case;
  • changing customer or employee records;
  • sending messages;
  • approving expenses;
  • issuing refunds;
  • placing orders;
  • changing access;
  • notifying regulators, partners, or customers;
  • starting or stopping downstream automation.

The model should generally propose transitions before they commit. A transition proposal should identify the target system, operation, actor, authority, inputs, evidence, expected effect, reversibility, approval requirement, and timeout. The execution boundary validates and records the proposal. If the proposal is incomplete, unsupported, out of policy, or stale, it should be rejected, revised, or escalated.

This preserves a critical distinction: the agent may reason about a business action, but the business system commits it.

Approvals must be meaningful

Section titled “Approvals must be meaningful”

Many process-agent designs add an approval step and then treat the design as safe. Approval is only meaningful when the approver has:

  • authority to approve the action;
  • enough evidence to understand the decision;
  • time and attention appropriate to the consequence;
  • a clear reject, edit, or escalate path;
  • a safe default if they do not respond;
  • a record of what exactly was approved.

Approval should bind to a concrete transition and current state. A stale approval should not be reused after the case changed. A broad approval such as “handle this vendor onboarding” should not authorize every payment, access grant, contract change, and notification that might occur later.

Exception handling is the product, not an edge case

Section titled “Exception handling is the product, not an edge case”

Business processes contain exceptions: missing documents, contradictory policies, angry customers, partial outages, unusual discounts, duplicate records, expired approvals, failed payments, and ambiguous ownership. Agents can help detect and route exceptions, but they should not be forced to invent policy when no routine path applies.

Design explicit exception states:

  • needs missing information;
  • needs policy owner;
  • needs customer or requester confirmation;
  • needs risk acceptance;
  • blocked by dependency;
  • external effect unknown;
  • compensation required;
  • expired or abandoned;
  • escalated to human owner.

The user-facing experience should show these states without pretending that work is complete. A partial result may still be valuable if it preserves evidence, identifies the blocker, and leaves the case ready for the right owner.

Recovery is part of process design

Section titled “Recovery is part of process design”

External effects can fail, partially commit, or become unknowable to the caller. Retrying blindly can duplicate orders, send repeated messages, or double-credit an account. The reliability chapter covers the general machinery; process agents must apply it to business meaning.

Microsoft Azure’s compensating transaction pattern is useful because it distinguishes compensation from simple rollback and stresses that recovery itself can fail or require human intervention (Azure Architecture Center). For process agents, compensation should be a domain operation with ownership and evidence, not a magical undo button.

Useful recovery records include:

  • logical intent and idempotency key;
  • external system request and response;
  • last known authoritative state;
  • whether the effect is confirmed, failed, unknown, or partially committed;
  • compensation options and constraints;
  • customer, partner, or internal notifications required;
  • owner responsible for reconciliation.

Design options

Section titled “Design options”
Option Best fit Main risk
Agent-assisted workflow step Drafting, summarizing, classifying, extracting fields Agent output may be accepted without evidence
Process copilot Human-owned case work with suggested next actions Human becomes rubber stamp under volume pressure
Bounded process agent Routine transitions with strict tools and approvals Hidden authority creep and stale state
Exception triage agent Routing nonstandard cases to owners Misclassification delays urgent work
Autonomous process segment Narrow low-risk segment with strong recovery Difficult to prove safety beyond that segment

Most organizations should combine deterministic workflows with agentic steps. The agent can make the process less brittle, but the process model should remain the source of truth.

Failure modes

Section titled “Failure modes”
  1. The agent becomes the process. State exists only in conversation and cannot be audited or resumed safely.
  2. Approval drift. A person approves one thing, but the case changes before the action commits.
  3. Exception invention. The agent creates a plausible policy for a case that required an owner.
  4. Duplicate effect. A retry repeats a payment, order, access grant, or notification.
  5. Silent expiration. Work continues after an approval, quote, consent, or data snapshot is no longer valid.
  6. Unowned compensation. The system detects a bad effect but no one owns correction.
  7. Metric blindness. The process appears faster while errors, complaints, or manual cleanup increase.

Fieldbook guidance

Section titled “Fieldbook guidance”

Do not ask whether an agent can “run the process” until the process has a state model. Ask which transitions need interpretation, which require deterministic validation, which require human authority, and which must be recoverable.

Keep durable state outside the model. Use the model to propose, explain, and triage. Use workflow and business systems to commit, wait, retry, expire, notify, and record.

Treat exceptions as first-class. If a business process has no safe default for missing evidence, failed dependencies, or ambiguous policy, the agent should not fill the gap with confidence. It should preserve the case and hand it to an accountable owner.

Checklist

Section titled “Checklist”
  • Is there a durable case model with states, transitions, owners, deadlines, and terminal outcomes?
  • Are model-mediated decisions separated from deterministic commits?
  • Does each external effect have an execution boundary, idempotency policy, audit record, and recovery path?
  • Are approvals bound to a specific actor, action, scope, evidence, state, and time?
  • Are exception states explicit and routed to responsible owners?
  • Can the system recover from failed, partial, duplicate, or unknown external effects?
  • Do process metrics include accepted outcomes, corrections, complaints, aging, and manual cleanup?
  • Can a reviewer reconstruct the case from durable records rather than chat history?

References and how they are used

Section titled “References and how they are used”