AgentOps: who will operate AI agents in production?

Artificial intelligence agents are starting to leave the lab and enter company processes. Some serve users, others query knowledge bases, analyze documents, run tasks in corporate systems, or coordinate steps in a workflow. As these experiences multiply, a problem appears that is less visible than choosing a model or building the agent: who will operate all of this after it goes to production?

The question seems simple, but it changes a lot when we stop talking about a few isolated pilots and imagine dozens or hundreds of agents spread across the organization. You need to know which are active, who owns each one, which models they use, which systems they can access, how much they consume, what decisions they make, when they were changed, and how they behave over time, especially when AI spending grows faster than return.

This problem is gaining importance because adoption is moving quickly while the ability to scale remains uneven. In McKinsey’s global survey published in 2025, 62% of respondents said their organizations were already experimenting with AI agents, but only 23% said they were scaling some agentic system in at least one function [1]. Another study from the firm described a similar paradox: nearly eight in ten companies already used generative AI, but a similar share still did not see a significant impact on financial results [2].

The gap between those numbers helps explain why the next stage of corporate AI adoption will probably be less about creating agents and more about learning to operate them.

When an agent stops being a project and becomes part of operations

During a pilot, almost everything is simpler. There is a close team, the scope is known, the number of users is usually limited, and any unexpected behavior can be investigated by whoever built the solution. Even when there are failures, they can still be treated as part of development.

In production, that logic changes. An agent can stay active for months, receive new model versions, gain tools, access new data sources, and take part in processes that also change over time. Other agents may appear around it and start using the same systems, APIs, or information. What was initially a relatively isolated application becomes part of an operational environment.

At that point, basic questions get harder. Which version is running? Who approved the last change? Was there a change to the prompt, model, tools, or permissions? Did the consumption increase this week come from higher use or from abnormal behavior? Is the agent still producing the expected results? Is someone clearly responsible for it?

The more agents take part in operations, the less sustainable it is to treat them only as AI projects. They will need operational discipline.

In that context, the concept of AgentOps, short for Agent Operations, is gaining ground. The market also uses expressions such as AI Agent Operations and AI AgentOps to describe this same emerging discipline of operating artificial intelligence agents [6].

Inspired by practices we already know from DevOps, MLOps, and more recently LLMOps, AgentOps extends the operational problem to systems that can not only produce an answer but execute a sequence of steps, call tools and external sources, interact with other systems and, depending on the level of autonomy granted, take actions in the environment.

AgentOps is the discipline of putting and keeping AI agents in production in a controlled, observable, and reliable way, tracking their lifecycle, behavior, performance, costs, security, and governance.

The distinction matters because AgentOps is not just another name for MLOps or LLMOps. Those disciplines remain relevant and share many practices, but agents add a different operational dimension. An agent can interpret context, choose tools, define different paths to reach a goal, and produce different action sequences in similar situations. In multi-agent architectures, it can also delegate tasks or depend on other agents.

Operating it therefore means observing not only whether it is available, but what it is doing, why certain paths are being taken, and what results are being produced.

Availability will not be enough

In traditional systems, much of operations can be tracked with familiar indicators: availability, latency, errors, capacity, resource consumption, and performance. Those signals will remain important for agents, but they will probably not be enough.

Imagine an agent responsible for supporting a given corporate activity. Technically, it may be available, responding within the expected time, and without infrastructure errors. Yet it may be using tools inappropriately, repeating unnecessary calls, consuming far more tokens than planned, accessing a source that is no longer reliable, or producing progressively worse results.

From an infrastructure perspective, everything may look normal, while from an agent operations perspective there is a problem. That difference becomes even more relevant when agents stop only recommending and start executing actions. Inappropriate behavior may no longer produce only a bad answer and may instead change a system, start a workflow, open a ticket, query sensitive data, or trigger another agent.

That is why observability appears often in discussions about agents in production, as we explored in When agents start acting, who will be watching the agents?. In work on how to build, scale, and sustain agentic AI initiatives, Deloitte highlights the need to make behavior, performance, and decisions traceable and auditable, linking agent operations to continuous monitoring, policy enforcement, automated tests, and rollback mechanisms [3].

An agent can be technically healthy and operationally wrong at the same time.

That distinction creates a new layer of observation. We will need to track infrastructure and applications, but also execution, decisions, tool use, results, and consequences. In some environments, it will be necessary to reconstruct the sequence of steps that led an agent to a given action and understand what information was available at that moment, which connects to operational governance and traceability for agents.

This also brings AgentOps closer to themes we have already discussed in this series, such as operational context, governance, and autonomy. The more autonomy granted, the more important it becomes to observe and reconstruct system behavior.

The problem grows when the number of agents increases

The difficulty of operating a single agent is manageable. The challenge changes scale when each area starts creating its own.

Marketing may have its own agents, as may Finance, IT, security, support, engineering, operations, and human resources. Some solutions will be built internally, others will come embedded in platforms the company already uses, and others will be bought from specialized vendors. In that scenario, the organization can quickly reach a situation similar to other technology cycles: many useful components individually, but little visibility over the whole.

