How to Deploy AI Agents in Production Safely

A prototype agent that works in a notebook and a production agent are different systems. The model is the same. Everything around it changes.

When teams ask me how to deploy AI agents in production, they usually expect an answer about models. The answer is almost entirely about the code around the model.

What does it take to deploy AI agents in production safely?

Safe means four things: the agent cannot take an action you have not explicitly allowed, cannot take it twice by accident, cannot spend past a budget you set, and can be stopped in under a minute. Everything else is implementation detail.

Almost every agent incident I have debugged was not a model failure. The model picked a plausible tool with plausible arguments and the surrounding system had no opinion about what happened next. A retry loop that fired the same webhook dozens of times. A support agent that messaged the same customer on two channels. A scraper agent that walked past its rate limit and got the account blocked.

So the work is mostly unglamorous infrastructure. If you are still deciding how much independence to grant, read how much autonomy is actually safe first. This post assumes you have something that works and now needs to survive real users.

Design for blast radius before you design for capability

Rank every tool the agent can call by what happens if it fires at the wrong moment, then set controls to match. Blast radius decides how much scaffolding you need, not benchmark scores.

Most teams start at the bottom row because it demos well. Start at the top row instead and earn your way down. Building AgentFlow, a visual builder where non-engineers chain input sources, AI processors and output actions on a canvas, is what convinced me this tiering belongs in the tool rather than in a document. When the person assembling the flow is not an engineer, the interface has to make blast radius visible at the point the node is dropped, not in a review later.

How do you sandbox agent tools?

You never expose a raw capability to the model. You expose a narrow typed function, validate its arguments against a schema before execution, run it under a service account with least privilege, and execute anything code-shaped inside a disposable container with network egress denied by default.

The dispatcher pattern

Anthropic's tool use documentation describes client tools as functions the model requests and your own application executes: the response carries a tool_use block, and your code decides whether to honour it. That gap between deciding and executing is where every safety control lives. Do not close it by auto-dispatching whatever comes back.

ALLOWED_TOOLS = {"search_kb", "create_note", "send_whatsapp"}

def dispatch(tool_name, raw_args, ctx):
    if tool_name not in ALLOWED_TOOLS:
        return deny("tool not in allowlist")

    args = TOOL_SCHEMAS[tool_name].model_validate(raw_args)  # reject, never coerce

    if ctx.spend_usd >= ctx.tenant_cap_usd:
        return deny("tenant spend cap reached")
    if ctx.step >= ctx.max_steps:
        return deny("step budget exhausted")

    key = idempotency_key(ctx.run_id, tool_name, args)
    prior = results.get(key)
    if prior:
        return prior  # replay the stored result, do not re-execute

    result = TOOLS[tool_name](args, timeout=20, actor=ctx.service_account)
    results.put(key, result, ttl=86400)
    audit.emit(ctx.run_id, ctx.tenant_id, tool_name, redact(args), result.status)
    return result

"The model is not your security boundary. Your dispatcher is."

Why every write action needs an idempotency key

Agents retry, networks drop, and planners re-plan. Without idempotency you will eventually send the same message, create the same record or charge the same card twice. This is the single highest-value control per hour of engineering effort.

Derive the key deterministically from the run id, the tool name and a canonical hash of the validated arguments. Store it with a unique constraint in Postgres or Supabase and replay the stored response on collision. Stripe's API documentation describes the same pattern: the first response for a given Idempotency-Key is saved and returned for later requests with that key, and keys are retained for at least 24 hours.

One caveat from a multi-tenant WhatsApp build: idempotency at your layer does not protect you from duplicates created upstream. If a webhook can be delivered more than once, deduplicate on the provider's message id as well as your own key.

Pair idempotency with disciplined error handling. When a tool call fails, return a structured error to the model rather than an exception trace, and decide per tool whether a retry is safe. A timeout on a read is safe to retry immediately. A timeout on a send is not, because you do not know whether the send happened. For that case, resolve the ambiguity by reading state back before retrying, and let the idempotency store break the tie if you cannot.

How do you stop an AI agent from burning your budget?

Meter tokens and tool calls per run, per tenant and per day, then hard-fail the run when it crosses a limit. Cost scales as tokens per call multiplied by calls per run multiplied by runs per day, and agents quietly inflate the middle term when a task goes sideways.

Model pricing is structured per million input and output tokens, with cached input priced lower and server-side tools such as web search often billed per use on top. Those numbers move, so read the current OpenAI and Anthropic Claude pricing pages rather than trusting a figure in a blog post, including this one. What does not move is the shape of the cost curve.

Kill switches and staged rollout

A kill switch is a flag your dispatcher checks before every tool call, readable from a store that does not require a deploy to change. If turning your agent off needs a pull request, you do not have a kill switch.

Shadow mode is the step teams skip and the one that pays for itself. It gives you a labelled dataset of agreement and disagreement against human behaviour, which is the only honest accuracy measure you will get before launch. I go deeper on that in nine lessons from shipping agents in production.

The teams that deploy AI agents in production without a bad week are the ones who treat rollout as a sequence rather than a launch date. Nothing in that list is clever. It is just refusing to skip steps when the demo went well.

What should you log, and how do you handle PII?

Log every tool call as a structured event: run id, tenant id, tool name, redacted arguments, result status, latency, token cost, and which policy authorised it. Redact personal data at the boundary before it reaches your log store, not in a cleanup job afterwards.

You need this for three separate reasons: debugging a bad run, proving to a customer what the agent did on their account, and answering a security review. The third one is what closes enterprise deals. When I built Synthicare, an NHS-compliant clinical decision support platform, the role-based access control and the data isolation design took more review cycles than the model work did.

The pre-launch checklist

Before you deploy AI agents in production to real users, every line below should be true. If one is not, you are not launching a feature, you are running an experiment on your customers.

Is a custom agent worth it versus an off-the-shelf tool?

If your workflow is generic and your data is not sensitive, buy the tool. Build when the workflow is specific to your business, the actions touch systems of record, or your compliance posture requires controls the vendor will not give you. I break the trade-off down in more detail on custom AI builds versus SaaS agent tools.

The honest cost comparison is not licence fee versus build cost. It is licence fee versus build cost plus the safety harness described above, because the harness is what makes the agent deployable at all. That harness is roughly the same size whether the agent does one job or ten, which is why per-agent economics improve fast once the first one ships. This is most of what my AI engineering work actually consists of, particularly for SaaS teams putting agents in front of their own customers.