The Touchless Enterprise · Part 5 of 6

Scoped to a category, not a team.

Layer 3 is where the pattern gets specific — and where the org chart stops being the right boundary.

By Timo Weber (Senior AI Solution Architect) and Thomas Geering (AI Architect), ServiceNow EMEA

← Part 4: Layer 2 — The Gatekeeper You Can Build Today

Part 4 ended on one sentence we left dangling on purpose: a record leaving Layer 2 has a category that means something, and that category is the trigger a specialist agent can be built against. Without it, every Layer 3 agent has to re-derive what kind of work it is looking at.

This part is about that specialist. Not how you build one — that is a separate, much longer conversation, and every category answers it differently. This is about what actually defines a vertical agent, why the boundary most organisations draw around it is the wrong one, and how you decide which category gets built first when you cannot build all of them at once.

What defines a vertical agent

Once a category is set, resolution belongs to a specialist with the access, knowledge and process logic that category requires. Three properties decide whether something that calls itself a vertical agent actually is one.

Scoped to a category, not a team

A single fulfilment group can own a category on the org chart while the requests that belong to it cluster into a dozen or more distinct intents spread across two or three different departments. The agent has to follow the work, not the reporting line — a build scoped to “whoever currently receives the ticket” only ever covers the slice that happens to route there today.

Acts, doesn’t advise

In role-and-access clusters we keep seeing the same split: the agent can compose a clean, complete record — correct fields, correct approver, correct justification — but it cannot execute the underlying provisioning step itself. Those cases correctly stay assisted, not autonomous. That is not a failed build. It is the test doing its job.

Escalates with the work done

A handful of clusters in every instance we have looked at map to no existing agent capability at all. Those requests still have to land somewhere — with the category attached and whatever was already tried and found, so a human never starts from a blank page.

The capability, not the concept, is what’s missing

Run a matching exercise against a real instance — every cluster you have identified, checked against every agent capability you actually have available — and the ratio is sobering. Only a small fraction of what gets evaluated maps to something that closes the loop today. That gap is not a reason to wait. It is the actual shape of the backlog, and it is a data question, not an opinion.

Why the org chart is the wrong boundary

The instinct, once Layer 2 hands over a category, is to route it to whoever already owns that category on paper and call the fulfilment group’s existing tooling “the agent.” That instinct is where most vertical agent programmes quietly narrow themselves before they have built anything.

Take access and identity work as an example, because the pattern repeats almost everywhere we look. On the org chart it is one group’s job. In the actual request data it is a dozen or more distinct intents — new joiner provisioning, role changes, temporary elevation, offboarding, access review follow-ups — and those intents do not stay inside one department. A change to someone’s role touches IT and HR in the same request. Scope the agent to the team and you have automated the fraction of that work which happens to land on one desk. Scope it to the category and you have automated the actual topic, wherever it enters and whichever system has to move.

This is the same argument Part 1 made about escalation: the boundary that survives a governance review is the one drawn around the work, not around who currently does it. A category is a contract — one category, one downstream action, auditable and changeable without retraining anything. A team is an org chart, and org charts change for reasons that have nothing to do with the work.

Which category to build for first

Part 2 left this as a placeholder: Layer 3 rolls out in waves, starting with whatever your Home Run quadrant actually contains. That answers the sequencing question at the level of the whole backlog. Inside the Home Run quadrant itself, four further signals decide which category goes first — and they are worth checking in this order, because each one can disqualify a candidate the previous one waved through.

Signal	Good first candidate	Push to a later wave
Volume shape	A few hundred records a month, concentrated in one recognisable pattern	High total volume, but scattered across many unrelated intents with nothing in common but the category label
Automation-readiness	The resolution path is a known, repeatable sequence of actions the platform can actually execute	Resolution depends on a judgement call, or on a system with no automatable interface at all
Containment	Everything the agent needs to act — data, permissions, workflow — lives in one system of record	Resolution means stepping across several systems of record with no single owner between them
Existing coverage	An existing agent, skill or tool already matches most of the pattern — you are extending, not starting from nothing	Nothing currently matches. The category is real, but the build starts from zero

None of these four is disqualifying on its own — a category can fail containment and still be worth building if the volume and the readiness are strong enough to justify the extra integration work. What they rule out, together, is the category that sounds important in a workshop and fails on all four at once. That candidate belongs on a roadmap, not in the first wave.

If you want the accelerated version

The matching exercise behind the ratio above — every cluster, checked against every capability you actually have — is exactly what AI Agent Advisor in Now Assist Center automates. It runs against your own instance data, matches clusters to available out-of-the-box tools and existing agents, and returns a scored backlog you can act on directly, refreshing automatically on a schedule. You can run a version of this by hand, the same way you can run Part 2’s method by hand — cluster by cluster, checked against whatever you actually have deployed. What the product buys you is scale and consistency: matching every cluster against every capability, on a fixed schedule, is exactly the comparison that degrades fastest when it is done by hand across a large taxonomy. Use it if you have it. Product documentation.

Figure 1. The three tests, not our numbers. Each one gets checked against your own matching exercise.

Where this hands over

Everything in this series so far holds up on a whiteboard. Three layers, a category as a contract, a specialist that acts instead of advising. None of that is controversial once you have seen it written down.

Part 6 is the reality check: six things that bite you once a layer has been live for a while. Some of them are exactly the rules above, quietly ignored six months after launch. The rest we only found out about by getting them wrong first.

 

The series

Part	Topic	Status
01	One flow, three layers — the pattern	Read now
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	You are here
06	Six things that bite you when you build this	Coming next

 

Tell us where we are wrong

One thing in particular: the “acts, doesn’t advise” test. We treat an agent that drafts a clean record but cannot execute the underlying action as correctly assisted rather than as a failed vertical build. If you have a category where that line sits somewhere else — where advising is genuinely the right end state, not a stepping stone — tell us in the comments. That is the argument in this part we are least sure of.

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.

← Previous: Part 4Next: Part 6 → publishing soon

© 2026 ServiceNow, Inc. All rights reserved.