The Enterprise AI Maturity Index 2025 survey, conducted by ServiceNow with Oxford Economics among nearly 4,500 executives from 16 countries and 11 sectors, found a drop in average AI maturity score, from 44 to 35 points. The study links that difficulty, among other factors, to a skills gap, privacy and security concerns, and the absence of cohesive adoption strategies. It also found that 43% of respondents planned to adopt agentic AI in the following 12 months [4].

Deloitte reached a similar conclusion when discussing moving from pilots to production: scaling agents requires thinking from the start about governance, data architecture, and operating model, instead of treating those elements as later concerns [5].

The implication is important. We may reach a point where the ability to create new agents grows faster than the company’s ability to know which agents it has and how they are being used.

The risk is not only that one agent fails. It is losing the ability to understand the agent environment we are building.

That involves inventory, ownership, policies, versions, dependencies, costs, performance, security, and history. At some point, it will be necessary to answer questions that seem administrative but are operationally important: which agents are active? Who is responsible for them? Which processes depend on them? What data do they access? Which tools can they run? How much do they cost? What changes did they undergo? Which showed abnormal behavior?

Those questions also show why AgentOps should not be understood only as a new tool. The problem involves technology, but equally processes, responsibilities, and governance.

The notion of ownership becomes particularly relevant. When an agent crosses several systems and takes part in a process that belongs to different areas, someone needs to answer not only for the infrastructure that keeps it running, but for the outcome it produces.

Operating agents will be part of the autonomy journey

In recent articles in this series, we discussed that autonomy does not happen simply because a model became more capable, as we reflected in Agentic operations: are we ready to give autonomy to AI?. It depends on the architecture around it, the available context, supervision mechanisms, and trust built progressively.

AgentOps adds an operational dimension to that discussion. If an agent takes part in a process for a few weeks, it may be possible to follow it in an almost artisanal way. If hundreds of them run activities continuously, that approach stops working. We will need mechanisms that allow systematic monitoring of the environment, identification of unexpected behavior, and understanding when human intervention is needed.

That does not mean trying to predict every decision an agent might make. Part of the value of agentic AI is precisely the ability to handle situations that were not fully coded in advance. The challenge is to allow that flexibility without giving up the ability to observe, govern, and intervene.

Autonomy without operational capacity to monitor does not remove human work. It only moves the problem to after deployment.

Perhaps that is why the discussion about AgentOps is emerging now. The first wave of adoption focused much attention on models, prompts, copilots, and agents. As these technologies enter real processes, focus naturally shifts to what always happens when a technology becomes part of enterprise infrastructure: someone needs to keep it reliable over time.

The question, therefore, is not only how many agents an organization can create. It is whether it will still know what they are doing when that number no longer fits in a spreadsheet.

From vision to practice: ARGUS

This new scenario, in which agents stop being isolated projects and become part of operations, also expands the role of ARGUS.

ARGUS was built to correlate events from multiple sources, reduce noise, and build shared operational context about what is happening in the environment. With AI Gateway and AgentOps capabilities, that vision now also includes AI agents as participants in operations.

That means combining the operational context agents need to make more consistent decisions with a layer that supports their own operation. The AI Gateway applies policies and controls how agents and applications access different AI resources, while AgentOps expands the ability to orchestrate agents, track their runs and actions, and establish observability, governance, and supervision mechanisms.

Traces, tool calls, errors, latency, costs, and results help understand how agents are behaving, while operational context makes it possible to relate that behavior to what was happening in the environment when a given decision was made.

The differentiator is connecting both perspectives: understanding the agent and, at the same time, understanding the operation it is deciding on and acting upon.

That vision allows building a more complete operational timeline, linking infrastructure, services, tools, automations, people, and agents. As autonomy increases, that capability becomes important for investigating problems, applying policies, auditing actions, and gradually expanding agent autonomy with human supervision.

In that sense, AgentOps is not only a new feature of ARGUS. It is a natural extension of the proposal to build shared operational context and a systemic view of operations, now also incorporating orchestration and operation of the intelligences that begin to take part in it.

Learn about ARGUS and see how it works in practice.

About the author

Paulo Florêncio de Menezes is an entrepreneur, partner, and co-founder of companies such as Target Solutions, BiPTT, and ARGUS.

He holds a degree in Data Processing from the Federal University of Amazonas (UFAM), an MBA in Business Management from Fundação Dom Cabral (FDC), and a Professional Master’s in Economics from Fundação Getulio Vargas (FGV).

In his Master’s research, he developed the IBEOP-IA (Brazilian Index of Potential Occupational Exposure to Artificial Intelligence), investigating the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] McKinsey & Company. The state of AI in 2025: Agents, innovation, and transformation. 2025.

[2] McKinsey & Company. Seizing the agentic AI advantage. 2025.

[3] Deloitte. Beyond the pilot: Building, scaling and sustaining agentic AI initiatives. 2025.

[4] ServiceNow and Oxford Economics. Enterprise AI Maturity Index 2025. 2025.

[5] Deloitte. Agentic AI: Design for scale or prepare to fail. 2026.

[6] IBM. What is AgentOps? IBM Think.