Agentic Workflow Automation

An agent is a system that decides which steps to take, calls real tools to take them, and keeps track of what it has done. That autonomy is the point — and the risk. The engineering worth paying for is the part that decides where the agent must stop and ask a human.

When an agent is the right answer

Agents suit work that is multi-step, involves several systems, and has enough variation that a fixed script keeps breaking: qualifying and routing inbound enquiries, extracting terms from contracts and filing them, reconciling records between a CRM and a finance system, triaging support tickets with context from documentation and history, or preparing a draft that a person reviews and sends.

They are the wrong answer for work that is genuinely deterministic. If the rules fit in a flowchart and rarely change, a scheduled job or a workflow engine will be cheaper, faster and far easier to debug. I will say so rather than build the more interesting thing.

Tools are an API surface, and should be treated like one

An agent is only as good as the tools you give it. Each tool is a function with a schema, a contract and a blast radius, and it deserves the same care as a public endpoint:

• Narrow and explicit — create_draft_invoice beats run_sql. Broad tools invite creative misuse.
• Validated inputs — arguments are checked before execution, not trusted because the model produced them.
• Least privilege — the agent gets its own service account with exactly the permissions its tools require.
• Idempotent where possible — a retried step should not create a second record.
• Read and write separated — gathering information is cheap and safe; changing state is neither.

Human approval at the points that matter

Every workflow gets an explicit map of which steps are reversible and which are not. Sending an external email, moving money, deleting records, publishing content and signing anything are checkpoints by default: the agent prepares the action, presents exactly what it intends to do, and waits.

This is not a limitation to be engineered away later. It is what makes the system deployable to people who will be accountable for its output, and in practice it is what gets an automation project approved at all. As confidence builds, individual checkpoints can be relaxed with evidence behind the decision.

State, retries and failure

Real workflows pause. They wait on an approval overnight, hit a rate limit, or encounter a third-party API that is down. The agent therefore needs durable state rather than a variable in memory: where it is in the workflow, what it has already done, what it is waiting for.

Alongside that: retry policy with backoff for transient failures, a step budget so a confused agent cannot loop indefinitely and bill you for the privilege, dead-lettering for runs that need a human, and a full trace of every decision, tool call, argument and result. When something goes wrong at 2am, that trace is the difference between a ten-minute diagnosis and a shrug.

Integration with the systems you already run

Agentic automation is mostly integration work. The agent needs to reach your CRM, your CMS, your ticketing system, your document store, your database and your messaging platform — with proper authentication, rate limiting, error handling and sandbox environments for testing.

Over fourteen years of building on Drupal, WordPress, PHP, Python and Node.js backends, most of my time on these projects goes into that integration layer rather than the agent logic itself. That is the correct ratio, and a proposal that implies otherwise is underestimating the job.

How an engagement usually runs

1. Map the workflow — the current process, decision points, systems touched, and which actions are irreversible.
2. Define the tools — the specific functions the agent may call, their schemas, permissions and failure modes.
3. Build the graph — steps, branches, checkpoints and durable state.
4. Shadow mode — the agent runs against real inputs and proposes actions without executing them, so its judgement can be checked safely.
5. Supervised rollout — execution enabled with approval gates, on a narrow slice of volume first.
6. Operate — tracing, alerting, cost tracking, and relaxing checkpoints only where the evidence supports it.

See this in practice: Agentic Workflow Automation

Common questions