Agent failures trace to tooling and guardrails, not the model, two dev.to posts argue

Agents fail as systems before they fail as models

Two dev.to posts by Hossein Hezami, published minutes apart on the same day, make one argument from two directions: when an AI agent fails in production, the cause is usually the engineering around the model — tool contracts, permissions, budgets and recovery paths — not the model's intelligence.

The first post opens with a familiar incident. A CRM endpoint returned a 502, the agent retried the call, created two support tickets, read a stale knowledge-base article, filled its context window with stack traces, and then told the customer everything was fine. Teams respond to such incidents by upgrading the model, but the author's point is that the same failure tends to reappear, just written more fluently.

The framing is that an agent is a control loop: receive a task, observe state, decide what to do next, call a tool, validate the result, update state, and choose whether to continue, escalate or stop. The model handles only the decision step; the rest is conventional software engineering complicated by probabilistic planning, flaky tools, hostile external content and messy state. The post also notes that by 2026 models have improved considerably at tool calling and multi-step reasoning, which makes weak guardrails more dangerous, because the system looks competent for longer before it breaks.

The recurring weak points the author describes in production systems include vague objectives, weak tool schemas, excessive permissions, context rot, unbounded loops, non-idempotent tools, prompt-injection exposure, missing trajectory evaluation, observability that stops at the final answer, and designs that prioritize autonomy over recovery.

Contracts and schemas do the real work

The first post's prescriptions treat reliability as a property of the whole loop rather than the model. Agents need a task contract: an objective, success criteria that are machine-checkable where possible, forbidden actions, maximum steps, time and cost budgets, and a fallback behavior such as escalating to a human. The author's rule of thumb is that if you cannot write ten realistic examples of what a finished task looks like, the task is not ready for an agent.

Tool schemas, meanwhile, function as prompts for action. A generic tool accepting a free-text query invites vague calls and garbage results, so tools should be designed like strict internal APIs: typed inputs, narrow scopes, explicit constraints, and compact structured output instead of raw blobs. Permissions get similar treatment through least privilege, with tools classified as read-only, reversible writes or irreversible writes, and stricter handling as risk increases. Retrying non-idempotent tools is called out as a way to turn a flaky dependency into confident, duplicated side effects.

Deciding which layer stops a mistake

The second post starts from another production failure: a support agent refunded a customer's full annual subscription instead of a $12 add-on. The model did not crash, the API threw no exception, and the tool worked exactly as designed. Postmortems ask how to stop the model from making bad decisions; the author argues the better question is which layer should have stopped the mistake before it became damage.

The post separates agent mistakes into six failure modes — wrong intent, dangerous plans, invalid tool arguments, unauthorized actions, harmful outputs and runaway execution — and assigns each to a different defensive layer: intent classification, plan validation, tool contracts, authorization, execution controls, output validation, runtime monitors and human approval.

Two points stand out. Prompts are probabilistic steering, not enforcement mechanisms, so a safety case that rests on the model obeying a sentence in its instructions is not much of a safety case. And the core rule: the closer an action is to irreversible harm, the more deterministic the stopping layer must be, with the best brake being the earliest deterministic layer that can prevent the harm. The author singles out requests with global scope as the most dangerous case — if the agent cannot describe the affected set precisely, it should not be allowed to modify anything — and offers the example of a plan to list inactive users and then delete each one, where every individual call is valid but the sequence is not.

Why it matters

Both posts push back against the reflex of answering agent incidents with bigger models or longer prompts. For teams shipping agents, the practical program is unglamorous: define completion criteria, type the tools, scope permissions, cap loops with budgets and circuit breakers, evaluate full trajectories rather than final answers, and place deterministic gates — authorization, plan validation, human approval — in front of irreversible actions. As models improve, failures migrate from comprehension to execution, and the reliability work shifts to the plumbing around them.