AgentOps

What is AgentOps?

AgentOps is the way of working that keeps AI agents running in production and keeps them doing the right thing. It is also a product name, an agent platform at agentops.ai with an open source SDK, so you will meet the word as a vendor too. This entry is about the practice.

What makes it separate from running an ordinary service is the unit you operate. With a web service you operate a request, and when it fails it throws. With an agent you operate a run, and a run behaves differently in four ways.

• It is a chain of steps, not one call. One job can be a dozen model calls and tool calls, and only the twelfth went wrong.

• The same input does not give the same path. Two runs of one question can pick different tools in a different order and both be right.

• The failure is usually a wrong action, not an error. The agent mailed the wrong contact, or answered from memory instead of checking the price list.

• Cost varies per run, not per deployment. An agent that decides to try again five times costs five times as much for the same job.

Out of that come four things you have to be able to do: see what a run actually did, say whether the outcome was right, know what it cost and who incurred it, and change the prompt, the tools or the model without breaking what already worked. Skip that last one and the other three become a museum. You watch what went wrong in high resolution, with no safe way to act on it.

What a trace has to contain to be useful in an incident

A trace is the recording of one run. The test of it is not how it looks on a dashboard, it is whether somebody can answer a customer complaint from it three weeks later. Six things have to be on it, under one identifier so they come up together.

• The input as it arrived, including the part that came from a document or a mailbox rather than a person.

• Every tool call with its arguments and its result. Knowing the agent called the invoice tool tells you nothing. Knowing it called that tool with the wrong supplier number tells you everything.

• The decision points: which model turn chose that tool, and what it had in front of it.

• The identity that acted, and on whose behalf.

• The token counts and the cost of the run.

• The outcome, including whether the run finished or hit a limit.

The tooling already thinks this way. In the OpenAI Agents SDK a trace has a workflow_name, a trace_id and an optional group_id that links several traces from one conversation, and the work inside is recorded as spans for the agent run, each model call, each tool call and each guardrail. Those spans hold the real inputs and outputs, which in a business agent means customer data, so decide what you keep and for how long while you are still building.

Evaluation once the thing is live

A fixed test set you run before deploying is necessary and it is not enough. It holds the cases you thought of. Production holds the ones you did not, and the mix shifts as customers change what they ask.

So two things sit next to it. The first is a way to sample real runs and judge them. Microsoft calls this continuous evaluation, quality and safety scoring of production traffic at a sampled rate, and LangSmith does the same with a sampling rate between 0 and 1 on filtered traces. Sampling is the design, not a compromise: judging every run means paying for a second model call on every run. Ten percent of runs, genuinely at random, beats every run that happened to be cheap to catch. The second is a scheduled run of your fixed set against production, which catches a regression before the live traffic has made it obvious.

What you score also changes. Microsoft Foundry splits it in two, and the split is worth stealing even if you never touch Azure. System evaluation looks at the end of the run: did it complete the task, work out what the person wanted, and stay inside its rules. Process evaluation looks at the steps: did it pick the right tools, call them with the right parameters, and use what came back. An agent can pass every system check while its process quietly rots, and the process is where the rot shows first.

A prompt change is a deploy

Editing a system prompt feels like editing a document. It is a production change with the reach of a code deploy, and it needs three things around it.

A version. Every prompt, tool description and model choice gets one, recorded together. In LangSmith each saved update becomes a commit with its own hash, and a tag can be moved to point at a different commit, so you change which version production runs without touching your code. In Foundry an agent version is immutable once saved and you address it as agent_name:version.

A staged rollout. Send part of the traffic to the new version first. Foundry does this by letting you point requests at a specific agent version. On a small system, staged can mean one team uses it for a week.

A rollback path somebody has used once. Not the theory that the old prompt is somewhere in Git. The old version live again inside ten minutes, done by somebody who is not the person who wrote it.

An agent that gets quietly worse after a model update

A quoting agent reads an incoming email, looks up prices with a tool, and drafts a reply for a salesperson to send. After four months the model deployment behind it moves to a new default version, either because somebody upgraded it or because the deployment was set to follow the default on its own.

Nothing breaks. Every run returns, latency is unchanged, no alert fires. But the newer model is more willing to answer from what it already read in the thread, so on ambiguous requests it skips the price lookup and writes a plausible number instead. Say your sampled runs go from nineteen in twenty calling the price tool to thirteen in twenty. Seven quotes in twenty are now written without a lookup, and nobody finds out until a customer holds you to a price that was never in the system.

Process evaluation on sampled runs sees the tool call rate drop within a day, while the answers still read fine. The scheduled run of the fixed test set fails on every case that needs a lookup, on the morning after the switch. The model version on each trace lines the drop up with the change, which turns a week of arguing into a five minute query. And the rollback path gets you back: Azure notifies customers at least two weeks before a new version becomes the default and keeps the previous major version until its retirement date, so there is something to pin to while you fix the prompt.

AgentOps versus MLOps

The two get treated as one job with a newer noun. They differ on what you are monitoring for.

MLOps watches the inputs and the score. The model is yours, trained on data you hold, and it degrades as the world moves away from that data. So you monitor distributions: is the input drifting, is accuracy on labelled outcomes falling, is it time to retrain. Model drift is what you hunt and retraining is the lever you pull.

AgentOps watches behaviour and actions. The model belongs to somebody else and you cannot retrain it. What changes is the path a run takes, which tools it reaches for, whether it stayed inside its instructions, and what that cost. Degradation arrives from outside, and your levers are the prompt, the tool set, the model version and the permissions.

Put plainly: MLOps asks whether the predictions are still accurate, AgentOps asks whether the actions are still correct.

Who is on call for an agent

Somebody has to be named. Not the team, a person, with a deputy. An agent with no owner is an agent nobody switches off, because switching it off is a decision and a decision needs a name on it.

Define what down means before you need the definition. For an agent the interesting state is that it answers and answers badly, so write the threshold down: below this score on sampled runs, or above this many escalations a day, the agent counts as down and gets paused. Microsoft's dashboard guidance has the same shape, treating a run success rate under ninety five percent as something to investigate rather than as background. Loud failures get fixed within the hour because somebody is shouting. The expensive ones ran for six weeks looking healthy, which is why the sampling exists at all.

If you run a smaller company, park the platform question. You do not need an AgentOps product to have AgentOps. You need a run history that somebody actually reads once a week, a way to stop the agent that works when the person who built it is on holiday, and a named owner. We have seen far more damage from an agent nobody was watching than from an agent with a plain toolchain.