Running agents in production

Launch is the start of the work

An agent that passes its evaluation set is ready for a pilot, not for a quiet life. Models change, documents change, users find new ways to phrase things, and a tool you depend on ships a new version. In production you need to see what the agent does, stop it when it misbehaves and fix it fast.

This lesson turns the earlier blocks into an operating model: a gateway in front, budgets and limits, observability on every step, and runbooks for the day something breaks. We do not cover team organisation. We cover the technical and procedural minimum we ask of every agent we hand over.

The operating picture

User or system
   -> Agent runtime (loop, bounds, approvals)
      -> Gateway (access, budgets, limits, policies, logging)
         -> Model endpoints (provider, open-weight, own)
      -> Tools through MCP (scoped identities)
      -> State stores (sessions, memory)
   -> Traces and logs -> scorers, dashboards, alerts -> a person on call

Each arrow is a place where something is recorded, limited or checked.

Run it as a service

On Databricks, the Agent Bricks documentation describes an Agent Server (with DurableAgentServer) that serves synchronous, streaming and background runs with crash recovery, and an Agent Runtime that deploys agents on Databricks-hosted compute. Agents can be queried through an invocation API, the Responses API or SQL. Whatever you deploy on, ask the same questions of the runtime:

• Crash recovery. If the process dies halfway through a task, does the task resume, restart or vanish? Long tasks need durable execution.
• Idempotency. A resumed run must not repeat a write. Tools take an idempotency key.
• Timeouts. Every task and every tool call has one.
• Versioning. You can say which prompt, model and tool versions produced any answer, and you can roll back one step.
• Environments. Dev, test, acceptance and production are separate, with their own identities and data. Deploy through a pipeline from reviewed code, never by hand. Prompts and tool configurations are code and go through the same pull requests.

The gateway

Put a gateway between agents and models. Unity Gateway provides, according to the documentation, permissions as Unity Catalog privileges, rate limits on model and MCP services, budgets with per-user thresholds and hard caps, service policies for guardrails, logging of requests and responses to Delta tables, usage tracking in system tables, and traffic splitting with failover.

For operations this gives you one place to answer: who used which model, how much, when and with what result. It is also the place where you stop something. A hard cap on a runaway agent is a setting, not an incident.

Observability: see every step

Log enough to reconstruct any run, and no more than privacy allows.

Run the same scorers you used before release on a sample of production traffic. MLflow supports running scorers on production traces. Every failure you find becomes a case in the evaluation set.

Mind personal data in logs. Redact before you store, set a retention period for traces, and restrict who can read them. Traces often hold the most sensitive text in the whole system.

Alerts that matter

An alert must lead to an action. Start with a short list:

• Cost per task or tokens per task above its limit for a defined window.
• Quality score on sampled traces below the release baseline.
• Escalation or override rate above normal.
• Tool error rate for a single tool above normal.
• Policy blocks that rise suddenly.
• Any hit on the hard caps.

Give each alert an owner and a runbook link. An alert nobody owns is noise.

Runbooks

A runbook is the written procedure for a known failure. Write them before launch, in short, direct sentences with one action per line, and test them in a drill. The standard set:

Add an owner, an escalation contact and a kill switch that a non-engineer can use. Test the kill switch on a schedule.

Change management

Every change goes through the same path: pull request, evaluation gate, cost gate, shadow run or traffic split, then full rollout. That includes model swaps (lesson 7), prompt edits and new tools. Keep a short change log per agent. When quality shifts, the log tells you where to look.

Review rhythm

• Weekly: read a sample of traces, the escalations and the blocked events with the agent owner.
• Monthly: review costs per task, the evaluation set coverage and the memory store.
• Quarterly: review access, as in our delivery standards, and remove permissions nobody uses.

Summary

Run an agent like any production service, with the extra care a probabilistic component asks for: a gateway for budgets and policy, traces and scorers for visibility, alerts with owners, runbooks you have rehearsed, a kill switch and one change path.

That completes the eight blocks. The final project asks you to put them together.