Most agents disappoint because of where they were placed, not what they could do. Put one in the wrong spot and even a capable agent looks useless.
Executive Summary
When an agent underwhelms, the instinct is to blame the agent. Usually the problem is placement. It was bolted onto a workflow rather than built into one. It was asked to do a part of the job that never needed it, or dropped at a point where it could not see what it needed to act.
Knowing where an agent belongs is most of the work. The capability is the easy part.
The bolt-on problem
A common pattern: a team has a workflow that works, decides to add AI, and looks for somewhere to slot an agent in. The agent gets attached at whatever point seems convenient.
But a workflow designed without the agent rarely has a natural place for one. So the agent sits awkwardly, doing a task that does not quite fit. It produces output that someone then has to reshape to match the steps on either side. It adds work because it was added, rather than designed in.
Find the judgement, not the task
The right place for an agent is wherever the workflow needs judgement on something that varies. Not the repetitive steps, automation handles those better, but the moments where a person currently has to look, assess, and decide.
Map a workflow and those moments stand out. The point where someone reads an incoming request and decides how to handle it. The point where an exception needs interpreting. Those decision points are where an agent earns its place, because that is where judgement is actually being applied.
Give it what it needs to see
An agent placed at the right decision point still fails if it cannot see what a human would see to make that decision.
A person deciding how to route a request draws on history, context, and related records, often without noticing. An agent has only what you give it. Place it at a real decision point but starve it of context, and it makes worse calls than the person it replaced. Placement and access go together; neither works alone.
Design the handoffs
An agent rarely does a whole job. It does a part, then hands to the next step, which might be a person or an automation. Those handoffs decide whether the whole thing flows.
What does the agent pass on, and in what form. What happens when it is unsure. Who picks up the cases it escalates. A well-placed agent with badly designed handoffs still produces friction, just further down the line. The workflow has to be designed as a whole, with the agent as one part of it.
Start from the workflow, not the agent
The reliable way to place an agent well is to start with the workflow. Ask where judgement is being applied, what context that judgement draws on, and how decisions hand off to the next step.
Answer those, and the right place for an agent becomes obvious, along with what it needs to work. Start instead with "where can we put an agent," and you get a bolt-on that disappoints. The order you ask the questions in decides the result.
A capable agent in the wrong place is still useless. The work is not finding an agent. It is understanding your workflow well enough to know where one belongs.