AI Can Work the Ticket. Who Governs the Change?

An Empty Queue Needs an Explanation

I once worked in an environment where the approach to old tickets was to close them. If the problem still existed, the reasoning went, somebody would reopen it.

In another environment, we had no incoming tickets for several days. It turned out there was a DNS problem with the ticketing system. People could not open them.

The ticket count looked excellent. The service had a problem.

That experience comes back to me whenever the industry talks about the percentage of tickets AI can handle. It is a useful measure, provided we are clear about what handling one means. Investigating it, recommending a change, executing a fix, verifying service, and completing the record are different pieces of work.

My test is whether we can follow an incident through those pieces and inspect what happened. That gives an engineer something to evaluate beyond the status field on a ticket.

A Recommendation Still Leaves Work in the Queue

An agent that investigates an incident and writes up findings can be useful immediately. It can gather context while the engineer is working on something else. It can save the next person from starting with an empty ticket and a vague complaint.

But a recommendation also hands work back to somebody. The engineer still needs to assess the proposal, get the appropriate approval, execute the change, and verify the result. A long AI-generated explanation can become another thing to read while the service remains broken.

This is why I am interested in the move from AI assistance to agentic infrastructure operations. The reasoning needs a path to action, with controls that hold when the agent uses it.

Follow One Incident Through the Boundary

Joksan’s example started with a remote host that could not reach 8.8.8.8. He had planted a blocking access control list, or ACL, entry in the lab. The ticket identified the source host, site, and destination, giving the investigation somewhere specific to begin.

He divided the work among three FlowAgents.

• The incident coordinator managed the ticket, routing, and approval.
• The triage agent investigated through read-only infrastructure tools.
• The remediation agent had the tools to apply the approved configuration and verify the result.

The triage agent found that the host could reach its default gateway but could not reach the destination. It investigated the border device, identified the ACL entry, and proposed a change with rollback information.

Here is the detail I would want an engineer to stop on: the agent doing the diagnosis did not have infrastructure write tools. Its available capabilities bounded the investigation. A recommendation could become a proposal for review; it could not quietly become a configuration change during troubleshooting.

In Work Center, the human could review the evidence, the proposed configuration, the preconditions, and the rollback information. After approval, the separate remediation agent took over.

That is a specific boundary you can inspect and test.

Approval Is One Control in the Execution Path

Putting a person in front of a proposed change is useful when the decision needs their judgment. It also needs supporting controls. The system must enforce the agent’s permitted tools and the access under which they run, and it needs checks around execution.

In this case, the remediation agent checked the current conditions again before applying the change. That matters if an incident is transient or execution waits for a change window. An approval based on yesterday’s evidence does not establish that yesterday’s problem still exists.

Earn Autonomy One Capability at a Time

There is a useful nuance in Rahim’s interview: alongside the broad forecast, he describes letting operators enable automated actions incrementally, capability by capability. That is the practical adoption discussion worth having.

A two-to-three-year prediction does not tell you which action your organization should authorize next. Your incident history, operational policy, and test results are much more useful inputs to that decision.

Pick a recurring ticket and work through five questions:

1. What context does the agent need to identify the affected host, device, and service?
2. Which read-only checks establish the cause, and when should the agent stop or escalate?
3. Which action is permitted, and which conditions require a human decision?
4. What pre-check, post-check, and recovery path belong around that action?
5. What evidence must return to the ticket so another engineer can review the result?

Start with the investigation if that is the scope your team can support today. Add approved remediation when the execution path is ready. For actions that eventually run without case-by-case approval, define the permitted scope and the conditions for escalation explicitly.