When an agent beats a workflow — and when it does not

There is a simple test for whether a task needs an agent: can you draw the flowchart in advance?

If you can draw it, build the pipeline

Classify a ticket, extract five fields, look the customer up, write a reply. The steps never change. A fixed pipeline runs it in a fraction of the time, costs a fraction of the tokens, and fails in ways you can read from a log.

If the next step depends on the last one, use an agent

"Find out why revenue in the Vietnam region dropped last quarter" cannot be drawn in advance. The second query depends on what the first one returned. That branching is exactly what an agent loop is for.

Give the agent a budget

An open-ended loop with no ceiling is how a research task quietly becomes an expensive one. Cap the number of steps, cap the tool calls, and stream progress so a human can stop it. In practice the cap is almost never hit — but knowing it exists is what makes the feature shippable.

Keep the tools small and boring

An agent that can call twelve well-named, single-purpose tools outperforms one with three tools that each take a configuration object. Ambiguity in a tool signature turns into retries, and retries turn into latency.