Agentic Workflow Automation

A multi-step agent that reads incoming work, decides which tools to call, updates the systems you already run, and stops for human approval before anything it cannot undo. The interesting engineering is not the autonomy — it is the constraints around it.

The problem it solves

Some processes are too varied for a fixed script but too repetitive to justify a person doing them end to end. A new enquiry arrives; someone reads it, decides what it is, updates the CRM, notifies a team, pulls the relevant contract, extracts a few terms, files them, and flags anything unusual for a manager. Every step is simple. The sequence changes constantly, which is why rule-based automation keeps breaking.

An agent handles the variation. The constraint that makes it deployable is that it does not get to decide what is irreversible.

How it is built

Tools before logic. The agent gets a set of narrow, explicitly defined functions — create_crm_record, extract_contract_terms, request_approval — each with a validated schema and its own least-privilege credentials. Broad tools invite creative misuse, so run_sql never appears on the list.

A graph, not a loop. The workflow is modelled as explicit steps and branches with durable state, so a run can pause overnight waiting for approval, survive a restart, and resume exactly where it stopped.

Checkpoints on irreversible actions. Every step is classified as reversible or not. Sending external email, moving money, deleting records and publishing content are approval gates by default: the agent prepares the action, shows exactly what it intends to do, and waits.

Failure handling. Retries with backoff for transient errors, a step budget so a confused agent stops rather than looping, and dead-lettering with the full trace attached for runs that need a person.

Tracing. Every decision, tool call, argument and result is recorded. When something goes wrong, the trace is the difference between a ten-minute diagnosis and a shrug.

Shadow mode before anything executes

The agent runs against real inputs and records what it would have done, without executing anything. Those proposed actions get compared against what the team would have done. Only when the agreement rate is convincing does execution get switched on, and even then it starts on a narrow slice of volume with every gate active.

This step is what turns "we built an AI agent" into something an operations manager will actually sign off on. Skipping it is the most common reason these projects stall at the pilot stage — nobody can quantify the risk, so nobody approves the rollout.

Where the time actually goes

Most of the build is integration, not agent logic: authenticating against the CRM, handling the ticketing system's rate limits, dealing with an internal system whose API was written in 2014 and documented never, setting up sandbox environments that behave enough like production to test against.

That ratio is normal and worth planning for honestly. A proposal that puts most of the effort into the agent itself has usually not looked closely at the systems it needs to touch.