The more authority we give AI agents, the better our evidence needs to be about what they actually accomplished.
By Randy J Rouse
The failed index calculations were the visible problem. The explanation was scattered across the infrastructure underneath them.
In a customer account published by Resolve AI, an agent connected signals across MSCI's network, Kubernetes environment and traffic reaching a retired server. It traced the problem to a hardcoded IP address still pointing at that server. Resolve reports reaching the root cause in 14 minutes, compared with historical investigations taking three to four hours.
That's a vendor-published account, and the comparison is historical. But there's another detail in it that interests me more than the speed.
The agent leads the investigation. Engineers drive the fix.
That boundary is worth paying attention to. Finding the problem and taking responsibility for changing the system are different parts of the job.
Now imagine moving that boundary. The agent investigates, decides what to change and makes the change.
Who determines whether it worked?
I think that's where the observability conversation gets much more interesting.
Delegation changes what we need to see
For years, observability has helped people understand what machines were doing. We collected signals, examined dashboards, followed traces and tried to connect what was happening in the system to what was happening in the business.
Agents are becoming another consumer of that knowledge. They can query operational data through interfaces such as MCP and command-line tools, investigate a failure and propose the next step.
The dashboard isn't disappearing. It's losing its monopoly on how we access operational knowledge.
But there's a second change underneath that one.
The machine consuming the evidence can also become the actor changing the environment. That gives us two things to observe: the system the agent is working on, and the agent's own decisions and actions.
Watching one without the other leaves part of the story missing.
In Where Does Value Live?, I explored what happens when agents separate the application interface from the capability underneath it. Work can continue even when the person stops opening the application.
The same question has an operational consequence. If work moves out of the screen, responsibility still has to follow the work.
We need to know what the agent saw, why it chose an action, what authority it used and what happened afterward.
Observability becomes a condition for delegation.
If I can't see enough to judge what happened, I have a much weaker basis for giving the agent more authority next time.
The system can be healthy while the business isn't
A slow database query is a technical observation. Understanding what depends on it changes the decision.
Imagine the same delay affecting an internal report in one case and customer checkout in another. Similar symptom. Different consequence. Different urgency. Potentially a very different acceptable intervention.
Severity tells you how badly something is broken. Business context tells you how much it matters.
That context has to survive the handoff to the agent.
Which process depends on this service? What changed recently? What has failed before? Who owns the process? What would restoring it actually mean?
An agent can follow a technically sensible path and still make a poor business decision. It might move the failure to another service, interrupt something more important or spend more on the investigation than the problem warrants.
Imagine a modest slowdown prompting repeated queries across large log stores, repeated model calls and more compute. The investigation keeps spending. The service doesn't improve.
Activity is increasing. Value isn't.
That's why the cost of an action belongs alongside its result. Time saved, recovery achieved, resources consumed and consequences elsewhere all matter. A spend limit and an escalation point should be part of the delegation from the beginning.
We've had automated operations, AIOps and feedback controls for years. Agents build on that foundation. What matters now is whether the context and controls remain intact as the agent chooses more of the steps for itself.
Authority has to follow the action
In Identity Stops at Login. AI Doesn't., I argued that trust decisions have to continue after access has been granted.
The observability question is closely connected.
An agent may be allowed to investigate a production issue. That doesn't settle whether it should restart a service, change permissions, delete data or deploy code. Each action has a different consequence, and the situation can change during the investigation.
Knowing which identity acted is part of the answer. We also need to understand whose authority it was exercising, what task was delegated and whether that particular action remained within the delegation.
Disclosure: I work at Quest. Quest Identity Insights, which incorporates Anetac technology, combines identity configuration with observed activity across Active Directory and Entra ID. It helps teams understand how identities are used and how their access relationships connect. That is one piece of this larger question: understanding what an identity could access and seeing how it is actually being used.
Identity context helps explain the actor and its reach. The operational controls still have to determine whether the next action should proceed.
Splunk's described workflow with Claude Managed Agents provides a useful example of making those boundaries visible: diagnosis, a proposed code change, validation and a pull request for an engineer to review. Splunk says Observability Studio controls the workflow and confirms the fix worked. Its September 17 announcement lists the Claude-powered remediation capability as alpha.
The important pattern is the separation of responsibilities. Understanding the problem, proposing a response, approving a change and evaluating the result each need a place in the operating model.
The agent finished. Did the business recover?
A tool can return success while the business process still fails.
A service restarts, but customers still can't complete an order. An alert clears, but the same change creates a problem elsewhere. The agent completes every step it planned, but the outcome we wanted never arrives.
Those are different definitions of success. Verification has to tell them apart.
For the illustrative checkout problem, I would want evidence that a transaction can complete, that the order reaches the system of record and that payment and neighboring services remain healthy. I would also want enough observation time to catch a regression.
The success criteria should be agreed before the agent acts. Otherwise, it's too easy to accept whatever evidence happens to be available afterward.
An agent's explanation can help us understand the decision. Evidence of the outcome needs to extend beyond the agent's account of its own work.
We also need to know where that evidence came from. A successful checkout test, a service log and the agent's own explanation tell us different things. Put them together, but keep the connection between each piece of evidence and what it actually proves.
Using a second model can help evaluate a decision, but another model name does not automatically make the evaluation independent. Two models may share the same incomplete context or accept the same mistaken assumption. Independence comes from the evidence, the success criteria and the authority to reject the result.
Some actions can be reversed. Others, including certain messages, disclosures and data changes, cannot be neatly undone. That should affect the authority we grant before the action, as well as what happens afterward.
If I were evaluating an autonomous operations system, I'd want to see the failure case.
Show me an action that failed. Show me how the failure was detected. Show me what stopped, what could be reversed, what was escalated and who remained accountable.
That tells me something a successful demonstration can't.
More autonomy has to be earned
The operational loop I would want to see is:
Observe → Understand → Decide → Act → Verify → Learn
Context supports the whole loop. Authority and escalation apply throughout it. Learning uses the verified result, including failures and unintended consequences.
Learning also means recognizing when an earlier lesson no longer applies. A fix that worked before can become the wrong response after the system changes. Keep the history, but know when to stop treating it as the answer.
The loop is also how I would think about expanding autonomy.
Start with a bounded task. Observe the decisions. Verify the outcome. Use that evidence to decide whether the agent deserves a wider scope next time. If conditions change or outcomes deteriorate, be prepared to reduce that scope.
Faster reasoning alone is a weak reason to expand authority. A record of useful, authorized actions with verified outcomes is a much stronger one.
The Boardroom Questions
If agents are going to operate inside critical business processes, these are the questions I'd want a leadership team to answer:
- What outcome are we delegating? Define the result and the limits on actions, access, time and spend.
- What evidence establishes success? Agree on a test that reaches beyond a tool response or an agent's summary.
- Who evaluates that evidence? Make the evaluator's independence and authority to reject the result clear.
- What happens when the action fails? Define when to stop, reverse, constrain or escalate, including actions that cannot be rolled back.
- Can we reconstruct the decision? Preserve the context, authority, actions, costs and verified result so the next decision can improve.
Someone still owns the business process after an agent takes over part of the work. That person needs enough evidence to judge the result and enough control to intervene.
The next expansion of agent authority should follow from that evidence.
We are getting better at giving machines work to do. The harder responsibility is staying accountable for what happens when they do it.
After the agent acts, who is watching the outcome?