What traditional automation actually is
"Traditional automation" covers a wide family: rules engines, robotic process automation driving a user interface, trigger-based workflow tools, scheduled scripts, and API integrations that move records between systems. What unites them is that they are deterministic. Given the same input and the same state, they take the same path and produce the same output. Every branch was written by a person in advance.
That is a strength, not a limitation. Deterministic automation is cheap to run, simple to test and easy to explain to an auditor. When a rule misfires, you can read it, find the case it missed and fix it. The price is rigidity: the system handles exactly the cases it was built for. A new input format, a judgement call or an unanticipated exception stops the line and waits for a person.
Most operational software is, and should remain, this kind of automation. A payroll run, a nightly sync to Xero, a webhook that opens a support ticket: none of these needs a model.
What an AI agent is
An AI agent is a language model placed inside a control loop with three things attached: tools it can call (search a database, read a document, draft an email), memory of what has happened so far in the task, and a goal. On each turn the model reads the current state, picks a tool or produces an answer, observes the result and goes again until the goal is met or a stopping rule is hit.
The important word is bounded. An agent worth deploying does not have open access to your systems. It has a specific set of tools, each with its own permissions, a budget of steps and tokens, and defined points where it must hand off to a person. The model supplies judgement about messy input; the surrounding software supplies the limits. That is the shape of the custom AI agents we build.
What an agent gives you is tolerance for variation: it can read an invoice in a format it has never seen, work out which of three similar suppliers it belongs to, and notice that the total does not match the line items. What it costs you is predictability. The same input can take a slightly different path on a different day, which has consequences for testing, cost and auditability.
Five questions that decide it
Before anyone talks about models, put the process through five questions.
- Is the input structured? A clean record in a known schema can be handled by a rule. An email thread, a scanned PDF, a free-text form or a call transcript has to be interpreted first, and that is where a model earns its place.
- Is the path fixed? Draw the process. If it fits on one page with a handful of branches, it is a workflow. If the honest diagram is "it depends, and an experienced person knows what to look for", the path is not fixed.
- Is judgement needed? Separate lookup from judgement. Checking whether a participant's plan has budget remaining is lookup. Deciding whether an unusual claim is plausible is judgement. Rules do lookup very well and judgement badly.
- What does a wrong action cost? A misrouted internal notification is cheap. A payment to the wrong account, a message to a client that misstates a fact, or a deleted record is not. The higher the cost, the more you want either a deterministic path or a human approval before the action lands.
- Can a human approve in time? Some steps can wait an hour for a person to tick a box; some cannot. Where approval is feasible, an agent can take on more because its output is reviewed before it acts. Where it is not, keep the agent to reading and recommending and let deterministic code do the writing.
Where the answers are messy input, a variable path and real judgement, an agent step is justified. Where they are structured input, a fixed path and an expensive mistake, the work belongs in rules, with or without a model helping at the edges.
Side by side
Neither column below is better; they are good at different jobs.
| Concern | Traditional automation | AI agent |
|---|---|---|
| Predictability | Same input, same output, every time. | Same goal, similar output; the path can vary between runs. |
| Messy input | Fails or stops on anything outside the expected format. | Interprets unstructured documents, free text and ambiguous cases. |
| Cost per run | Close to nothing once built; compute is trivial. | Model calls on every step; grows with tokens and tool calls, so it needs a budget. |
| Failure modes | Loud and specific: an exception, a stuck queue, a null field. | Quiet and plausible: a confident wrong answer, a loop, an action taken on a misread instruction. |
| Auditability | Every branch is code; the log says which rule fired. | Needs deliberate tracing: every prompt, tool call and decision logged and replayable. |
| Build effort | Low to moderate; the hard part is mapping the process. | Moderate to high; the hard part is evaluation, guardrails and approvals. |
| Best fit | High-volume, well-defined, repeatable steps over structured data. | Variable input, judgement calls and exceptions: work that needs a person to read and decide. |
The hybrid pattern that fits most processes
Very few real processes are purely one or the other. The pattern we recommend is deterministic rails, agent judgement at specific steps, and human approval wherever the consequences are real.
The trigger, the data fetches, the validation and the final write to the system of record are ordinary code, running on queues and state machines with retries and idempotency keys. Inside that flow, one or two steps go to an agent because they involve reading something unstructured or making a call. The agent should return a structured result with a confidence score and its reasoning. Above a threshold the rails carry on; below it, or whenever the next action cannot be undone, the work waits in a queue for a person.
- TriggerEvent, schedule or inbound document. Deterministic.
- Fetch and validatePull records, check the schema, reject the obviously wrong. Deterministic.
- Judgement stepAgent reads, classifies, reconciles or drafts; returns structured output with a confidence score.
- ApprovalLow confidence or high consequence waits for a person.
- Write and recordCommit to the system of record; log every step. Deterministic.
This gives you the tolerance of an agent where the variation lives and the predictability of rules everywhere else. It also makes the system testable. The deterministic parts get unit tests; the agent step gets an evaluation set built from real cases; and reviewer decisions from the approval queue feed back into that set. It is the discipline behind our agentic workflow automation.
Two worked examples
The two engagements below sit at opposite ends of the same spectrum; both are described in general terms.
Invoice processing and reconciliation. DisabilityAssessments is an NDIS allied health provider. The administration around that service is onboarding, matching, invoicing providers and plan managers, and reconciling payments, and we built each of those steps as a system, sitting on secure storage for patient data. Run a process like that through the framework and most of the answers point to rails. Matching and reconciliation are lookup over records the business already holds, the path is largely fixed, and a wrong payment is expensive, so the bulk of the work belongs in deterministic code with the exceptions surfaced for a person. The client reports 90% of its operations automated.
Operations agents inside a platform. For Modedu we built agentic workflows through the operations around a custom SaaS platform; for Luxpip we built agentic solutions for internal operations behind a trading product. This is the other end of the spectrum: internal operations, where the input tends to vary, the path is rarely fixed and the work has historically needed a person to read and decide. For work like that, the hybrid shape above is the one to build: the agent reads and proposes, deterministic code carries out and records, and a person approves where the consequence is real. Luxpip reports a 75% reduction in manual workload; Modedu reports 2× revenue within six months of going live.
When not to use an agent
An agent is the wrong tool when:
- The process is fully specified and the input is clean. A rule is cheaper, faster and easier to audit; a model adds cost and variance for nothing.
- A wrong action is expensive and cannot be reviewed first. Large payments, regulatory submissions, destructive changes to data: keep these on deterministic paths with explicit human sign-off.
- Nobody can describe a good outcome. If you cannot write down the cases the agent should get right, you cannot build an evaluation set or know whether it works. It is the same gap that stops a proof of concept reaching production.
- Volume is tiny. An agent that handles a handful of cases a month rarely repays the engineering; a checklist and a person will do.
- The real problem is a missing integration. If two systems do not talk to each other, the fix is an integration with your existing systems, not a model reading screens.
An agent also cannot repair a process nobody understands. If the workflow lives in one person's head, map it before automating any of it.
How to start
Start by mapping the workflow, not by choosing a model. Write down every step, who does it, what they look at, what they decide, and what happens when it goes wrong. Mark each step as lookup or judgement, structured or messy, reversible or not. The map usually shows that most of the process is rails, a few steps need judgement, and one or two need a person regardless.
From there the build order is fixed. Rails first, so the deterministic path works end to end with a human doing the judgement steps by hand. Then replace one judgement step with an agent, behind an approval, and collect the reviewer decisions. Widen the agent's scope only where those decisions show it is reliable, and leave the approval in place where they do not. Our AI automation engagements run this way, and the same approach underpins our AI agent development: the model is the smallest part; the system around it is the work. Discovery, the first paid stage in how we work, is where we do that mapping with you.
Where to go next
- AI agent development: tool-using agents with permissions, approvals and audit trails.
- AI automation: agentic workflows running on deterministic rails.
- AI engineering: the evaluation, observability and infrastructure underneath both.