Business Process Automation

The bulk of enterprise agentic work is not chat. It is background processing: an invoice PDF arrives, fields are extracted, the vendor is matched in the ERP, a purchase order is checked, an approval is requested if amounts differ, the payment is scheduled, and the outcome is logged. The model contributes judgment at a few steps (extraction, matching ambiguity, drafting the approval note); everything else is integration code.

The systems involved are the usual suspects, and each brings its own failure modes: REST APIs rate-limit and time out, databases need transactions, documents parse badly, SaaS tools have webhooks that fire twice, internal services have undocumented auth, and humans take three days to click approve.

Automation runs fail halfway. The network drops after the payment API accepted the request but before the response arrived; the worker restarts; the model, seeing no result, calls schedule_payment again. Without idempotency the vendor is paid twice. With it, the second call carries the same key and the API returns the original result.

Idempotency has to be designed in at the tool layer, not hoped for at the model layer. The runtime derives a key deterministically from the run id and step (or from business identity like invoice_id), passes it with every write, and stores the result so replays are served from the store. The model never sees or invents keys.

When an automated process moves money, changes a customer record or sends a contract, someone will eventually ask "why did this happen?". The answer must be reconstructible from stored data: the input document, the extracted fields, the model's reasoning for the vendor match, the tool calls with arguments and results, who approved what and when, and the final action. This is a trace with retention and access control, not a debug log — see Tracing Agents.

Approvals turn a run into a long-lived process. The state must be persisted so the run can wait hours or days, survive deploys, and resume exactly where it paused. Approvals should carry enough context for a two-minute decision: what will happen, why the system is unsure, and what the alternative is. Route by risk: auto-approve under a threshold, one approver up to another, two above.

Most business processes are known in advance. The invoice flow above has five steps in a fixed order with one decision point. That is a graph, and graphs are what workflow engines (durable execution systems, state machines, BPMN tools) are built for: they persist state per step, retry with policies, handle timers and human tasks, and give you a visual of where every run is. The model is called inside a step; it does not own the control flow.

Reserve the agent for the step whose path is unknowable: reconciling a vendor whose name, address and tax id all differ slightly across three systems may take one lookup or seven. Put that step in a bounded agent loop inside the workflow. You get durability and auditability from the engine and adaptability only where it pays.