The AI Agent Diagnosed the Incident, Wrote the Notes, and Waited for a Human

Blog · IT Service Management

The AI Agent Diagnosed the Incident, Wrote the Notes, and Waited for a Human

By Shubham Rathore9 min read

Short answer

Read the verbs in every agentic-ITSM demo: detect, summarize, translate, suggest, recommend, surface. The one verb that carries the risk — execute — is quietly still a human's job.

Watch any agentic-ITSM demo to the end and keep a tally of the verbs. The agent detects the anomaly, summarizes the thread, translates the stack trace, suggests a probable cause, recommends the next best action, surfaces the right runbook. Then — at the precise moment something has to change in a real system — it opens a ticket, or asks a person to approve, and stops. Every verb in the reel describes knowing. The one verb that carries the risk — execute — is quietly still a human's job.

Start by giving the category its due, because the advisory work is genuinely good. An agent that reads a noisy incident, correlates it against similar past cases, drafts a clean summary for the on-call engineer, and proposes the likely fix is saving real minutes on every ticket. Deflecting a routine question with a well-retrieved knowledge article is a legitimate win — it keeps easy work out of the queue entirely. Summarizing a forty-message thread into three sentences a human can act on is exactly the kind of toil these systems should absorb. None of that is vapor. It is useful, and it is here.

But line the verbs up and a pattern is impossible to miss. Detect, classify, summarize, translate, suggest, recommend, surface, deflect. Every one of them is a verb of cognition — the system perceives, reasons, and advises. What is systematically absent from the demo's climax is a verb of consequence: grant, revoke, restart, patch, reconfigure, roll back, provision. The AI does the thinking out loud. The changing of state — the part where an entitlement actually moves, a service actually restarts, a config actually changes — is handed to a person, or to a script the person kicks off. The intelligence and the action live on opposite sides of a line.

Watch the two examples the AI-service-management vendors reach for most, because they are the tell. A password reset: the agent authenticates the user through a few conversational turns, confirms the account, gathers everything the fulfillment step will need — and then routes a task, or triggers a pre-built flow, so the reset can happen. An access request: the agent understands what was asked, identifies the right entitlement, drafts the request, maybe pre-fills the approval — and hands it to a workflow queue and an approver. In both, the agent is superb at the part that precedes the change. It collects. The moment of acting — the write that grants the access or resets the credential — is somewhere else, performed by something else.

To be fair and precise: some of these platforms do execute a narrow set of scripted fixes. A password reset can be wired to an automation, a disk can be cleared, a known flow can be fired. That is real, and it matters. But look at what it is architecturally — a bolted-on script, hand-built for a specific known case, that the ticketing tool orchestrates across to another system. It is an exception carved out of an advisory default, not the default itself. The instant the situation steps outside the pre-scripted set — a fix that touches a production change, an entitlement above a threshold, a remediation that spans three systems — the agent is back to what it does natively: it diagnoses, it drafts the notes, and it waits.

The temptation is to read this as a maturity gap — the execution just hasn't shipped yet, wait for the next release. That underestimates the problem. The handoff is not a missing feature; it is a property of where these tools sit. A service-management platform is, at its core, a system of record for the ticket. Its native object is the incident, the request, the change — a record with a status. Around that record it does four things extraordinarily well: it captures the issue, routes it, assigns it, and tracks its status to closure. The fulfillment — the actual mutation of the world the ticket describes — happens in systems the platform does not own: the directory, the cloud console, the ERP, the network fabric. It reaches those systems the only way it can: a human does the work and updates the ticket, or a script drives another system's interface as a last mile and reports back.

This is worth conceding plainly, because a lot of it is genuinely better than what came before. A single unified platform really does beat a drawer of stitched-together point tools. ITIL-aligned incident, problem, and change discipline really is valuable. A well-run configuration database really does make impact analysis sharper. Last-mile automation really does take manual steps off a person's plate. But add it all up and the architecture still records, routes, summarizes, and recommends. The AI made the recording and the recommending dramatically smarter. It did not move the execution across the line. When the workflow "resolves" a ticket, what it resolved is the record — someone, or something bolted on beside it, resolved the world.

