Production-Ready AI Agents: Four Things That Actually Prevent Disasters - By Sourav Mishra (@souravvmishra)

Every postmortem I've seen follows the same script: no step limit, overprivileged tools, no human check on destructive actions, or one agent's output piped straight into the next with zero validation. Fix those four and you're most of the way there. In this guide I, Sourav Mishra, walk through each one with concrete patterns and where to implement them—so your agents don't blow up in production.

1. Cap the Loop

Agents that can call tools "until done" need a hard stop. Without it you get "and then it called the API 10,000 times" or an infinite loop that burns budget and locks up your system. In the Vercel AI SDK that's stopWhen: stepCountIs(N). I use 10 as a default for open-ended tasks; for narrower tasks (e.g. "answer this question using search") I might use 5. Tune from there based on your use case and cost.

Why it matters: real incidents (e.g. in my AI agent security fact-check) include runaway tool use and cascading failures. A step limit is the first line of defense. It doesn't replace good prompts or tool design—it ensures that even when the agent goes off the rails, the damage is bounded.

Implementation: in the Vercel AI SDK you pass stopWhen into the agent loop so the run terminates after N steps. The full pattern—tools, loop, streaming, and stop condition—is in building an agentic chatbot. If you're using LangGraph, CrewAI, or another framework, look for an equivalent max-steps or max-iterations option and set it. Never ship an agent without a step cap.

2. Least Privilege per Tool

No shared admin creds. No "run anything" endpoints. If the agent only needs read from a database, give it read-only. If it only needs to call one API with a narrow scope, give it a token with that scope only. EchoLeak, Kiro, Uncrew—every security roundup I track points at overprivileged access. Multi-agent is worse: one bad agent can abuse the whole chain. I wrote about multi-agent security and why handoffs must be verified.

In practice that means: one set of credentials per agent (or per role), scoped to the minimum needed. No .env with a single super-user shared across all agents. If an agent is compromised or manipulated, the blast radius is limited to what that agent can do. Audit your tool definitions and ask: "If this agent went rogue, what's the worst it could do?" Then remove or narrow any permission that isn't strictly necessary.

For read-only tools (e.g. search, fetch doc), use read-only clients or API keys with read scope. For write operations, prefer narrow actions (e.g. "create draft" not "publish anything") and human-in-the-loop for the irreversible part. I tie that to the next point.

3. Human-in-the-Loop for Irreversible Actions

Anthropic's data on Claude Code usage shows that most production tool use still has human oversight, and only a tiny fraction of actions are irreversible. Design for that. For delete, pay, publish, or any action that can't be undone—require confirmation or at least review. "Agent proposes, human confirms" is the right default. I summarized the research in Anthropic's autonomy study.

That doesn't mean every tool call needs a human. Read-only and low-impact tools (search, read file, compute) can run autonomously. The ones that change state in a way that's hard or impossible to roll back are where you add a confirmation step, a review queue, or an explicit "approve" action in your UI. Log those actions so you can audit who (or what agent) did what.

Implementation options: return a "pending approval" result from the agent and show it in the UI; use a separate "destructive actions" tool that queues the action and requires a human to confirm; or run destructive operations only after the user clicks "Confirm" on a summary of what the agent wants to do. Pick one and apply it consistently.

4. Verify Between Agents

If Agent A's output goes straight to Agent B as input, you have a cascade risk. One compromised or manipulated agent can feed bad data or malicious instructions to the next. Research in 2026 showed systems like CrewAI could be pushed into data exfiltration in a large share of tests when one agent was compromised. So add schema checks, allowlists for tool calls or handoff payloads, or a gatekeeper that validates handoffs before the next agent runs.

In practice: don't pass raw text from A to B. Validate structure (e.g. JSON schema) and content (e.g. allowlist of allowed actions or topics). Reject out-of-scope payloads and log them. Give each agent the least privilege it needs and don't let Agent B run with privileges that were intended for Agent A. Details and patterns are in multi-agent security.

If you don't need multiple agents, don't use them. A single agent with good tools is easier to secure and reason about. Add a second (or third) agent only when the task genuinely benefits from separate roles or models—and then add verification at every handoff.

Do These Four, Then Optimize

Step limit, least-privilege tools, human-in-the-loop for destructive actions, and verification between agents—get those in place first. Then you can optimize for speed, cost, or fancier behavior. Skipping any of the four is how production incidents happen. I keep a fact-check of 2026 incidents and a full agent implementation guide updated so you have concrete references when you ship.

Key Takeaways

• Cap the loop: stopWhen: stepCountIs(N) or equivalent. No unbounded agent runs.
• Least privilege per tool: No shared admin creds; scope every tool to the minimum needed. One compromised agent = limited blast radius.
• Human-in-the-loop for irreversible actions: Delete, pay, publish—require confirmation or review. Agent proposes; human confirms.
• Verify between agents: Schema checks, allowlists, or gatekeepers at handoffs. Don't pass raw output from A to B without validation.
• Do these four before optimizing. Full pattern: building an agentic chatbot.

---

Written by Sourav Mishra. Full Stack Engineer, Next.js and AI.

Frequently Asked Questions

Q: What's the first thing to add for production? A hard step limit (stopWhen: stepCountIs(10) or similar) and least-privilege tool access. Then human-in-the-loop for destructive actions and verification between agents if you have more than one.

Q: Do I need human-in-the-loop for every tool call? No. Use it for irreversible or high-impact actions (delete, pay, publish). Read-only and low-impact tools can run autonomously.

Q: Where's a full agent implementation? Building an agentic chatbot with the Vercel AI SDK—tools, stopWhen, streaming, and structure you can copy.

Q: What if I only have one agent? You still need the step limit and least privilege. Human-in-the-loop applies to any destructive tool. Verification between agents only applies when you have multiple agents passing output to each other.