- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago
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.
← 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.
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.
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.
