Choosing Your First Use Case

How to pick the use case that should go first, using your ratings, reports, and execution patterns.

The platform ranks your use cases. This page is about the judgement the ranking cannot make for you.

The Outcome

One use case is selected to build, and you can defend why it went first.

Before You Start

You need a populated Jamming Board - either from a discovery run or from use cases you added manually.

If you ran the full assessment, have the Revised Priority Use Cases and AWS Fit Feasibility reports open alongside.

Start Here

Look at the use case carrying the Best Fit badge. That is the platform's answer, derived from your team's star ratings and sentiment analysis of the comments.

Then deliberately try to argue against it using the three tests below. If it survives, build it.

The Three Tests

1. Can you tell when it worked?

If you cannot state the success measure in one sentence before you build, you will not be able to prove value afterwards. "Reduce time to resolve a claim from 4 days to 1" is a measure. "Improve customer experience" is not.

2. Is the process actually agentic?

Run the use case past Agentic Process Transformation. If the work underneath is fully rule-based, APT will propose Deterministic - and conventional automation will beat an agent on cost, latency, and predictability. A first use case that a workflow engine could have solved undermines the case for everything after it.

The strongest first candidates land on Agent as Tool: a fixed process path with one bounded step that needs judgement.

3. Does the data already exist?

Agents reason over what you give them. If the knowledge base has to be built from scratch, the build is a data project wearing an AI costume, and the timeline is longer than it looks. Check what the Gap Mitigation Plan said about data readiness.

When Value and Feasibility Disagree

This is the common case, and the ranking will not resolve it.

The highest-value use case is frequently the least feasible - it touches the most systems, the most regulated data, and the most stakeholders. The highest-feasibility one is often unglamorous.

Take the feasible one first. A shipped, boring agent earns you the organizational credit to attempt the ambitious one. An ambitious first attempt that stalls in integration review costs you that credit instead.

The exception is when the ambitious use case is the only one anyone senior cares about. Then the boring win buys you nothing politically, and you should go straight at the real target with the gaps explicitly acknowledged.

What Good Looks Like

  • One use case selected, with a named owner
  • A success measure written down before the build starts
  • Its APT execution pattern is Agent as Tool or Other - not Deterministic
  • You know which data it depends on, and that data exists today

Where This Leads

With a use case chosen, move into Align and get the foundations right before designing agents: