Where Agents Don't Belong (Yet)
Six task shapes where the agent architecture is the wrong fit regardless of model quality — each with a tell you can check in an afternoon, before committing a quarter to it.
Most writing about agents concerns making them work. The complementary skill — recognizing tasks where an agent is the wrong shape regardless of model quality — saves more time, and it's less discussed because it produces no demo.
These aren't predictions about permanent limits. They're properties of tasks that make the agent architecture a poor fit today, and each has a tell you can check before committing a quarter to it.
When the task is fully specified
If every input maps to exactly one correct output by rules you can write down, the agent's defining feature — deciding what to do next — has nothing to decide.
You get variable cost, variable latency, and non-zero error rate in exchange for flexibility the task doesn't need. Tell: you can describe the complete procedure to a new colleague in a paragraph, and they'd never need to ask a follow-up question.
Worth noting the honest exception: sometimes the rules exist but are locked in a legacy system nobody can modify. An agent as a bridge is legitimate there — but it's a workaround for an organizational constraint, not a fit for the task.
When the cost of a rare error exceeds the value of the common case
Agents don't have zero error rate, and errors don't announce themselves. For work where a wrong result is discovered late and costs more than all the correct results saved, the arithmetic fails even at high accuracy.
Tell: you can't think of a review step that would catch a wrong answer before it causes damage. If the only check is someone re-doing the work, automation has bought nothing.
This is why "agent proposes, human disposes" is so prevalent in high-stakes domains — it's not timidity, it's the only structure where the arithmetic works.
When there's no way to tell whether the output is right
Some tasks are objectively checkable — code compiles, schema validates, numbers reconcile. Others are only assessable by an expert, slowly.
Without a feasible verification step, quality is unmeasurable and drift is undetectable. Tell: you cannot describe how you'd evaluate a hundred outputs in an afternoon. If you can't build the eval, you can't operate the system — you can only hope.
When latency is the product
A tail of multi-second responses is disqualifying for autocomplete, live trading signals, or a real-time control loop. Agents are turn-based and each turn is a network round trip to a large model.
Tell: your requirement is stated in milliseconds. A small classifier, a cached lookup, or ordinary code is the answer — and a model can help build those without being in the request path.
When the environment offers no feedback
Agents work best where actions produce observable results the agent can react to. Where the effect of an action is invisible for weeks, the loop can't close.
Tell: the agent takes an action and nothing in its environment tells it whether it worked. Strategy and long-horizon planning frequently fall here — which is why agents assist those tasks well and execute them poorly.
When accountability must be personal
Some decisions require a named human who examined the facts, because that's what the regulation, the profession, or the relationship demands. An agent can prepare, summarize, and draft. It cannot be the accountable party, and structuring things so it's effectively making the call while a human signs is worse than either alternative.
Tell: if it went wrong, someone would have to explain their reasoning to a regulator, a court, or a person affected by it.
✅ The four questions
Before starting an agent project:
- Can I write the rules? → If yes, write the rules.
- Can I check the output cheaply? → If no, you can't operate it.
- What does a wrong answer cost, and would we catch it? → If expensive and uncaught, add a human or don't build it.
- Does the task actually branch on judgment? → If no, it's a workflow.
Four questions, most of an afternoon, and they'll redirect a meaningful fraction of proposals toward something simpler that works.
The takeaway
The interesting boundary isn't what agents can do — it's where the architecture fits. Fully-specified tasks want rules. Unverifiable outputs want a different approach entirely. Millisecond latency wants a small model or a lookup. Personal accountability wants a person, with an agent preparing the ground. Recognizing these early is worth more than any amount of prompt tuning afterwards, and it's the judgment that separates teams shipping useful agents from teams still explaining a pilot.