What the blueprint actually asks
Scoping is not a discovery call in disguise. It is four inputs, and each one exists because it changes what gets built:
- Who you are and how big the team is. An agency reselling agents, a solo founder, a B2B team, and an enterprise with a security review want different things from the same workflow. Team size changes who has to be able to operate the agent afterwards.
- Which task eats the most time. Lead follow-up, inbox triage, data entry, research, reporting, scheduling, or support. Picking the single most expensive repetitive task is the whole trick — a first agent that owns one task beats a plan that covers six.
- How many hours a week it consumes. Not to sell you anything: it is the baseline. Without a number recorded before the build, "it saved us time" is an opinion.
- How many systems the task touches. One or two tools is a single-agent job. Six or more means orchestration, handoffs, and shared state, which is a different architecture and a different timeline.
There is a fifth question the form cannot ask well, and it matters more than any of the above: what should the agent do when it is not sure? Stop, escalate to a named person, or act anyway. Teams that have not answered it end up with an agent that escalates everything, which is useless, or guesses at everything, which is dangerous.
What you get back
The wizard returns four things immediately, on screen, without an email gate on the result:
- A framework call with the reasoning attached. Hermes for a single agent that benefits from persistent memory, OpenClaw when the work hands off across tools, or a custom build when the answers point at audit trails, role-based access, or six-plus systems. Thefull framework comparison shows the same decision in long form if you want to check the recommendation against the alternatives.
- The first workflow, named. The specific task the first agent would own, with the hours you reported attached to it as the baseline to measure against.
- An estimate of the hours the workflow could return, derived from the figure you entered. It is arithmetic on your own input, not a measured result from another client — we have no client-side outcome data and will not present one as if we did.
- The next three steps: we review and validate the scope, build a proof-of-concept on your real workflow rather than a demo, then you measure and decide. No retainer starts any of that.
The blueprint is deliberately not an architecture document. It is the decision that has to be right before an architecture document is worth writing: which single workflow goes first.
What a good scope looks like — and what it does not
"Automate our sales process" is not a scope. "Score inbound demo requests against these five criteria, enrich them from the CRM, and route anything above the bar to the owning rep" is. The difference is that the second version names the trigger, the judgement, the systems, and the output, which means it can be built, tested, and argued with.
A scope this tight is also what keeps the calendar honest. A first agent on one well-defined workflow runs on real work within days; the one to three weeks that follow go into memory, fallback models, guardrails, logging, and real credentials —the timeline breakdown is here, and it is the part most proposals leave out. If the scoping exercise ends with more than one workflow, the honest move is to build the first one and re-scope after it has been running for a fortnight, the waya single automated business processusually expands.
Scoping also has to be allowed to conclude "do not build this". If every step in the workflow is deterministic, an automation platform is the better tool. If the work is a customer conversation on a channel a vendor already supports, compare theno-code AI agent platforms first — being live next week on a subscription beats a build you would outgrow in the wrong direction. And if nobody can yet describe the steps a human takes today, that write-up is the work, and it is free to do internally.