One flow.
Three layers.
A pattern we keep arriving at when customers ask where to start with AI Agents — and why the answer is almost never a product.
Most of our working weeks are spent in workshops with customers, talking about their service data — and, where a customer asks us to and gives us access, looking at it with them in their own environment. Incidents, requests, catalog items, search behaviour, assignment groups. Always alongside the people who own that data, never instead of them.
And after enough of those weeks you stop seeing individual organisations and start seeing the same shape over and over again.
This series is our attempt to write that shape down. It is a summary of what we have identified over the last months, put in front of a wider audience in the hope that it is useful — and in the hope that people who see it differently will say so.
The first four parts are published together, so you can read straight through rather than wait a week between instalments. The remaining two follow shortly.
It is not a product launch and not a maturity model. It is the working structure we ended up with because we needed something to answer one specific question, and we needed to answer it roughly every second week. Over six parts we will take it apart: the pattern itself, the method we use to find evidence for it in an instance, and then each of the three layers — including a working build you can import.
Everything in this series was developed in customer engagements, not in a lab. That means it is opinionated, and it means some of it will not fit your organisation. Where we are guessing, we say so. Where a number is a sample rather than a measurement, we say that too — that distinction turns out to matter more than almost anything else in this space.
And one thing to set straight before we start: where we share something we built, it is a demo-grade MVP. Not a product, not on a roadmap, not supported by anyone. It exists to show that an idea works and to let you rebuild it properly. If you were hoping to install your way out of this, we are about to disappoint you.
Two people, one missing thing
The same question reaches us from two very different seats on the customer side, in almost the same words. Both of these are composites of people we have actually sat with.
Miriam
She owns the platform. Three weeks ago her sponsor asked her, in a steering committee, “So — what are we doing with AI?” Since then she has collected forty-one ideas from twelve teams. She has budget. She has a slot on the board agenda. She has an executive who expects a number.
What she does not have is a way to decide. Every idea sounds plausible. Every team believes theirs is the obvious first one. Nothing in the list tells her which one to fund.
Jonas
He works on Miriam’s team and knows the instance better than anyone in the building — which catalog items are dead, which assignment groups exist because of a reorganisation in 2019, where the close notes stop being written. The forty-one ideas have started landing on his desk, and roughly all of them are described as a quick win.
He is not worried about whether he can build an agent. He can. What he cannot answer is what to build it for, and he can already see which of the forty-one will collapse the moment it meets the real catalog.
Miriam and Jonas are missing the same thing, and it is not tooling and not model access. Both have plenty of ideas and no structure to decide inside. Without a structure, a list of forty-one ideas is not a plan — it is forty-one arguments waiting to happen.
When there is no structure, one of two things happens. Either the organisation builds the idea with the loudest sponsor, or it builds the idea that is technically easiest and then cannot explain the business case. We have watched both. Neither survives the second quarter.
What kept showing up
Once you stop looking at ideas and start looking at how work actually enters an organisation, the picture simplifies dramatically. Every request — an incident, a service request, an HR case, a customer case — passes through the same three decisions before anyone resolves it:
- Can this be answered before it becomes a record at all?
- If not, what kind of thing is it, and what is missing?
- Who or what can actually resolve it end to end?
Those three questions are not a process we invented. They are already being answered in every organisation today — usually by people, usually inconsistently, and usually without anyone owning the answer. That is the whole opportunity. Three questions, three layers.
Figure 1. One flow, three layers. The band is schematic — it shows relative volume, not a measurement.
Deflection
- Job
- Resolve in the channel, before a request is ever created.
- Scope
- Channel-specific. Self-service, chat, voice, email and monitoring each need their own design — one deflection strategy pointed at all of them underperforms in all of them.
- Test
- What resolves here never becomes a ticket.
Qualify & Triage
- Job
- Classify what arrives, ask for what is missing, and answer the genuinely simple things.
- Scope
- Deliberately narrow. A handful of actions, a fixed and pre-approved set of categories. It decides — it does not solve.
- Test
- Every record leaves this layer with a category that means something.
Vertical Agents
- Job
- Domain specialists resolve end to end, acting inside the systems of record.
- Scope
- Scoped to one category, not to one team. Identity, endpoint, ERP, network, collaboration — the work follows the topic, not the org chart.
- Test
- It acts. It does not advise and hand back.
Read top to bottom, the volume narrows at every step. Each layer hands over less than it received, and hands it over in better shape. When a human finally picks something up, it arrives with a category, the steps already attempted, and what was found — never back to square one.
Why the pattern holds up in a governance review
Conceptual clarity is cheap. The reason we still use this structure a year later is that it survives the conversations that usually kill AI initiatives — risk, audit, and “who is accountable when it gets it wrong?”. Three design decisions do that work.
The category is a contract, not a case-by-case decision
Layer 2 does not invent a route. It picks from a set that was defined and approved in advance, and one category always leads to the same downstream outcome. That single constraint is what makes the layer auditable: you can always show which category triggered which action, and you can change the routing without retraining anything.
Escalation exists at every layer, with the work attached
Anything outside scope goes to a human. That is not a failure mode, it is the design. What matters is that the handover carries context — what was tried, what was found, why it stopped. An empty escalation is worse than no automation at all, because it costs the requester time and teaches them not to trust the channel.
Each layer ships on its own
This is the part customers tend not to believe at first. You do not have to finish Layer 1 to start Layer 2, and Layer 3 does not require either of them to be complete. Layers 1 and 2 are largely configuration and taxonomy work — the build lands in weeks. What actually paces them is not engineering, it is agreement: deciding which categories exist and who owns them. That is why you start with the agreement rather than waiting for it. Layer 3 rolls out in waves, one category at a time. All three can be picked up now, and each keeps paying off even if the target architecture changes underneath it.
The value is not one clever generalist agent. It is many small, well-scoped ones, sitting in a structure that says which one runs when — and a narrow agent that decides reliably is worth more than a broad one that improvises.
What this is not
Three clarifications, because all three have come up in workshops and all three change the conversation:
- Not a maturity model. There is no level to reach. The layers are parallel tracks with different rollout horizons, not steps on a ladder.
- Not IT-only. We describe it with incidents and requests because that is where the data is richest, but the same three decisions run in HR, in customer service and in any request-driven process. The vocabulary changes; the structure does not.
- Not tied to one product. The pattern is a way to decide. Which capability you implement each layer with is a separate, later, and much easier question.
From a pattern to a plan
Here is the honest limitation of everything above: a pattern does not tell Miriam which of her forty-one ideas to fund, and it does not tell Jonas which one to open on Monday. It only tells them what to look for.
To get from the pattern to a decision you need evidence out of the actual instance — and that is a method, not a tool. Part 2 walks through the one we use: harvest, filter, score, visualise. Deliberately in that order, and deliberately in a form you can reproduce with reports and queries you already have, without any specialist tooling.
We will also be explicit about two things that are easy to get wrong: the difference between asking “which existing agent fits this?” and “could an agent be built for this?” — two questions that produce wildly different answers on the same instance — and when a number is a measurement versus a sample you are extrapolating from.
The series
| Part | Topic | Status |
|---|---|---|
| 01 | One flow, three layers — the pattern | You are here |
| 02 | Read the instance before you design the agent — harvest, filter, score, visualise | Read now |
| 03 | Layer 1 — deflect where the request is born, including a working build to import | Read now |
| 04 | Layer 2 — the gatekeeper you can build today | Read now |
| 05 | Layer 3 — specialists scoped to a category, not a team | Next week |
| 06 | Six things that bite you when you build this | Next week |
Tell us where we are wrong
This structure came out of a specific set of engagements, which means it carries the bias of those engagements. If your instance behaves differently, if a layer does not map onto your process, or if you have solved one of these layers in a way we have not considered — put it in the comments. We read them, we answer them, and we update the articles when someone shows us something better. Several of the sharpest points in this series came from exactly that.
If it is useful, share it. If you want to take the pattern into your own account conversations, take it — that is what it is for.
Views are our own and do not represent our team, employer, partners, or customers. Anything we build and share in this series is a demo-grade MVP — not a ServiceNow product, not part of any roadmap, and not supported.
