Stop guessing which process gets your first AI Agent

Every conversation I have with leadership around AI Agents hits the same wall within ten minutes: “Which use case do we actually start with?”

How do you actually decide?

Every AI Agent conversation I've had with a client this year hits the same wall inside about ten minutes. Someone says "we want AI Agents on the service desk," everyone nods, and then the room drifts into which use case to start with.

Nine times out of ten it lands on password resets. Not because the data says so. Because everybody in the room has reset their own password recently and remembers being annoyed by it.

That's not discovery. That's a hunch in a nice suit.

I've started running these engagements differently. Partly because I think it makes for a better program. Partly because I think we owe clients rigour before we owe them a demo.

Start with evidence, not opinion

Predictive Intelligence clustering has been sitting in the platform for years. Most shops that use it at all use it for incident-to-problem grouping, and then forget about it.

Right now, its best use is something else entirely: telling you, with actual numbers, which Case or Incident patterns are worth building an agent for.

The mechanics aren't complicated. Define a dataset against your Case table. Pick the text fields you care about (short_description, description). Add an encoded query to scope your window. Wrap that in a ClusteringSolution with a K-means config and a target coverage, submit it as a training job, and poll until it finishes.

What comes back is a ranked list. Concept label, quality score, size.

That output is the whole point. Instead of "everyone hates the password reset process," you get:

265 cases in six months. 99.97% cluster quality. Concept: unable to access team file share.

That's a business case. Both guesses might well be right — but now you know which one actually moves the needle, and you knew it before you spent a day building anything.

One practical note, learned the hard way: don't cluster on short_description alone. On Case records that field is usually thin. It's a portal form summary line, not the real story. Pull description in as well. Richer text means cleaner separation, and fewer clusters you end up throwing away because they're three different problems wearing one label.

Reference: Predictive Intelligence and the ML APIs (ServiceNow docs)

Not every cluster deserves an agent

A big part of the discipline is knowing what to leave out.

High volume plus quality in the high 90s is a strong candidate. The pattern is real and it's consistent. Low quality with a handful of records usually isn't a process problem at all — it's noise, or an intake form that lets people type whatever they like.

These days I put the excluded clusters in the report too, flagged as "needs intake cleanup," rather than quietly dropping them. Clients respond really well to seeing what you didn't recommend and why. It buys you a lot of credibility for the ones you did.

Build boring first

Once a cluster has been validated with an SME, the build should be unglamorous.

In AI Agent Studio I wire the resolution logic as native tools first. A Subflow or Flow Action doing the actual work — checking entitlement, granting access. No protocol layer. Nothing extra to govern.

The Orchestrator sequences those tools from natural language instructions instead of a hardcoded flow. That's the genuinely new muscle for architects: writing intent and guardrails rather than drawing a flowchart. It takes some getting used to.

Only when a tool needs to be shared — across agents, or with an external client like Copilot or Claude — do I reach for MCP Server Console. Every tool you publish through MCP is a tool you now have to govern, audit and version externally. Publish what needs publishing. Keep the rest native.

Reference: Action Fabric: MCP Server, MCP Client, and A2A explained

Governance isn't a bolt-on

Too many teams build the agent, get it working in a sandbox, and treat AI Control Tower as a checkbox on the way to go-live.

I'd much rather it were part of the design from day one. Every MCP connection sits in review until an AI Steward approves it. Role-based tool packages define exactly what each agent is allowed to touch. And if something goes sideways, you can pause a connection instantly and globally, no redeployment required.

That last point on its own is worth the conversation with any security team that's nervous about agentic AI. And right now, every one of them is.

Reference: AI Control Tower

What it looks like once it's live

Take the file share example all the way through.

An employee messages the portal saying they can't get into the team share. The case lands, the trigger fires, the Orchestrator checks entitlement, and if it's valid it grants access and closes the case. Seconds, rather than the fifteen to twenty minutes an L1 agent used to spend on it.

If entitlement fails — a contractor, say — the agent doesn't improvise. It hands off to a human, with the relevant KB article attached, because that guardrail was written into its instructions from the start.

Every tool call, resolved or handed off, logs through AI Gateway. That's your audit trail, and it's also your measurement loop. Baseline volume comes from the original cluster. Invocation and success counts come from Gateway afterwards.

Then re-run the clustering next quarter. Cluster shrinking? The agent is doing its job. New cluster appeared? There's your next backlog item, evidenced exactly the same way the first one was.

The sequence I've been using

Having something concrete to point to helps when a client asks "fine, what do we actually do on Monday." This is roughly how I run it. One way to structure it, not the only way:

Discover — cluster Case or Incident, rank by volume × quality.
Validate — sample per cluster, confirm the resolution pattern with SMEs.
Build — native tools first, in AI Agent Studio.
Publish, only if needed — move to MCP Server Console when reuse genuinely demands it.
Govern — register in AI Control Tower before production traffic, not after.
Connect and test — use the same sample cases you validated with.
Extend to A2A, only if needed — when the task really does require another system's own agent.
Measure and re-cluster — compare Gateway data against baseline, then cluster again next quarter.

I ran this exact sequence on a Case-table exercise recently. Entitlement-style access requests scored highest, which I'd say is a fair stand-in for what most CSM or ITSM shops will find once they look at their data instead of guessing at it.

Back to the original question

So, how do you decide which process gets the first AI Agent?

Not by whoever's loudest in the workshop. Cluster to find out what's actually there. Build native first and publish through MCP only when reuse demands it. Govern from day one. Measure against the same baseline you used to justify the build.

Discover, build, govern, measure, repeat. It's a more honest answer than a show of hands, and it's most of what separates an AI Agent programme from an AI Agent demo.

Curious whether others here are using clustering this way, or whether you've landed on a different discovery method that works. Happy to compare notes in the comments.

Further reading

Predictive Intelligence and the ML APIs — ServiceNow docs
Action Fabric: MCP Server, MCP Client, and A2A explained — Community article
AI Control Tower — product page
Enable MCP and A2A for your agentic workflows, with FAQs — Community article