An agent's completion message is a claim that the operating model must be able to check. So how can we evaluate how well your agents are working?
Building my own agent system made this concrete. My monitoring page distinguishes a recorded run from a missing run and from a workflow for which no expectation has been configured. It also shows when the checker last ran. A reassuring status loses meaning if the mechanism producing it has stopped.
Those distinctions are deliberately modest. Evidence that a routine ran does not prove that its output was useful or complete. A delivery record does not establish sound judgment. Each additional claim needs its own evidence.
This is a useful starting point for enterprise agentic operating models. Before expanding what agents can do, establish what the organization can observe about their work and who will act on that information.
An operating model should describe how a particular outcome is produced. Where does the request originate? What work is assigned to people, fixed automation, or agents? What information and systems are involved? Who receives the output? Who is responsible when the chain stops halfway through?
The model needs to remain understandable beyond the team that built it. A business owner should be able to describe the service and its limits. An operator should be able to identify a failure and take the next step. A reviewer should be able to inspect the evidence relevant to the decision they are being asked to make.
Take an illustrative intake agent. It reads a new request, checks required information, searches an approved catalog, and prepares a recommendation for routing. A second component updates the record after the authorized person makes a decision. The workflow crosses several boundaries, even though the user experiences it as one service.
At each boundary, something should be verifiable. Was the correct request read? Which catalog version was available? Was an update accepted by the receiving system? Did the recommendation reach the assigned reviewer? If a step failed, did the workflow stop or continue with incomplete information?
The relevant record should contain observable actions, source references, applied rules, approvals, results, and exceptions. A generated explanation can help a reviewer understand a recommendation, but it should not be mistaken for proof of what the system actually did.
Authority then becomes specific. The agent may read certain records, create a draft in a designated location, and route eligible requests. It may be prohibited from approving investments, changing policy, or contacting people outside the workflow. These boundaries need to be reflected in permissions and system behavior, as well as instructions.
A named business owner remains accountable for the outcome. That person does not have to perform every technical task. Technical operations may maintain integrations and reliability; data owners may maintain sources; control functions may define mandatory constraints. The operating model should make those responsibilities connect rather than leave gaps between them.
Exceptions deserve the same care as the expected path. Define who receives an unresolved case, what information accompanies it, how urgently it needs attention, and what happens if the recipient is unavailable. A handoff is incomplete until someone can accept responsibility for the next action.
Recovery requires choices too. If the system attempted a write and received no confirmation, should it retry? Could that create a duplicate? If only part of a workflow completed, can the team safely resume it? These questions are easier to answer before an incident, with a clear record of what is known and what remains uncertain.
NIST's AI Risk Management Framework treats governance, measurement, and management as continuing responsibilities across the lifecycle. That is a useful orientation for agents: authorization begins an ongoing responsibility to assess performance and respond to change. The framework is voluntary guidance, and its application needs to fit the organization's context. Source
Widening authority should therefore be a documented decision about a defined class of actions. State which evidence supports it, which limits remain, and what would trigger suspension. An agent that performs well on one class of request has not automatically demonstrated readiness for another.
Changes to the system can also invalidate prior confidence. A new model, connector, source document, or business rule may alter behavior. Retest relevant cases, retain a record of the change, and decide whether the current permissions still make sense. The organization should be able to reduce authority as readily as it expands it.
The commercial side belongs here as well. Someone needs visibility into operating cost, human review effort, incident handling, and continued usefulness. A service that costs more to maintain than the value it creates should be eligible for redesign or retirement, even if its technology remains impressive.
Before approving the next expansion of an agent's role, ask the team to reconstruct one completed case and one failed case from the available evidence. What can they establish, what must they infer, and which missing observation would change your willingness to delegate?