Agentic Systems Aren't Apps With Extra Steps

Most teams ship their first agent the way they'd ship a feature flag: wrap a model in a loop, hand it a few tools, call it done. Then it fails in ways a normal endpoint never would — it retries a side-effecting call, it wanders past its own stop condition, it does three of five steps and quietly stops. None of that is a model problem. It's an architecture problem wearing an AI costume. An agent loop with tool calls behaves like a distributed system — partial failure, retries, non-idempotent actions — not like request/response. Treat it like the latter and the failure modes will find you in production.

The parts people skip

• State boundaries. What persists across turns versus what's thrown away after one — undefined, until a bug makes it very defined.
• Tool permission scoping. The same least-privilege problem as indirect prompt injection, but self-inflicted: an agent doesn't need write access to everything it can theoretically reach.
• Idempotency on side-effecting calls. The model will retry a step after a timeout. If "send the email" isn't safe to run twice, that's not the model's bug to catch. The standard fix — an idempotency key the caller generates per logical action — needs unique identifiers you can produce offline and in bulk; a UUID v4 generator makes them from your browser's crypto random, no server round trip.
• An explicit stop condition. Loops don't end gracefully on their own — something outside the loop has to decide "done" or "give up."

What actually helps

• Treat the tool layer as an API boundary, not a suggestion. Validate inputs and outputs the way you would for any external caller, because that's what the model is.
• Log the reasoning trace, not just the final action. You'll want it for the incident you haven't had yet, and you won't be able to reconstruct it after the fact.
• Design for partial completion as the common case. "It did three of five steps then failed" isn't an edge case worth a TODO — it's the shape most multi-step runs eventually take.

The interesting architecture question was never "can the model figure it out." It's "what happens when it's confidently wrong halfway through a multi-step action" — and that answer has to live in your system, not in the prompt.