The fastest way to waste an AI discovery session is to walk in talking about models. The conversation turns to capabilities, tools, and what is technically possible — and an hour later everyone is energized and no one is closer to a project worth building. The session felt productive. It produced nothing.
The teams that get the most out of discovery do the opposite. They arrive with the work, not the technology. They know which workflows are slow, which data is scattered, and which constraints will shape any solution — and they let those facts drive the conversation. The lesson: discovery is not where you decide to use AI. It is where you decide what is actually worth automating, and the quality of that decision is set entirely by what you bring into the room.
Start with the work, not the model
The most common opening line in a weak discovery session is some version of "we want to use AI." It sounds like a starting point. It is actually a dead end, because it describes a means, not a problem. AI applied to a workflow that isn't broken produces an expensive demo. AI applied to a workflow that quietly costs your team hours every week produces an asset.
So the preparation that matters most happens before any call: write down where the work actually slows down. The questions people ask over and over. The reports that take half a day to assemble. The data that lives across too many systems. The decisions that require a manual lookup every time. The customer or internal requests that need routing before anyone can act on them.
Each of these is a candidate worth more than any model name, because each describes a cost you are already paying. Discovery's job is to find the few candidates where automation would pay that cost back fastest — and it can only do that if the candidates are on the table.
"We want to use AI" is not a starting point. "This workflow costs us six hours a week" is. Discovery works with problems, not ambitions.
What this means for you: Before the session, list five places where work repeatedly stalls. If you cannot name five, that itself is the finding — and worth surfacing before anyone designs a build.
Map the systems before you map the solution
Once you know which workflows are worth examining, the next preparation is to list the systems each one touches. Not in architectural detail — a rough inventory is enough. CRM, ERP, databases, spreadsheets, email, Slack, Drive, Notion, SharePoint, the internal tool nobody documented. For each candidate workflow, what would an agent need to read, write, or trigger to do the job?
This matters because the systems are where most AI projects actually succeed or fail. The model is rarely the hard part. The hard part is reliable, permissioned access to the data the agent needs, kept fresh enough to be trusted. A workflow that looks simple on a whiteboard can be genuinely difficult if the data it depends on lives in three systems that don't talk to each other — and a workflow that sounds ambitious can be straightforward if everything it needs sits in one well-maintained CRM.
You do not need a perfect diagram. You need enough of a map that the discovery conversation can distinguish "this is a clean two-system integration" from "this touches six systems and one of them is a legacy database no one wants to open." That distinction changes the project's cost, timeline, and risk far more than the choice of model ever will.
The model is rarely the hard part of an AI project. Reliable, permissioned, current access to the right data almost always is.
What this means for you: For each workflow you bring, sketch the systems involved and flag the one you expect to be hardest to access. The flag is often where the real scope of the project hides.
Bring constraints early — they are the most useful thing in the room
There is a temptation to keep constraints out of an early conversation, as if naming the limits will make the project smaller. The opposite is true. Constraints are the single most valuable input to discovery, because they prevent the wrong project from moving forward before it has cost anything.
Bring everything that genuinely shapes what is possible: permission rules, sensitive-data requirements, compliance concerns, approval steps, systems that are hard to access, teams whose sign-off is mandatory. None of these is an obstacle to good discovery. Each is information that turns a vague ambition into a buildable architecture. A constraint named in discovery becomes a design decision. The same constraint discovered mid-build becomes a surprise — and surprises in production are expensive.
Good discovery does not route around constraints. It turns them into the shape of the solution. An approval step is not a blocker; it is a place the agent hands off to a human. A sensitive-data rule is not a wall; it is the boundary the access layer is built to respect. The constraints you bring early are what make the resulting design real rather than aspirational.
A constraint named in discovery becomes a design decision. The same constraint discovered mid-build becomes an expensive surprise.
What this means for you: Treat your constraints as assets, not admissions. The compliance rule or permission boundary you are tempted to leave unsaid is exactly the input that keeps the project honest.
Define what "better" would actually look like
The final piece of preparation is the one most often skipped: deciding, in advance, what success would mean. The goal of a discovery session is never to "add AI." It is to make a specific workflow measurably better — and "measurably" is the operative word.
Useful success signals are concrete and observable: time saved per week, faster response times, fewer manual handoffs, higher answer quality, fewer escalations, clearer operational visibility into work that is currently opaque. The value of naming these before the session is that they turn a build into something you can later confirm or disprove. A project with a defined before-and-after can be evaluated. A project defined only as "use AI here" can only be argued about.
If you can describe the current state and the state you want, discovery has everything it needs to turn that gap into a practical build plan. If you cannot, the most valuable outcome of the session may be discovering that — because a workflow whose improvement you cannot describe is usually a workflow that is not yet ready to automate.
What this means for you: For each candidate workflow, write one sentence of "before" and one of "after." If the "after" is hard to make concrete, that is a signal to refine the problem before building anything.
Early actions
The difference between a discovery session that produces a real plan and one that produces enthusiasm comes down to what you prepare. Three things to do before the call:
- Bring problems, not a wish for AI. Walk in with five workflows that demonstrably cost time, not with a desire to use the technology. The problems are what discovery can act on; the ambition is not.
- Map systems and flag the hard one. For each workflow, list what an agent must read, write, or trigger — and mark the system you expect to fight with. That flag usually predicts the real scope.
- Write the before-and-after. Define, in one sentence each, the current cost and the target outcome. A workflow you can measure is a workflow discovery can turn into a build.
A discovery session does not start with the model. It starts with the work your team repeats every week, the systems that work depends on, the constraints that shape it, and a clear picture of what better would look like. Bring those four things, and the conversation about which model to use becomes the easy part — which is exactly where it belongs.