Agents
·
·
6 min read
Pick the right one.
A plain-English way to decide which one a task needs, and why most teams need fewer agents than they think.
By
Alex Morgan
Most weeks, someone asks us to build them “an AI agent”. About half the time, what they actually need is an automation: a fixed set of steps that runs the same way every time, without anything having to think. The other half of the time, an agent really is the right tool, and a rigid automation would break the first time the input looked slightly different.
Picking the wrong one is expensive in both directions. An agent where an automation would do is slower, costs more per run and adds a step that can be wrong. An automation where an agent is needed ends up wrapped in so many special cases that nobody dares touch it. Here is how we decide.
The one-question test
Ask one thing about the task: does the next step depend on judgement?
If you could write every step on an index card and hand it to a new starter, it is an automation. “When a form is submitted, add a row to the sheet and send the welcome email” needs no judgement at all. If the steps change with what is in front of you, such as a messy invoice, an angry email or a vague request, then somebody is reading, weighing and deciding. That reading and deciding is the part an agent can take on.
What an automation is good at
Automations shine wherever the path is fixed. Typical examples:
Moving a new deal from your CRM into your project tool when it is marked as won.
Sending a reminder two days before a contract renews.
Copying form answers into a spreadsheet and notifying the right channel.
Creating accounts and folders for a new hire from one checklist.
They are cheap to run, fast, easy to test and easy to hand over. They behave the same way at three in the morning as they do in a demo, and when they fail, they fail loudly in a way you can trace.
What an agent is good at
Agents earn their place where the input is unstructured and the right answer depends on context:
Reading a supplier invoice in any layout and pulling out the fields you need.
Drafting a reply that matches the tone and history of a support ticket.
Deciding which of three account managers a new lead belongs to.
Summarising a long email thread into the three decisions somebody has to make.
The trade-off is real. An agent is slower than a rule, costs something every time it runs and will occasionally be wrong. That is fine, as long as you design for it: give it a narrow job, show it examples and put a person in front of anything that is hard to undo.
The questions we ask before building either
How often does it happen? A task that runs twice a month rarely justifies an agent. A checklist might be enough.
How varied is the input? If ninety per cent of cases look the same, rules can cover them and an agent can handle the rest.
What does a mistake cost? A wrong tag on a ticket is cheap. A wrong payment is not.
Who checks the result? If nobody would notice an error for a week, build in a review step before you build anything clever.
Can we explain the decision? If you can't describe how a person makes the call today, an agent won't magically know either.
Most teams need both
The systems we are proudest of are mostly plain automation, with a small agent sitting at the one step that needs judgement. Take supplier invoices. An automation watches the inbox and pulls out the attachment. An agent reads it, extracts the supplier, amount and due date, and flags anything that doesn't match the purchase order. Anything over an agreed amount waits for a person to approve it. Then another automation files the invoice and posts it to your accounts software.
Keep the agent's job small and the whole thing stays fast, cheap and easy to check.
Each piece does what it is good at. The automation gives you reliability and an audit trail, the agent handles the messy reading, and the person keeps control of the decisions that matter.
Where to start
Pick one task your team does every week. Write down every step, in order, the way you would explain it to a new starter. Then circle the steps where someone has to read something and make a call. Everything outside the circles is automation. The circles are where an agent might help, and the smaller you can make them, the better the result will be.
Sample article for the Relay template. Replace it with your own writing.
Field notes from building agents and automations for real teams. Short, practical and free of hype, with a new post every fortnight.
We are always glad to meet operators and engineers who hate busywork.