DevOps for AI Agents: How to Ship and Run Agentic AI in Production
The short answer: treat everything that shapes an agent’s behaviour as code: the code itself, its prompts, the exact model version, its tools and permissions, and the knowledge it searches. Version them together as one bundle, push every change through an automatic quality gate, release to a small group first, and watch every request in production. If anything goes wrong, roll back the whole bundle in one step.
DevOps made ordinary software safe to change many times a day. AI agents need the same discipline, plus a few new habits, because they can change behaviour even when nobody touches the code. Some teams call this AgentOps or LLMOps; the ideas are the same.
What makes agents different to run
- Behaviour lives outside the code. A one-word prompt edit, a new model version or a refreshed document index can change answers as much as a code change.
- Vendors move under you. Model providers update and retire versions. If you always call “the latest” model, your agent can change overnight.
- Agents take actions. They call systems, send messages and update records, so a bad release can do damage, not just show a wrong screen.
- Cost is a live metric. Every request spends tokens. A bug that loops can burn a month’s budget in a day.
- Quality can’t be checked by a simple test. It needs the evals described in How to Test AI Agents.
Principle 1: one versioned release bundle
Package five things together, with one version number:
- Code: the agent logic and its tools.
- Prompts: stored in the repository, reviewed like code, never edited live in a console.
- Model version: pinned to an exact version, never “latest”.
- Tools and permissions: which systems the agent may call, and with which rights.
- Knowledge index version: the snapshot of documents it searches.
Now “what changed?” always has an answer, and rollback means one step back to the last good bundle.
Principle 2: a pipeline with an eval gate
Every change, of any of the five parts, runs the same path:
- Build and test: ordinary unit tests for tools and code.
- Eval gate: the golden set runs automatically. Quality, safety, cost per task and speed must all meet their targets.
- Security checks: scan for leaked secrets and risky packages, and run the prompt-injection tests.
- Staging: a full copy of the agent with sandboxed tools and masked data, so tests can’t touch real customers.
- Canary: the new bundle serves a small share of real traffic while you compare its metrics with the current version.
- Production: a gradual rollout behind a feature flag, with a kill switch ready.
The bundle on the left is what moves through the pipeline. The highlighted eval gate is the step ordinary DevOps doesn’t have. If production metrics drop, you redeploy the previous bundle, prompts and model version included.
Principle 3: control every request at runtime
Testing before release is not enough, because real users will always find new paths. Wrap the agent in layers that act on every request:
- Input checks: catch prompt-injection attempts, strip or mask personal data, and turn away off-topic requests.
- Model gateway: a single place that calls the model. It enforces the pinned version, fails over to a backup model if a provider is down, caches repeated requests, and applies spend caps per user or per task.
- Tool access layer: each agent gets its own identity and only the permissions its job needs (least privilege). Risky actions, such as payments or deletions, wait for a person to approve.
- Limits: a maximum number of steps and a time limit per task, so a confused agent can’t loop forever.
- Output checks: confirm the answer is backed by sources, follows policy, and doesn’t reveal data it shouldn’t.
The request travels left to right through checks on both sides of the agent. The agent reaches models only through the gateway and systems only through the tool layer. Every box reports to the telemetry band, so each answer can be traced step by step.
Principle 4: observe everything
For an agent, “the server is up” tells you almost nothing. Record a trace for every request: each step, model call, tool call, token count, cost and error. OpenTelemetry, the common open standard for this data, now covers AI calls, so traces can flow into the monitoring tools you already use. Then watch:
- task success rate and hand-offs to people
- cost and tokens per task, by agent and by customer
- speed per task, and tool error rates
- a daily sample of real conversations scored by your evals
Set alerts on sudden changes. A jump in cost per task or a drop in success rate is often the first sign of a model update, a broken tool or stale data.
Principle 5: plan for operations, not just launch
- Runbooks for common incidents: provider outage (switch to backup model), runaway costs (lower caps, pause the agent), bad answers (roll back the bundle).
- A refresh schedule for the knowledge index, treated as a release that runs through the eval gate.
- A model upgrade path: test new model versions in shadow before they replace the pinned one, well before the old one retires.
- Clear ownership: someone is on call for each production agent, just as for any other critical service.
Common mistakes
- Editing prompts directly in production.
- Calling “the latest” model instead of a pinned version.
- Giving an agent one powerful shared account for every system.
- Monitoring uptime but not quality or cost.
- No way to roll back prompts and model versions together with code.
How SHVX can help
Our Agent Operations team builds release pipelines, gateways and monitoring for agentic solutions, and runs them with you after go-live, from model upgrades to incident response.
Learn more about Agent Operations.
FAQ
What is AgentOps?
The practices and tools for releasing, monitoring and operating AI agents safely in production. It is DevOps extended to cover prompts, models, tools and data.
Do prompts really need version control?
Yes. A prompt change can alter behaviour as much as a code change, so it needs the same review, testing and rollback.
How do we roll back an AI agent?
Redeploy the previous release bundle, which restores code, prompts, model version, permissions and knowledge index together.
What should we monitor first?
Task success, cost per task, error rates and hand-offs to people, plus a daily scored sample of real conversations.