I've watched smart teams burn six weeks building an agentic use case that worked perfectly. Sadly, it solved a problem nobody actually had.
It's a quiet kind of failure. Nothing blows up. The demo works. The stakeholders nod. And then, somewhere around week three, the cracks show: the problem the business thought it had and the one the data and the workflow actually point to turn out to be two different things.
So, I want to share what I've learned from the Forward Deployed Engineering group, about how to pick agentic use cases that earn their place, and how to set them up to grow. The difference between a program that scales and a pile of orphaned demos usually isn't the tech — it's which use case you pick and who backs it. That's what this is about. First in what I hope becomes an ongoing series — let's get into it.
Good vs. great: what separates the two
You will often come across lists of agentic “use case criteria” for a Domain or Industry. High volume, repetitive, human-toil, well-bounded. That's the floor. It tells you what's not a terrible idea. It doesn't tell you what's going to matter.
When I look at a candidate use case now, I'm looking for three things. Not all three need to be present, but the more there are, the more confident I am.
1. Does it compound?
A good agent saves you time once. A great agent creates something tangible: data, a pattern, a workflow shape, a trust relationship that makes the next agent easier to build.
Think about an agent that triages incoming requests. On its own, it saves the team some hours. But it's also quietly producing a labeled dataset of "what kinds of requests do we actually get, and how do they get resolved?" That dataset becomes the foundation for the next agent. And the one after that. It should be a strategic pursuit.
Most customers, depending on their AI fluency and data maturity, default to the use case in front of them, on the workflow they already know, with the data they already have. That instinct isn't wrong, but it's rarely where compounding lives. The shortest path forward isn't always the right one — and a good partner says so, even when the customer doesn't want to hear it.
Going after the right anchor usually requires table-topping every scenario across the process or workflow to identify the natural points where one agent's output becomes the next one's input. The art is harder: convincing senior stakeholders that an immediate high-value outcome is a multi-step pursuit, not a "right now." Going slow at the start is how you go fast long-term.
On the flip side, if a use case is a one-off clever automation with no downstream, it can still be worth building for a tactical win. Just be honest about which one you’re building.
2. Does it sit in the workflow, or at the edge?
Some agents are decorative. They live in a sidebar. People can use them or not, and the business runs the same either way.
Other agents sit in the workflow, the request can't move forward without the agent doing its part. These are the ones that change the operating model. They're also the ones that need real governance, real change management, and a sponsor who's willing to lean in. Edge agents are safer to ship. Central agents are harder to build but transform the business. The trick is being honest with yourself, and with your sponsor, about which kind you're building.
3. Does it help humans do more of what humans are good at?
The agentic use cases I've seen land best aren't the ones that try to replace someone. They're the ones that take the part of the job nobody enjoys: the cross-system lookup, the policy check, the formatting, the chase-down, orchestrating different systems, and hand the human back a cleaner, higher-leverage decision.
The framing matters. Same agent, often. Different story.
Some customers have explicit goals to go fully autonomous on certain processes depending on their maturity. Assistive is the near-term path, and the trust built there is what makes fuller autonomy possible later.
Table stakes
Before you fall in love with a use case, check the floor. An agent that summarizes resolution notes across past incidents is a great idea — if your resolution notes contain more than "fixed." Garbage in, eloquent garbage out.
So before identification, do a quick honesty check on the use case:
- Does the data the agent needs exist, in a place the agent can reach?
- Is there a system of record, or three competing ones?
- Is the workflow stable enough that an agent built today still applies in six months?
If any of those are no, you don't necessarily have to walk away. But you do have to add them to the scope and tell the sponsor.
Sponsorship: pick someone who'll lean in
Here's where a lot of agentic projects quietly die. The use case is fine. The build is fine. But there's no one with enough altitude, and enough stake, to push it across the finish line.
A sponsor isn't a name on a slide. A sponsor is someone who:
- Unblocks. When the process owner won't make time, when the data access request is sitting in someone's queue, when legal has questions, the sponsor is our “go-to”.
- Fosters. They tell the rest of the org that this matters. They put it on agendas. They take the work seriously enough that the team doing the work does too.
- Leans in when it gets rough. And it will get rough. The first model output is going to embarrass somebody. The first pilot is going to surface a process problem that's been hiding for years. A good sponsor doesn't disappear in those moments, they show up harder.
The sponsor can be from the business side or the technology side. What matters is decision-making authority and willingness. A passionate champion three levels down from the budget is not a sponsor, they're an advocate, which is valuable, but different.
And here's the part that's almost always underestimated. Most organizations move slower on the ground than their leadership realizes. Governance reviews, skill gaps, internal handoffs, bureaucracy — none of it shows up on the leadership dashboard, but all of it shows up in the project plan. Meanwhile, leadership is on the hook to deliver fast, visible results with AI. That gap between the floor and the leadership is real, and it's where momentum dies. Without an accountable sponsor actively monitoring it, escalating when needed, and driving through the friction, a two-month AI project quietly becomes a six-month one.
If you find yourself in a kickoff and the person across the table can't tell you who will sign off when the work gets hard, raise the flag before you write a single line of code.
Scaling: start with one, expand from value
The instinct, when a team gets excited about agents, is to build a portfolio. Five use cases. Ten. A roadmap with swim lanes. I've come to believe this is almost always a mistake.
Start with one. That is your lighthouse. Get it right. Let value pull the next one.
What does "value" mean here? It is the definition of SMART: specific, measurable, relevant, and time-bound. Most of the time it's hours saved, and that's fine — hours saved is real, it's defensible, and finance understands it. But the strongest signal isn't on the scorecard. It's when the business owner asks you, unprompted, "what's the next one?"
That's the moment you've earned the right to scale.
A note of caution, though. When you do go to the second use case, resist the urge to copy-paste the first one's design. Each agentic build has its own shape — its own data dependencies, its own human-in-the-loop requirements, its own decision surface. The discipline of starting from scratch each time, while reusing the lessons rather than the artifacts, is what separates a program from a pile of demos.
On the platform side, this is where things like the AI Control Tower start to earn their place — giving you one view across multiple agents as your portfolio grows. But the technology is downstream of the discipline. Don't let a nice dashboard substitute for the harder work of understanding why each agent exists.
So, what would I do differently, knowing what I know now?
One: I'd spend more of the first week listening, not architecting. The use case that walks in the door is almost never the use case that ships, and the customer's default use case is rarely the path that compounds.
Two: I'd pick the sponsor before I picked the use case. With the right sponsor, an okay use case becomes a great one. With the wrong sponsor, even a great use case quietly dies.
Three: I'd resist the portfolio instinct. One agent, done well, opens more doors than five agents stuck in pilot.
