Most Agents Are Bullsh*t

Most agents are bullsh*t, but not because the models are useless. The pattern I keep seeing is more ordinary: a team decides it needs an agent before it has defined the job, then tries to make the system reliable by adding prompts, tools, and more agents.

An agent is useful when the path cannot be fully mapped in advance. The model has to inspect the situation, decide what to do next, act, and adjust to what happened. The influential ReAct paper helped establish this loop, whose value comes from letting the model change its next step based on the result of the last one.

Imagine a customer asks for a refund. A model reads the request, retrieves the order and policy, then drafts a reply. That may look like an agent in a demo, but the job might only require one well-designed model call.

If a model can do the work in one pass, call it once. If the path is known, write a workflow. Use an agent when the next step genuinely depends on what the system learns along the way.

1. They start with the agent, not the job

“Let’s build an agent” sounds like a plan, but it starts at the wrong end. Before anyone picks a model or framework, the team should be able to say what job needs doing, what a better outcome looks like, and why an agent is the simplest way to get there.

For the refund assistant, a single structured call may be faster, cheaper, and easier to evaluate than an agent loop. The loop is justified only if the system must take several steps and change course based on what it finds.

AI Agents That Matter, published in TMLR in 2025, found that agent benchmarks often rewarded accuracy without giving enough weight to cost, reliability, holdouts, or reproducibility. Anthropic's engineering guidance offers similar advice: start with the simplest approach that works and add complexity only when it produces a measurable gain.

Define the trigger, owner, outcome, system of record, permitted actions, and unacceptable failures first. Those decisions tell you whether the job needs one model call, a fixed workflow, or an agent.

2. They leave business rules to the model

Suppose refunds above $250 require human approval. The model should not decide whether to respect that limit on each run. Code should enforce it.

The model can interpret the customer’s evidence, decide whether it supports an exception, and explain its reasoning. It should not be able to grant itself the authority to issue the refund. Putting the whole policy in a prompt is quick, but it also gives the model room to reinterpret rules the business meant to enforce.

Models are useful for ambiguity. Software should handle what must happen every time: permissions, validations, approval thresholds, and state transitions. Infrastructure for AI Agents, published in TMLR in 2025, describes why infrastructure outside the agent must control how it interacts with the environment and limit the consequences of its actions.

3. They overload one agent, or add more too soon

Teams make this mistake in both directions. Some put triage, research, policy interpretation, payment operations, customer communication, and review into one agent with too many tools and too much context. Others divide the same job among several agents before proving that one can do it.

One approach overloads the model; the other adds handoffs, duplicated context, and coordination failures. MAST, a NeurIPS 2025 Datasets and Benchmarks paper, examined more than 1,600 traces from seven multi-agent frameworks and found 14 recurring failure modes involving system design, alignment between agents, and task verification.

Two controlled 2026 preprints reached a similar conclusion. OneFlow found that one agent could match homogeneous multi-agent workflows across seven benchmarks. An equal-budget comparison found that single agents matched or beat multi-agent systems on multi-hop reasoning once reasoning tokens were held constant. Neither study argues against subagents in general. Both matter because multi-agent systems often spend more tokens, and a fair comparison has to account for that cost.

Subagents make sense when parts of the work need different context or tools, can be checked independently, or benefit from running in parallel. Anthropic reported a 90.2% improvement on an internal research eval for its multi-agent research system, alongside roughly 15 times the token usage of ordinary chat. That is a reasonable tradeoff for some research tasks and a poor one for many routine workflows. Test the simpler system first, then split the work if the results justify the added coordination.

4. They treat tools and context as an afterthought

The agent only knows what its instructions, retrieved context, and tools make available. Give the refund agent two similarly named tools, an obsolete policy beside the current one, and an order lookup that omits pending chargebacks, and it can follow the information correctly while still reaching the wrong result.

AgentBench, an influential ICLR 2024 benchmark spanning eight environments, identified long-term reasoning, decision-making, and instruction following as major obstacles. The later τ-bench moved evaluation closer to production by checking final database state and policy compliance across repeated runs, rather than grading only the conversation.

Its ICML 2026 successor, τ-Knowledge, asked agents to navigate roughly 700 connected banking-policy documents while making verifiable account changes. Even frontier models given extra reasoning time achieved only about 25.5% single-run success in that environment. More context did not make the information easy to navigate or the actions easy to complete.

Tool names, schemas, error messages, returned state, permissions, and knowledge organization all affect performance. They need the same product attention as the model’s instructions.

5. They have demos, not evals

A clean demo shows that the agent can succeed when the inputs are familiar and every dependency works. An eval suite should also test what happens when information is missing, a tool fails, or an action only partially completes.

Suppose the payment processor completes a refund but returns a misleading timeout. Does the agent verify the state before retrying? Does it stay within its authority? Does it tell the customer what actually happened? Does it escalate with enough context for a human to recover?

Good evals grade those decisions, actions, and outcomes, not just whether the response sounds helpful. They check final state, policy compliance, repeated reliability, and failures that carry real cost. τ-bench's pass-to-the-k metric measures whether an agent can repeat a success, while a 2026 ACL survey of agent evaluation identifies cost, safety, and robustness as continuing gaps.

An ICLR 2026 workshop study covering 20 case studies and 306 practitioners found that 68% of production agents ran no more than ten steps before human intervention, while 74% still depended primarily on human evaluation. Reliability was the most frequently reported challenge.

If a team cannot say what would make the agent fail an eval, it does not yet know what the agent is supposed to do.

6. They review failures without learning from them

After a bad run, someone reads the trace, edits the prompt, and moves on. The failing case never enters the eval suite, so the same behavior can return later and no one can tell whether the change actually helped.

NVIDIA describes a more disciplined process in a 2026 EACL industry paper about an internal assistant serving more than 30,000 employees. Over three months, the team used 495 negative examples to improve routing and query rephrasing. Its new router reached 96% accuracy using a model ten times smaller and with 70% lower latency (industry paper). Those are company-reported results from one deployment, but the process is useful: the team turned specific failures into targeted engineering work.

Agent-Ops, published in the ACL 2026 Industry Track, reported 85% to 97% end-to-end accuracy across deployed e-commerce workflows. Reaching that level required clearer SOPs, more robust web automation, and independent document verification.

A production failure should leave something useful behind: a diagnosed cause, a regression case, a scoped change, and evidence from later runs that the problem was fixed.

The agent readiness checklist

Before approving another agent pilot, ask eight questions:

1. Why is this an agent? Explain why one model call or a fixed workflow is not enough.
2. What exact job does it own? Name the outcome, owner, system of record, authority, and unacceptable failures.
3. What belongs in code? Keep rules, permissions, validations, approvals, and state transitions deterministic.
4. Can it finish the real job? Test the actual duration and messiness of the work. The system should preserve state, resume after an interruption, and know when to stop, retry, or ask for help.
5. Can it use the right tools safely? Test tool selection, permissions, failures, and whether the intended action actually happened. If the catalog is large or changes often, expose tools only when they become relevant.
6. Is the work split at the right boundaries? Give each agent a coherent task, the context and tools it needs, and a clear handoff. Add a subagent only when it improves the result, latency, or cost.
7. What do the evals grade? Test decisions, actions, final state, repeated reliability, recovery, cost, and latency under realistic conditions.
8. Does production improve the next version? Turn important failures into diagnosed causes, regression cases, scoped fixes, and evidence from future runs.

If one model call can do the job, use it. If the work truly needs an agent, the surrounding rules, tools, permissions, evals, recovery paths, and feedback loop are part of the product. That is what makes the system dependable enough to use in a real business.