AgentOps Part 1: Why AI Agents Need Their Own Operating Model

Key takeaways:

• Agents that stall after the pilot are let down by the operating model around them, not by the model itself.
  
• Agents break the Machine Learning Operations (MLOps) and Large Language Model Operations (LLMOps) playbook in three ways: Costs multiply, the unit of change is six parts rather than code, and quality drifts without a deployment; KPI Partners versions all six parts as one agent release and runs a release clock and a drift clock to keep each in check.
  
• Controls belong in the platform, not in the prompt: A prompt rule is guidance that a determined user can talk a model out of, while a catalog grant is enforced every time, and that one principle shapes every layer and plane of a production-grade AgentOps architecture.
  

The Demo Is the Easy Part; Production Is the Exam

Most enterprise agent demos work flawlessly, and that is precisely the challenge. A demo answers five rehearsed questions in front of a friendly room. Production has to answer fifty thousand unrehearsed ones while controlling cost, recording every consequential action and giving auditors a defensible explanation. The real exam begins when the agent meets live users, changing data and the core systems the business runs on.

A widely quoted 2025 Massachusetts Institute of Technology (MIT) study suggested that roughly 95% of enterprise Artificial Intelligence (AI) pilots fail to show a measurable return, and Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027, citing costs, unclear value and weak risk controls. Across the agent programs KPI Partners has supported, the model is seldom the limiting factor. The gap is usually the operating model around it: No release gate to stop a bad change, no ceiling on what a runaway loop could spend, and no record that could explain why the agent answered the way it did.

KPI Partners' work on routing each question to the right model consistently leads clients to a broader question: How do you run agents with the same discipline you already apply to payments, data pipelines and every other system the business cannot afford to lose?

That discipline is AgentOps, and this three-part series gives technical decision-makers a practical way to assess whether an agent is ready for production. Part 1 covers the operating-model failures to look for, the five-layer architecture that serves each request, and the three cross-cutting planes that control release, observability and governance. Part 2 examines model routing and release gates, while Part 3 covers operating, governing and scaling agents after go-live.

Treat AgentOps as Its Own Discipline, Not an MLOps Add-On

AgentOps is the practice of building, versioning, evaluating, releasing, observing and improving AI systems that plan and act on their own. It borrows heavily from MLOps and LLMOps, but it exists separately because agents do something no predictive model or chatbot ever did: They choose their own path through tools, data and other agents, and then act on what they find.

Expect Three Properties of Agents to Break the Old Playbook

Three properties of agents break the existing playbook, and each one shaped a part of the architecture that follows.

Costs Multiply Rather Than Add

The orchestrator plans the work, each sub-agent takes its turn, tools retry when they fail, and synthesis and guardrail checks run before anyone sees an answer. One request can easily become six or more billed calls. Without span-level cost attribution, a platform owner cannot see which step, tool or model drove the spend, or set the right routing rule, alert or hard cap. In effect, every request produces an invoice with no line items and no obvious lever for reducing it.

The Unit of Change Is No Longer the Code

An agent's behavior comes from six moving parts: Its instructions, tools, models, routing policy, knowledge sources and the test set used to judge it. These change on different schedules and often belong to different teams, so we version all six together as one agent release. A prompt change and a retrieval change can each pass their own tests and still fail together in production.

Agents Regress Without a Deployment

A traditional application stays the same until someone ships a change. An agent can degrade with no release at all, because a provider updated a hosted model, a source table changed shape, or a downstream Application Programming Interface (API) started returning a new error. We therefore run two clocks: A release clock that tests each change before it ships, and a drift clock that re-runs the same tests on a schedule against the version already live.

All three point the same way: The operating model deserves as much design attention as the agent, and it is far more economical to build before go-live than after an unexpected invoice reaches the Chief Financial Officer (CFO).

Design Five Layers and Three Planes That Work on Any Platform

The KPI Partners reference architecture has five layers that serve each request and three planes that run across all of them. The layers describe how an agent produces an answer; The planes describe how the organization can trust that answer, afford it and change it safely over time.

The Five Layers That Serve Each Request

Experience layer. A chat surface in Teams or Slack, a panel inside an existing application, or a Representational State Transfer (REST) and Model Context Protocol (MCP) endpoint. The user's identity enters with the request and travels with it to the last query the agent makes.

Agent runtime. A supervisor plans each request, narrow domain sub-agents do the work, and tools such as text-to-Structured Query Language (SQL) over a governed semantic layer, hybrid document search and MCP servers do the fetching. A state store lets approvals or claims pause for a human and resume at the right step.

AI gateway. The control plane in front of every model call. It screens prompts and answers, routes each question to the right model pool, serves repeats from a cache, attributes spend to each span, and enforces a soft alert and a hard spending cap. We treat it as non-negotiable: It is the one place cost, safety and routing hold across every agent.

Model pools. Small open-weight models for routine work, large models for real reasoning and a frontier model in reserve. Keeping most of the pool open weight means the routing design moves with the client from host to host.

Data and knowledge foundation. Governed tables, a semantic layer of business definitions, extracted document content, a hybrid vector and keyword index and, in advanced cases, an ontology. Agents are only as reliable as the context they retrieve, so this layer sits under the same change control as the agent, which is also why we built the Enterprise Context Engine.

The Three Planes That Make Every Answer Trustworthy

The release plane turns every change into a numbered, immutable version, scores it and promotes it by moving an alias, so rollback is one step. The observability plane records every span with its model, tokens, latency, cost and version. The governance plane decides what each agent and user may see and do, and writes every tool call to an audit table that cannot be edited after the fact.

A rule in a system prompt is guidance. A grant in the catalog is enforcement.

Already Running Agents? Add the Planes and Keep the Build

A live agent does not mean starting over. A gateway can sit in front of the models you already call, tracing can attach to the runtime you already run, and an evaluation set can be built from traces your users have already generated. For a Head of Data with a live agent, this is often the faster path, because real traffic shows exactly where the gate should be strictest first.

Up Next: Where Cost and Trust Get Decided

The architecture shows where the controls live, not how they behave under real traffic. Two carry most of the weight: Model routing decides what every answer costs, and the release gate decides whether it reaches a user at all. Part 2 of this series examines both in detail: How a routing cascade cut model cost by up to 20% on a manufacturing build, why a cache that ignores identity can turn a saving into a data leak, and how to replace the "vibe check" with a release gate whose catch rate you can measure.