[framework]

Running AI agents in production

What changes when an agent leaves the notebook: evaluation, observability, guardrails, and ownership.

7 min read · 2026-09-14

Agents are different

A predictive model returns a number. An agent takes actions, calls tools, and makes a sequence of decisions that can vary with every run. That variability is what makes agents useful and what makes them hard to operate. Traditional MLOps was not designed for it.

Evaluation sets are the contract

Every agent needs a golden dataset of tasks with expected outcomes, run on every change. Without it, no one can say whether a prompt edit, a model upgrade, or a tool change made things better or worse.

Observe cost and outcome, not just uptime

Trace each run end to end. Record cost per task, latency, tool calls, and whether the task was completed correctly. Aggregate by task type so regressions are visible before they reach users.

Guardrails and approval gates

Define which actions an agent may take alone and which need a human. Put hard limits on spend and on the blast radius of any single run. Make rollback a one-step operation.

Ownership

An agent in production needs a product owner who decides what it should do, an engineering owner who keeps it running, and a risk owner who signs off changes. Runbooks belong to the operations team, not to the vendor who built the first version.

The framework

Our AI Agent Ops Framework packages these into templates, tooling, and a release process that teams adopt in weeks. It is the reason agents we build pass assurance review and keep running after we leave.

Ready to move from pilots to P&L?

Tell us about the decision or workflow you want to change. We'll come back with an honest view on whether it's worth proving, and what it would take.

Start a conversation