When Not to Build an Agent: The Discipline of Saying No
Not every process should be an agent. Knowing when the answer is a simple rule or a human is what separates an architect from a hype-chaser.
The most valuable thing an architect can say about agentic AI is sometimes 'not this one'. Not every process wants an agent. Some need a simple automation rule, some genuinely need a human, and knowing the difference is what separates a serious advisor from someone chasing the shiny thing.
If a rule does it, use a rule
If a process is fully deterministic, a clear if-this-then-that, a straightforward automation or workflow rule is simpler, cheaper, and more predictable than an agent. Reaching for AI where a rule suffices is over-engineering with extra risk.
If it needs judgement and empathy, keep the human
A difficult conversation, a sensitive exception, a decision that affects someone's livelihood, these want a human. An agent handling the mechanical parts is fine; an agent replacing the human judgement in high-stakes, emotional moments is a mistake.
If the value isn't there, don't
Some processes are too rare or too low-value to justify building and governing an agent. Build effort and governance overhead have to earn their keep. 'We could' isn't 'we should'.
Real scenario: a client wanted an agent for a compliance check that was, on inspection, a simple deterministic rule, does this field match that field. We built a plain validation rule in an afternoon instead of a governed agent over weeks. Same outcome, a fraction of the cost and risk. Knowing when not to build is as valuable as knowing how. Simple wins.