Agent workflows that fail safely

An agent is not a smarter chatbot. It is a loop that plans, calls tools, observes, and plans again. That loop is useful only if you bound it: which tools exist, how long it may run, what it may write, and who approves irreversible steps.

Give the agent a small, typed tool surface. “Search, read ticket, draft reply, post reply” is a workflow. “Browse the internet and do whatever the user meant” is a liability. Each tool should declare side effects — read vs write — and write tools should be idempotent or gated.

Timeouts and step budgets matter more than a clever planner. Cap iterations. Cap tokens. Cap parallel tool calls. When the budget is gone, stop with a partial result and a trace, not another speculative hop. Infinite retries are how you burn money and corrupt state.

Put human gates on anything that emails a customer, moves money, or changes production config. The agent can prepare the action and explain why. A person clicks. That pattern is slower in the demo and much faster in week three, when you are not reversing silent mistakes.

Log the plan, the tool args, the tool results, and the final action as one trace id. Without that, you cannot debug, you cannot eval, and you cannot tell a customer what happened. Traces are the unit of quality for agents the same way logs are the unit of quality for services.

Start with a supervised workflow, not an open-ended persona. The teams that get value from agents in production almost always wrap a job that already exists — triage, enrichment, reconciliation — and only then let the loop run longer. Autonomy is earned by a shrinking exception rate, not granted on day one.