Solution
Automation that is durable, observable and under human control
We automate multi-step business processes with workflow engines, document processing and AI agents, choosing deterministic rules where they suffice and AI where judgement over unstructured input is required.
The problem space
Most operational work in an organisation is a process that crosses systems: an invoice arrives by email, is checked against a purchase order in the ERP, approved by a manager, posted to the ledger and paid. People carry the process between systems, re-keying data and remembering what comes next. Automation removes that carrying. Doing it well means the automated process must be at least as reliable as the person it replaces, and easier to inspect.
There are two kinds of step in such a process. Some are fully specified: if the amount is under a threshold and the supplier is approved, route to payment. These belong in deterministic code or a rules engine, where they are fast, cheap, testable and explainable. Others involve unstructured input or judgement: reading a scanned document, classifying a customer email, drafting a reply, deciding which of several records an ambiguous reference means. These are where language models earn their place.
The engineering problem is combining the two without losing control. An AI agent that can call tools is powerful and non-deterministic. Placed inside a durable workflow with typed inputs and outputs, bounded permissions, validation and human approval at the points that matter, it becomes a component that can be trusted with real work. Left to run freely against production systems, it does not.
Why it is hard
Engineering challenges
Automations that fail silently
A scheduled script throws an error at step three and stops. Nothing retries it, nobody is told, and the half-finished work is found when a customer complains. Without persisted state and visibility, every automation is a hidden liability.
Using AI where a rule would do
Passing a decision to a language model when the logic is fully known adds cost, latency and a small chance of a wrong answer on every run, and makes the outcome harder to explain. The opposite error is as common: hundreds of brittle rules attempting to parse free text that a model would handle easily.
Agents with too much authority
An agent given broad API credentials and an open-ended goal can take actions nobody intended, particularly if a document it reads contains injected instructions. The risk scales with the permissions it holds. Authority has to be scoped per task and consequential actions gated.
Document variability
Invoices, forms and contracts arrive as scans, photographs and PDFs in hundreds of layouts. Template-based extraction breaks when a supplier changes a format. Extraction needs confidence scores, validation against known data and a route to a person for the uncertain cases.
Partial failure across systems
A process updates the CRM, then fails to update the ERP. Retrying from the start duplicates the first update; stopping leaves the systems inconsistent. Each step needs to be idempotent, and the process needs defined compensation for steps that cannot be completed.
Human approval as an afterthought
Approvals handled by email have no deadline, no escalation and no record tied to the process. Work stalls in an inbox. Human tasks need to be first-class steps with assignment, timeouts, delegation and an audit trail.
How we build it
Architecture
Processes run on a durable workflow engine that persists every step. Deterministic rules, document processing and AI agents are invoked as activities with typed contracts, and human decisions are modelled as explicit tasks.
- 01
Durable workflow engine
An engine such as Temporal or a BPMN platform such as Camunda executes each process as a persisted state machine. If a worker crashes, the process resumes from its last completed step. Retries, timeouts and timers are declared in the workflow definition, and a process can wait for days on an external event without holding resources.
- 02
Integration connectors
Each external system is accessed through a connector that handles authentication, rate limits, pagination and error mapping. Connector operations are designed to be idempotent, using natural keys or idempotency tokens, so a retried step does not create a duplicate record. Where a system offers no API, robotic process automation over the user interface is used as a last resort and isolated behind the same interface.
- 03
Rules and decision service
Business rules that are fully specified live in a decision service as versioned decision tables or code, separate from the workflow that calls them. This keeps policy changes reviewable and testable on their own. Every evaluation records its inputs, the rule version and the result, which gives a direct explanation for any automated decision.
- 04
Document processing pipeline
Incoming documents are classified, passed through optical character recognition and layout analysis, and have fields extracted by models suited to the document type. Extracted values are validated against reference data, for example matching a supplier and purchase order in the ERP, and assigned a confidence score. High-confidence results proceed automatically; the remainder go to a review screen that shows the source alongside the extracted fields.
- 05
AI agent runtime
Agents are invoked as workflow activities with a defined goal, a fixed set of tools and limits on steps, time and spend. Tools are narrow functions with typed parameters, executed with credentials scoped to the task. Agent output must conform to a schema and passes validation before the workflow acts on it, and content the agent reads is treated as untrusted data.
- 06
Human task service
Approvals, reviews and exceptions are tasks assigned to a role or person with a due time, escalation path and delegation rules. The reviewer sees the evidence the automation used and the action it proposes, and can approve, amend or reject. The decision is recorded against the workflow instance and resumes it.
- 07
Process observability
Every workflow instance exposes its current step, history, inputs and outputs. Dashboards report throughput, cycle time, failure rate, the share of cases handled without human intervention and, for AI steps, quality against a maintained evaluation set. Failed instances are surfaced in an operations queue where they can be inspected, corrected and resumed.
Reason
- 01
Trigger
Event, schedule or user request
- 02
Plan
Break the goal into bounded steps
- 03
Tool calls
Read-only lookups via typed tools
- 04
Draft action
Proposed change with its evidence
Act under control
- 01
Policy check
Limits, permissions, risk rating
- 02
Human approval
Required for high-impact actions
- 03
Act
Idempotent write to target system
- 04
Verify
Confirm the result, retry or roll back
- 05
Audit
Every step logged and replayable
What an engagement delivers
- Process analysis identifying rule-based and judgement-based steps
- Workflow definitions deployed on a durable engine
- Idempotent connectors to the systems involved
- Document extraction pipeline with confidence thresholds and review screen
- AI agent tools, permission scopes and evaluation set
- Approval and exception handling with escalation rules
- Operations dashboard and runbook for failed instances
Before you start
Decisions to make early
- Rules or AI for a given step
- Use rules when the inputs are structured and the logic can be written down completely; they are cheaper, faster and auditable. Use AI when the input is unstructured or the variety of cases makes rules unmanageable. A good default is a model that extracts and classifies, followed by rules that decide, so the decision itself stays deterministic.
- Where to place human approval
- Place it where an error is costly or irreversible: payments, external communications, contract changes, anything touching a customer's legal position. Use confidence thresholds so people review the uncertain cases and not every case. Review the thresholds as evidence accumulates; removing a human step should be a deliberate, recorded decision.
- Workflow engine or event choreography
- Use a workflow engine when a process has a defined sequence, needs a clear view of its state and has compensation logic. Use event choreography when independent systems react to facts and no single party owns the whole flow. Long choreographed chains are hard to trace and change, so an orchestrator is usually the better fit for core business processes.
- One capable agent or several narrow ones
- Prefer narrow agents with a small tool set and a single responsibility, composed by the workflow. They are easier to evaluate, cheaper to run and limit the effect of any one failure. A single general agent with many tools is simpler to start and harder to predict, test and secure.
FAQ
Common questions
How is this different from robotic process automation?
Robotic process automation drives applications through their user interface, which is useful when no API exists and fragile when screens change. The approach here integrates through APIs and events wherever possible, persists process state in a workflow engine, and uses AI for unstructured input. UI automation is kept for systems that offer no alternative.
Can an AI agent take actions without supervision?
It can for actions that are low in impact and reversible, within permissions scoped to that task. Consequential actions go through a human approval step. The boundary is set per process with the people accountable for it and is enforced by the workflow, not left to the agent's judgement.
What happens when a step fails?
The engine retries transient failures with backoff. If the failure persists, the instance pauses in a visible error state with its full history, and an operator can correct the data and resume it from that step. For multi-system operations, compensating actions reverse the steps already completed.
Where should an organisation start?
With a process that is frequent, well understood and painful, where inputs and outcomes can be measured. Automating one end-to-end process on a proper engine establishes the connectors, approval patterns and monitoring that later processes reuse.
Related
Have a system that needs to work in production?
Tell us what you are building. An engineer will read it and reply within two working days.