AgentOps
From human-in-the-loop to autonomy: how much control?
Giving an agent autonomy does not simply mean removing the human from the process. The real challenge is defining which decisions can be delegated, under what conditions, and with which control mechanisms.
Autonomy does not have to be an all-or-nothing choice
In recent articles, we have moved through different dimensions of the same transformation. First, we discussed whether operations are really prepared to give autonomy to artificial intelligence. Then, drawing on the TM Forum’s Autonomous Networks journey, we saw in autonomous networks: an architecture prepared for autonomy that higher levels of autonomy depend on an architecture able to provide the knowledge and context to support decisions.
In the article on intelligence silos, I left a question that may be one of the hardest of this journey: even when an agent has enough knowledge and context to make a decision, how much control are we really willing to hand over to it?
The most immediate answer usually puts two alternatives at opposite extremes. On one side, we keep a person taking part in the important decisions, reviewing what artificial intelligence recommends before any action is executed. On the other, we imagine a fully autonomous operation, in which agents identify situations, decide what to do, and execute actions without depending on human approval.
In practice, there is probably a much larger space between these two extremes.
That is the space where the concept of human-in-the-loop gains importance, in which human participation remains part of the process, so the system can analyze a situation and recommend an action, but someone needs to validate it before execution.
In the first case, human participation is part of the decision flow itself, that is, the system can analyze a situation and recommend an action, but someone needs to validate it before execution. As trust increases, that participation can change. In certain scenarios, the system begins to act within previously established limits while people monitor its behavior and can intervene when necessary.
This difference seems small, but it represents an important change in how we think about automation and artificial intelligence. For many years, most operational automations were built deterministically: a given condition produces a previously defined action. We can test the flow, know the possibilities in advance, and establish with reasonable precision what will happen when each rule is triggered.
Agents introduce a different dynamic, because they can analyze context, choose tools, break down problems, formulate alternatives, and adapt their next steps according to what they find during execution. That flexibility is one of the reasons agentic AI is so promising, but it is also what makes it insufficient to treat its autonomy as if we were simply releasing one more workflow.
This concern takes on another dimension in critical environments. An inappropriate recommendation presented to a specialist can be identified before it produces consequences. The same decision, when tied to the ability to change configurations, restart components, block resources, or interfere with services, represents a different operational risk.
This does not mean agents should remain limited to producing recommendations indefinitely. If we do that, we may fail to capture an important part of the value promised by agentic AI. It means autonomy needs to be treated as a progressive capability, earned according to risk, predictability, and the trust accumulated in each scenario.
This logic comes quite close to the Autonomous Networks journey itself. The TM Forum does not treat autonomy simply as the absence of human beings. Its taxonomy describes an evolution in which systems progressively take on perception, analysis, decision, and execution, and the leap to L4 involves intent-driven operations, predictive analytics, and closed loops with significantly higher levels of autonomy. Today, the organization itself acknowledges that most operators are still between L2 and L3, although some are already advancing to L4 in specific domains.
Not every decision should receive the same level of autonomy
Imagine two relatively simple situations. In the first, an agent identifies a known condition whose cause has been confirmed many times and recommends a standardized, reversible, low-impact action. In the second, it identifies an unprecedented combination of signals involving different systems and proposes a change that may affect thousands of users.
It would be hard to justify giving both decisions exactly the same level of autonomy.
That difference leads us to an important point: autonomy should be tied to the risk of the decision, and not only to the technical capability of the agent executing it.
Even an extremely competent agent may encounter situations with little evidence, incomplete context, or consequences that are hard to anticipate. On the other hand, actions that are sufficiently well known, observable, and reversible may be good candidates for greater levels of automation.
In practice, this suggests a gradual evolution: an agent may start by only observing and explaining what it found. Then it may recommend actions for human approval. As its results are evaluated, certain classes of decision may be authorized under specific conditions. Only when trust, evidence, and control mechanisms are sufficient would it make sense to expand that scope again.
The analogy with the development of a less experienced professional helps understand this process. When someone joins a critical operation, they do not immediately receive all available permissions just because they have technical knowledge. At first they follow procedures, learn the particularities of that environment, and work under supervision. As they demonstrate competence and experience, they take on higher-impact decisions.
With agents, the logic can be similar, but there is a fundamental difference, because trust cannot be just a subjective perception that “the AI is working well.” It needs to be supported by evidence.
That means observing which recommendations were produced, which actions were executed, in what context they occurred, what the result was, and whether there were unforeseen consequences. It also means being able to reconstruct later why a given decision was made and what information was available at that moment.
This is where guardrails, policies, permissions, auditing, and observability of the AI itself stop being peripheral elements and become part of the operational architecture.
Guardrails can establish what an agent is authorized to do, which systems it can access, which actions require approval, and which conditions must interrupt an execution. Policies can incorporate criteria related to risk, criticality, and impact. Audit records make it possible to reconstruct decisions, while observability mechanisms help track agent behavior during operation.
It is not only about preventing errors. These mechanisms can make it possible to increase autonomy safely.
There is also a question that tends to gain importance as agents stop merely recommending and begin acting on infrastructure and services: who is accountable for the decisions made by the AI?
This question cannot be solved by technology alone. It involves corporate governance, responsibilities, security, compliance, and a regulatory environment that is still evolving. The TM Forum itself has been discussing the need for an enforcement layer capable of controlling and proving how AI systems behave while executing actions, especially in critical infrastructure and regulated environments.
That is why handing over autonomy does not mean giving up control, but shifting part of that control from the manual approval of each action to an architecture capable of defining in advance what can be done, by whom, under which circumstances, and within which limits.
The goal is not to remove people from the operation, but to change where they add value
When we talk about autonomous operations, there is a natural tendency to measure progress by the reduction of human intervention. The fewer people take part in an activity, the more autonomous it will seem. Although this relationship has some basis, it can lead to a limited interpretation of the goal of this transformation.
The value of autonomy is not simply in removing people from processes, but in no longer using specialists to continuously perform tasks that systems can carry out safely, letting them focus their attention on situations in which human judgment, experience, creativity, or responsibility remain important.
In a NOC, for example, a significant share of effort may be consumed by repetitive alarm analysis, searching for information across different tools, identifying already-known relationships, and executing recurring procedures. As systems take over these activities, people’s role can shift from executing each step to defining policies, handling exceptions, investigating unprecedented situations, and supervising the very intelligence that begins to take part in the operation.
This also changes how we should think about human-in-the-loop. Instead of simply asking whether or not there will be a person in the process, it may be more useful to ask where human participation produces enough value to justify its presence.
In certain scenarios, that may continue to happen before the action. In others, oversight may take place during execution or afterward, through analysis of the results. There will also be situations that are sufficiently well known and controlled in which human participation in each occurrence will no longer be necessary, although policies, auditing, and interruption mechanisms remain in place.
There is, therefore, no ideal level of autonomy that can be applied indiscriminately to the whole operation. There is a combination of scenario, risk, context, trust, and control mechanisms that determines how much decision space can be handed to agents at each moment.
And this combination is not permanent: as the environment changes, new agents are added, models evolve, and processes are modified, decisions previously considered safe may need to be reassessed. The governance of autonomy also needs to be dynamic.
Perhaps this is one of the most important points of this discussion. For a long time, governance was perceived mainly as something that restricted what systems and people could do. In agentic operations, it can take on a different role and be the mechanism that makes it possible to expand autonomy without losing control over its consequences.
The goal should not be to quickly reach an operation without people. It should be to build an operation capable of deciding, with evidence, where human participation remains necessary and where autonomy can already produce better results.
The challenge will not be simply deciding whether or not we trust artificial intelligence. It will be building mechanisms that let us know what we can trust, how far, and under which conditions.
And that may be a more useful definition of maturity for truly autonomous operations.
From vision to practice: ARGUS
Defining when an agent can act alone and when it needs human participation is a decision that depends on risk, the criticality of the action, and the confidence the organization has in the available control mechanisms.
ARGUS contributes to this scenario in two complementary dimensions. Through its AIOps capabilities, it connects information from different sources and builds the operational context needed to understand the situation before deciding. With AgentOps and AI Gateway, it extends this approach to tracking agent executions and applying policies to their activity.
This combination can help organizations gradually evolve their autonomy models, keeping visibility into what agents do and information relevant for oversight, investigation, and auditing.
ARGUS does not determine which decisions should remain a human responsibility. Its contribution is to support an operation in which autonomy and oversight can evolve with more context, traceability, and control.
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.