When not to build an agent
By the end: Apply a test for whether a problem justifies an agent, and pick the simpler option when it does not.
The published guidance from every lab that has built these systems at scale converges on one uncomfortable recommendation: find the simplest thing that works, and only add autonomy when you can show it helps. Most production systems that people describe as agents are workflows, and they are better for it.
Two more questions sharpen it. Is there a way for the system to tell whether it is making progress — a test that passes, a record that matches, a check that succeeds? An agent without feedback is a model guessing repeatedly and gaining nothing. And is the cost of a wrong action acceptable, or recoverable by a person in reasonable time? Autonomy multiplies both good and bad decisions.
- Extract the order number from an email → single call. One step, verifiable, no discovery.
- Route the ticket, then draft a reply from the right template → workflow. Two steps, both known in advance.
- Investigate why a customer was charged twice → agent. You cannot know how many systems must be consulted until you start looking.
- Issue the refund → not the agent. A person confirms, because money leaving the company is not recoverable by an apology.
That last line is the pattern worth internalising: an agent can be excellent at the investigation and still be the wrong thing to trust with the irreversible act at the end. Splitting those two is often what makes an agent shippable.