Support-case diagnosis in 6 seconds, with a person still deciding

The fastest way to get an agent into a regulated workflow is to give it less to decide. At a tier-1 global reinsurer, that turned a 60-minute diagnosis into a 6-second one without taking the decision away from a person.

The team handles technical support cases in ServiceNow. Before anything could be fixed, someone had to work out what was wrong: identify the systems involved, pull the right logs, read them, and search the knowledge base and past cases for anything similar. Done properly, that took about an hour per case.

Why not let an agent do all of it?

Two earlier pilots had tried to bring AI into this kind of work, and neither had left the sandbox. A fully agentic design, where a model decides which systems to query and what to do about the answer, is hard to test, hard to explain to a compliance function and hard to trust with access to production systems. So I split the work by what each part actually needs.

• Deterministic retrieval. The case's issue and tags in ServiceNow decide which logs to pull. That mapping is plain code: reviewable, testable, and the same every time.
• Agentic synthesis. An AI agent reads the logs it has been handed, searches the knowledge base and the case history for similar problems, and writes a diagnosis for the case.
• Human decision. A support agent reads the diagnosis, approves or corrects it, and actions the work in ServiceNow.

What the split buys

Speed is the visible result: the diagnosis is ready in about 6 seconds. The quieter results matter as much.

The agent never chooses what to access, because code has already decided. Its output is a proposal, never an action, so a wrong diagnosis costs a support agent a moment's reading rather than a change to a live system. And each part can be judged on its own terms: the retrieval rules like any other code, the synthesis by the people who approve or correct it every day.

That is also what made the design acceptable under human-in-the-loop requirements. The approval boundary sits exactly where it did before, with a person. What reaches that person is simply better prepared.

Where to start in your own workflow

The same split works well beyond support. Write down the steps of the current process as someone actually performs them, then mark each one. Where the answer is already known, such as which system a tag points to, write a rule. Where the work is reading, comparing and summarising, use a model, and hand it only what the rules have chosen. Where someone is accountable for the outcome, keep a person, and give them the model's work to start from.

Time the step you are replacing before you build anything. A before figure is what gives the after figure its meaning.

What carries over

• Split a workflow by what each step needs: rules where the answer is known, a model where reading and synthesis are the work, a person where the decision is accountable.
• Let code decide what the agent can see. Retrieval by rule is easier to test, and easier to approve, than retrieval by judgement.
• Keep the agent's output a proposal. The approval boundary is a design decision, not a limitation to remove later.
• Measure the step you changed. Here that was diagnosis, not the whole life of the case.

Six seconds makes a good headline. The design behind it is what got through review: the agent was given less to decide, and so it could be trusted with more of the work.