That line has a name in the demo, even if no one says it out loud: the boundary between the system that knows and the system that acts. Everything on the near side is fast, intelligent, and safe to show. Everything that carries risk lives on the far side, and the agent politely stops at the border.

SYSTEM OF RECORD FOR THE TICKET capture route assign status fulfillment happens elsewhere another system human · bolted-on script the fix status only ONE GOVERNED WORKFLOW ON THE FABRIC resolved — closed loop, no boundary incident / request change control governed connector system approval · SoD · threshold · HITL a non-compliant fix cannot execute immutable per-action record: diagnosis → gate → connector → effect

Entroid removes the boundary — not by making a smarter advisor, but by changing what an incident is. On the fabric, an incident or a service request is not a record a human works and closes beside the systems where the fix lives. It is a running Deterministic Workflow composed with Atomic Agents, and that composition performs the remediation itself, through governed Connectors, on the underlying estate. The password reset is not collected and handed to a flow — the workflow resets the credential. The access request is not drafted and queued — the workflow grants the entitlement, or routes to the human whose approval the grant requires, and then grants it. The diagnosis and the change are the same governed process, so a correct diagnosis becomes a correct fix without ever crossing a line.

The reason this is safe to say — and the reason it is not the over-claim the category makes — is that the acting is bound by the same governance as every other action on the fabric, enforced inline at the moment of execution:

  • Permissioning at action time, not suggestion quality. An advisory agent can recommend a fix no matter who is in the chair, because a recommendation changes nothing. An Atomic Agent that executes runs under the invoking identity's real entitlements — the permission check happens where the write happens. The question stops being "is the suggestion good?" and becomes "is this actor allowed to make this change?" — answered before state moves, not after.
  • Change-control as an inline gate, not a downstream ticket. When the remediation touches something that needs a change record, segregation of duties, an approval, or a threshold, that control is a step the action must pass through to execute — not a form filed alongside a change that already happened. A non-compliant fix does not get flagged after the fact; it does not run.
  • An immutable per-action record, as a byproduct. Because the diagnosis, the gate decision, the connector call, and the resulting effect are one execution path, the audit is what the path leaves behind — not a log assembled to look like one. What changed, under whose authority, past which control, is recorded because the action could not have travelled any other way.
  • The configuration state is live. The impact analysis the agent reasons over is read from the semantic ontology the enterprise actually runs on — a live model, not a periodically reconciled inventory that is right on average and wrong at the moment you needed it.

This is the honest version of the payoff, so state its limits too. None of it means ES touches your systems without integration — the opposite. It executes over the existing estate, and Connectors are the one primitive that reaches an external system. The difference is not the absence of integration; it is where the integration sits. In the advisory model, the touchpoint to the real system hangs off the far side of the boundary, orchestrated across. On the fabric, the touchpoint sits inside the governed path — which is the whole reason the fix can be an authorized, audited action instead of a handoff.

Removing the boundary is not the same as removing the human, and the distinction is the point. The advisory pattern stops at the human because that is the only place its architecture can stop — the person is the execution engine of last resort. On the fabric, human-in-the-loop is a first-class primitive, placed deliberately where judgment is genuinely required: a high-blast-radius production change, an entitlement above a sensitive threshold, an irreversible step that deserves a person's eyes. The workflow pauses, surfaces exactly what the agent proposes to do and why, and resumes with the decision recorded as part of the action. That is a governed checkpoint by design — not a dead end reached because the software ran out of things it was allowed to do.

So the wedge is narrow and it is exact. It is not that the AI-service-management vendors never execute — some fire narrow scripted fixes, and credit where due. It is that their execution is a scripted exception to an advisory default, each case hand-wired and ungoverned as a class. ES's execution is the default, and every action — the routine reset and the sensitive change alike — travels the same inline governance. When the pattern is "advise by default, script a few exceptions," the exceptions carry no shared guarantee. When the pattern is "execute under governance by default," the guarantee is the architecture, and it holds across every process on the fabric, not just the ones someone remembered to automate.

Diagnosis was never the hard part of an incident. Being allowed to act on it was — and that is the exact part the demos quietly hand back to you.

See what this looks like for your enterprise.

Not a demo. A strategic conversation about how your enterprise could operate
when every process runs on one governed fabric.

Start the Conversation