What AgentOps is: a complete guide to the operating framework for controlling and improving AI Agents that carry out work

AgentOps is a framework for operating agents safely that records the entire process by which an AI Agent calls tools, enters data into systems and carries out work, and manages permissions and approval, task-level evaluation, and stopping and recovery.

Why AgentOps is needed

AI began to leave behind actions, not answers.

When generative AI only answered questions, people could filter out wrong answers. AI Agents are different. They read documents, judge conditions, register values in ERP, send emails and hand work on to the next step. A single wrong judgement leaves traces across several systems.

An agent handles each case in multiple steps. Without a record of which tool it called at which step and on what grounds, there is no way to tell, when a result is wrong, whether the cause was recognition, the decision rules or the system integration.

Work can be entrusted to an agent only when the scope of what it may do is defined, points requiring human approval are in place, and it can be stopped and rolled back if something goes wrong. AgentOps is the operating framework that brings these requirements together.

The difference shows when agents are extended from pilot work to real work. In a pilot, staff watch every result, but as volume grows people cannot check each one, so recording and control must be built in as a framework.

What AgentOps actually is: how it differs from LLMOps

LLMOps and AgentOps across three axes

First, the unit of management differs. LLMOps manages the input and output of a single model call. AgentOps manages the entire chain of judgements, tool calls and system entries linked together to process one case.

Second, the nature of the risk differs. The risk LLMOps mainly deals with is wrong or ungrounded answers. AgentOps also deals with the risk of actions, such as accessing systems outside its permissions, registering values without approval or running the same task repeatedly.

Third, the evaluation criteria differ. LLMOps scores the accuracy and format of answers. AgentOps looks, case by case, at whether the work was processed correctly to the end, where people intervened, and how much processing time and cost it took.

AgentOps does not replace LLMOps but sits on top of it. The models and prompts used inside an agent are managed with LLMOps, and the workflow those models drive is managed with AgentOps.

Four functions that make up AgentOps

Four functions for entrusting work to agents

First, execution tracing. For each case, record in order which documents were read, which rules were applied in judging, and which tools were called with which values.

Second, permissions and approval. Separate systems the agent may only query from systems it may also write to, and require cases with large amounts or deviations from criteria to be approved by a person before execution. Approval criteria should be kept as separate rules rather than inside the agent's configuration, so that the business department can check and change them.

Third, task-level evaluation. Look at the task completion rate, exception rate and processing time per case alongside step-by-step accuracy. Even if every step scores well, the work is not finished if the flow breaks off partway.

Fourth, stopping and rolling back. When abnormal behaviour is detected, it must be possible to stop the agent and cancel entries already made or hand them over to a person.

The four functions interlock. Execution records are needed to adjust approval criteria, and the ability to roll back is what allows permissions to be widened.

How AgentOps is applied in practice

Start with narrow permissions and widen them

Do not give the agent write permissions from the start. Initially, have it only propose judgements and values to enter, with a person approving execution. Move task types with almost no corrections in the approval history to automatic execution first.

Recording the switching criteria and date each time permissions are widened shows which decision to trace back from when a problem arises.

Keep execution records that business staff can read

Developer logs alone do not let the business department review the agent's judgements. Also keep a processing history that summarises, in business terms, the location in the original that grounded each judgement, the rules applied and the actions taken.

The processing history is both material for audits and the starting point for improvement. Gathering the cases in which staff corrected the agent's judgement reveals which rules are lacking and which document types unsettle its judgement.

Validate changes on the same cases

When changing decision rules, models or integration methods, rerun cases processed in the past and compare how the results differ. Check first in a test environment that does not write to real systems, then put the change into operation after approval. Keep the pre-change version so that it can be restored immediately. Where results for past cases have changed, confirm one by one whether the difference stems from the intended change.

AgentOps in the Korean environment

Korean finance and the public sector strictly require accountability and access records for computer operations. Entries made by an agent must leave the same level of record as a person's work, showing who approved them and on what grounds they were executed.

Integration with existing ERP, EDMS and RPA is common, so issue separate accounts and permissions dedicated to the agent, and configure the setup so that execution records can be kept internally even under network separation.

Frequently asked questions