The deciding move on most agentic AI projects happens before a single line of code is written. It happens in scoping. A scope that names the workflow, the owner, the data, the success metric and the failure mode in one document is half the engagement done. A scope that says "implement AI in our sales process" is the project we politely decline.
Eight questions, in this order, separate a project that ships from a project that stalls. We walk every prospective client through them in the first two meetings. The ones who can answer them get a build proposal. The ones who cannot get a discovery sprint first, because the answers do not yet exist.
1. Which single workflow are we rebuilding?
Not a function. Not a department. A workflow. Outbound to net new accounts. First-line support tickets. Quote generation for inbound RFQs. Invoice categorisation for accounts payable. The narrower the cut, the better the build. A workflow that fits on one page is a workflow that can be shipped in eight weeks. A workflow that takes a wiki is a workflow that needs to be broken down first.
2. Who owns the workflow today, and will they own it after?
Every workflow has a human owner. The Head of Sales for outbound, the Head of Support for tickets, the Finance Manager for invoices. That person is the agent's manager. They sign off on the prompt, the tools, the escalation rules, the dashboard. If the owner is unwilling or unavailable, the project is not ready, regardless of how clean the technology is.
3. What data does the agent need, and where does it live today?
Agents are read-write workers. They need the same inputs the human uses and they need to write back into the same systems the team works in. Before any build, list the data: product catalogue, account history, pricing rules, tone of voice. Then list where it lives: PIM, CRM, spreadsheet, someone's head. The gap between those two lists is the data work that will precede the agent.
4. What does done look like in the first 90 days?
A single number. Not three. "The agent handles 40 percent of inbound support tickets end to end, with under 5 percent customer-reported errors, by day 90." Or "The agent drafts every outbound sequence for the sales team, and reps approve 80 percent without edits, by day 60." One number that the owner agrees is worth the project. Everything in the build serves that number.
5. What is the failure mode we cannot accept?
Every agent is wrong sometimes. The question is which kinds of wrong are acceptable and which are not. A support agent sending a politely worded apology when escalation was needed: usually acceptable. A finance agent miscategorising an invoice into the wrong account: acceptable with review. A quote agent quoting 30 percent under cost: not acceptable, ever. Name the unacceptable failure modes up front. They become the guardrails.
6. What is the smallest useful version we can ship in week six?
Not week twelve, not week twenty. Week six. If there is no version that can be live in six weeks, the scope is too big. Pick a slice, ship it to a friendly subset of the workflow, measure it. The full rollout follows from the slice, not from a quarter of theoretical design.
7. Who reviews the agent in week one, and how do we move them backwards?
Day one, every agent decision should be reviewed by a human before it goes live. That is non-negotiable. The plan is to move the reviewer backwards over time, from approving every action, to spot-checking, to monthly audit, based on measured accuracy. Without a written plan for moving the human backwards, you have not built an agent. You have built a slow assistant.
8. What is the second workflow, and the third?
An agent that lives in isolation is a feature. A platform that ships the second workflow in half the time of the first, and the third in half the time of the second, is leverage. Scoping the first workflow without naming the next two is a mistake. The data layer, the eval harness, the deployment pattern all compound across workflows. Build the first one with the second in mind.
“Scoping is where projects ship or die. By the time we are writing code, the hard decisions are already made.”
- Derk Disselhoff
What good scoping produces
A two-page document. One workflow, one owner, named data sources, one success metric, named failure modes, a week-six slice, a reviewer plan, the next two workflows. Signed by the workflow owner and the founder. That document is the contract for the build. Everything in the eight weeks that follow can be traced back to a line in it.
What bad scoping produces
A deck. "Implement AI across the sales organisation." Five workstreams. Three vendors. A steering committee. Nine months later there is a pilot in a corner that nobody uses, the budget is spent, and the team has decided AI does not work for them. The technology is fine. The scoping was the failure.
The invitation
If you have a workflow and you can answer six of these eight questions, we can probably build it. If you can answer all eight, the build is the easy part. If you can answer two of them, we should run a two-week discovery first, before either of us commits to anything. Either route gets you a working agent. The wrong route gets you a stalled one.
