INTELLERTS AGENTOPS SERIES | PAPER 1
A practical toolkit for keeping AI models and agents accurate, affordable, safe and
accountable once real users depend on them.
BY DARIUS DILIJONAS, INTELLERTS
An agent that issues a refund, updates a customer record or drafts a supplier email can look flawless in a demo. Run the same task ten times and the picture changes. The τ-bench benchmark measures whether an agent succeeds on every one of several attempts, and success falls sharply as the attempts add up. A process that works once in a demo may fail one time in four in production. That gap between the demo and dependable operation is where most AI value is lost. In McKinsey’s State of AI 2026, 44% of organisations say AI is scaling across the enterprise, yet only 37% attribute any EBIT impact to it. Closing the gap is the job of MLOps and, for systems that plan, use tools and act, AgentOps. The argument in brief: most of an AI system is everything around the model; evaluation is the new centre of gravity; the session is the unit of observation; cost is an operational metric; governance belongs in the platform. The rest of this article turns that argument into tools you can use this quarter.
1. Know what you are operating
A few years ago an MLOps platform managed models: trained artefacts with defined inputs and outputs,
judged on precision, recall or AUC. Today many AI systems combine a foundation model, prompts, a retrieval
layer over company knowledge, tools the system may call, memory of earlier interactions and rules about
what it may say or do. Each part can change on its own, and each change can alter the behaviour of the
whole.
LLM and agent system (2026). Yellow marks what most people think of as “the AI”. Everything else is where production systems
succeed or fail.
Two working definitions anchor the rest of this article.
MLOps is the set of practices, platforms and responsibilities that keep AI systems accurate, affordable, safe and accountable once real users depend on them.
AgentOps extends MLOps for systems that decide, use tools and act on their own, with trajectory evaluation, session tracing, runtime guardrails, least-privilege access, human checkpoints and cost control per task.
In practice, three things change when you move from models to agents:
MLOps | AgentOps | |
|---|---|---|
Unit of work
| A single prediction
| A multi-step task or session
|
Typical failure
| Wrong classification or low confidence
| Unauthorised data change, unintended
transaction or runaway API calls |
Cost driver | Training and serving compute
| Model and tool calls per task, which vary
from run to run |
Use it this week: list every asset behind one of your AI systems (data, code, model version, prompts, retrieval
index, tool definitions, agent configuration, evaluation set, guardrail policies) and check which of them are
versioned together. Any output should be traceable to exactly what produced it.
2. Decide the level of autonomy before you build
When an agent may act on its own, the lifecycle gains decisions a chatbot never needed: which actions it
may take, at what level of autonomy, and how you will know when a session goes wrong. Make those
decisions explicit, in this order:
- Define boundaries before prompts. Write down the goal, the tools, the data scope, the actions that need approval and the budget per task before building anything.
- Start with the simplest pattern that works. Anthropic distinguishes workflows, which follow predefined code paths, from agents, which direct their own process, and recommends adding autonomy only when simpler compositions fall short. Databricks warns against overly broad use cases and premature multi-agent orchestration.
- Release autonomy in stages, one level at a time, and only on evidence from evaluation and production.
Level | What the agent does | Typical controls |
|---|---|---|
1 Assist | Drafts, summarises and suggests. A person takes every action. | Output evaluation, disclosure that AI is involved |
2 Recommend | Proposes actions with its reasoning. A
person approves each one. | Approval interface, trace of the rationale, sampled review |
3 Act with approval | Executes within its scope, with approval for defined high-impact steps. | Action validation, human-in-the-loop triggers, audit log |
4 Act within bounds | Executes autonomously inside strict limits. People review samples and exceptions. | Budgets per task, anomaly alerts, kill switch, periodic re-evaluation |
Use it this week: place each agent you run or plan on this scale, and write down the evidence you would need
to move it up one level.
3. Make evaluation an entry criterion
An LLM application that answers customer questions or summarises contracts produces free text, and there
is rarely one correct answer. Quality becomes a set of properties: correctness, grounding in the retrieved
sources, completeness, tone, safety and policy compliance. Without measurement, nobody can tell whether a
new prompt, model version or retrieval change made things better or worse.
For agents, evaluation scores the whole trajectory. A correct result reached through a forbidden tool call
counts as a failure. Five criteria cover most cases:
- Goal achievement: the task completed as the user intended, including side effects in other systems.
- Tool-use correctness: the right tool, with the right arguments, in the right order, and no invented arguments.
- Constraint adherence: the agent stayed within permitted data, actions and policies.
- Efficiency: steps, tokens, latency and cost per completed task.
- Consistency: the same scenario run several times, because agents are non-deterministic. Observability follows the same logic. Trace each agent session from the first instruction to task completion, including every model call, retrieval and tool call. Engineers debug with those traces, product owners learn from them and risk teams use them as evidence. Open standards such as the OpenTelemetry conventions for generative AI keep them portable between tools.
A PRACTICAL MINIMUM FOR ANY LLM APPLICATION OR AGENT
- An evaluation set of real tasks, owned by the business, before the first release.
- Automated evaluation on every change, with a quality threshold that blocks release.
- Tracing of every production request or session, retained long enough to investigate incidents.
- Sampled evaluation of live traffic, reported weekly to the system owner.
- Cost per request, per task and per use case, visible to the team that makes design decisions.
- For agents: trajectory scores, repeated runs per scenario, and alerts on loops, repeated tool calls and budget overruns.
4. Measure cost per completed task
About one in five organisations say AI running costs already constrain their AI use. Generative AI costs scale
with usage, prompt length and the number of steps an agent takes, and a design choice made in a prototype
can multiply spend in production. One agent request can trigger several model calls, retries and guardrail
checks, so cost belongs on the same dashboard as quality and latency.
- Measure cost per request, per task and per use case, and give it an owner with a budget.
- Route simple tasks to smaller or cheaper models when evaluation shows quality holds.
- Cache repeated context and limit the number of agent steps per task.
- Set a hard budget per task for steps, tokens, time and spend, and stop the run when it is reached.
- Detect loops and repeated tool calls before they reach the invoice.
- Compare the running cost with the value of the work it replaces, before scaling.
Two pieces of infrastructure give most of the control. A gateway in front of models routes, limits and
logs every model call. A tool gateway does the same for actions: which agent may call which tool, with
which arguments, under which identity. With more than 10,000 published MCP servers, that gateway
lets you use the ecosystem without giving every agent access to everything.
Use it this week: ask your team three questions. Which agent types cost the most per completed task?
Which tool calls repeat unnecessarily? Which sessions run away from their budget? If nobody can answer,
cost is still logged per call instead of per session.
5. Produce governance evidence as a by-product
The EU AI Act turns much of AI governance into dated obligations. In July 2026 the Digital Omnibus on AI
(Regulation (EU) 2026/1744) moved the high-risk obligations to December 2027 for stand-alone systems and August 2028 for AI embedded in regulated products. The transparency duties of Article 50, such as telling people they are interacting with an AI system, apply from August 2026.
The Act has no separate category for agents. The European Commission’s AI Act Service Desk confirms that the existing rules cover them, so obligations follow the use case: an agent that screens job applicants can be high-risk, and an agent that talks to customers must disclose that it is AI.
Most of what auditors ask for is operational evidence. Which systems run, and for what purpose? What
produced a given output? How was it tested, and who can intervene? For agents, add two questions: which
actions was the agent allowed to take, and who approved them? Organisations with mature MLOps and
AgentOps produce those answers from normal work. Others reconstruct them after the fact, slowly and often
incompletely.
Capability | What it takes |
|---|---|
Know what you run | An inventory of AI systems, agents and use cases, each with a risk classification, a purpose and a named owner |
Keep the evidence
| Versioned data, models, prompts and tools, evaluation results and traces that can be retrieved for any output or action |
Design for oversight | Defined human review points and the ability to pause, stop or roll back a system or an agent |
Be transparent | Clear disclosure when people interact with AI or receive generated content |
Bound the agents | For every agent: its tools, permissions, autonomy level and budget, reviewed like any other access right |
Align the owners | Clear responsibilities across engineering, product, security, compliance and finance |
Obligations depend on your role and on the risk category of each system. This overview is not legal advice.
6. Choose tools you can leave
The tooling market is consolidating fast. Between May 2025 and February 2026, Weights & Biases, Protect
AI, Tecton, Lakera, Neptune.ai, Langfuse and BentoML were acquired or joined larger companies, and
Neptune shut down its hosted service in March 2026. Seldon Core moved to a source-available licence in
2024.
In 2022 we tested nine open-source tools on one realistic use case: a classifier trained on 376,617 records.
Looking back, the choices anchored in lasting needs held up. MLflow, Airflow and BentoML, which we recommended, are all actively developed today. The tools that were hardest to install stayed niche. Standard
interfaces (containers, OpenAPI, Kubernetes, and now OpenTelemetry and MCP) outlived every product built
on them.
Use it before your next tool decision: ask how you would leave the tool. Which export paths, open formats,
open protocols and self-hosting options exist? Weigh governance evidence, running cost and support for
open agent protocols alongside features, and review the answer every year.
What to do this quarter
- Give every production AI system, including agents, a named owner, service levels and a budget per use case.
- Make an evaluation set and a quality gate an entry criterion for every release, and derive new test cases from production traces.
- Trace every agent session and report cost per completed task.
- Put a gateway in front of models and tools, and give every agent explicit boundaries and a tested way to stop it.
- Choose tools on governance evidence, portability and running cost, and review the choices every year
Sources
McKinsey & Company (QuantumBlack), The state of AI in 2026, August 2026 · Yao et al., τ-bench,
arXiv:2406.12045, 2024 · Anthropic, Building effective agents, December 2024 · Databricks, The Big Book of
AgentOps, 2026 · OpenTelemetry semantic conventions for generative AI · Linux Foundation, Agentic AI
Foundation announcement, December 2025 · Regulation (EU) 2026/1744 · European Commission AI Act
Service Desk, FAQ on AI agents · Dilijonas & Danėnas, An Evaluative Study of MLOps Tools, Intellerts, 2022.
Paper 1 lists all 32 sources.
