We tell people that after a 30-minute call, if there's a fit, they get a scoped agent plan within 48 hours.
That's an easy thing to say and a slightly suspicious one to hear. Two days is either impressively fast or a sign the document is a template with a logo on it.
So here's what's actually in it, section by section, and why 48 hours is the right amount of time rather than a sales number.
1. The workflow, written down properly
One workflow. Named, bounded, described as a loop: what triggers it, what arrives, what decisions get made, what the output is, where it lands, and what happens when it goes wrong today.
This section is often the most immediately useful part of the document, and clients tell us so — not because we're good at writing, but because in most businesses nobody has ever written this down. It exists in someone's head, and the version in their head skips the exceptions.
It also names the frequency. How many times a week does this actually run? That single number decides whether the project is worth doing, and it's the number most often guessed wrong in the initial call. We'd rather correct it on day two than month four.
2. The eval set — its shape, and where it comes from
Not the eval set itself. Building that properly takes about a week and involves your artefacts and your expert's time.
What the plan specifies is where it comes from: which hundred historical cases we'd pull, who's the expert we'd sit with, roughly which clusters we expect the data to fall into, and what the assertions look like for the most common one. Enough that you can see the method concretely rather than take "we do evals" on trust.
If your workflow leaves no artefacts — no sent messages, no closed tickets, no record of what was decided — that's flagged here as the first risk, because it means the first phase of work is instrumentation, not AI. Better to know on day two.
3. The autonomy level, per step
The ladder, applied to your specific workflow, step by step.
This step at level 2 — drafted, held for approval. This one at level 3 once the approval rate holds, with these criteria. This one stays human permanently, and here's why.
Along with it: who approves, where the queue lives, and what the kill switch does at each level.
This is usually the section that generates the most discussion internally at the client, which is the point. It converts an unbounded anxiety into a set of specific decisions that people with authority can actually make.
4. The integration surface
Where the agent lives. Which systems it reads, which it writes to, what the authentication story is, and — critically — whether those systems have usable interfaces.
Frequently this is where the real timeline hides. The model work is often the predictable part; getting reliable access to the system of record is what moves a six-week estimate to ten. If your CRM has no API and the data lives in a shared spreadsheet, the plan says so plainly, with what it costs.
5. The one number
The metric that would justify the work, agreed as a single number, with how we'd baseline it before go-live.
Not a dashboard. One number, chosen by whoever controls the budget. Response time, hours returned to the team, conversion on inbound, filings submitted before deadline — whatever the real business cares about.
If we can't identify one, that's a finding, and it goes at the top of the document rather than being quietly omitted.
6. Phases, with a decision point after the first
Typically three: instrument and measure, run at level 2, then selectively raise autonomy where the numbers support it. Each with a duration, a cost, and what exists at the end.
The first phase always ends in a genuine go/no-go, with the criteria written in advance. A plan where every phase assumes the next one happens isn't a plan, it's a proposal wearing one.
7. Why this might not be worth building
Every plan has this section, and it's not boilerplate.
Sometimes the honest content is: this workflow runs eleven times a month, the agent saves twenty minutes each time, and the integration work is six weeks — the arithmetic doesn't work, here's a different workflow in your business that does. Sometimes it's: the judgment in this process is the whole job, and automating the assembly around it saves you less than you'd hope. Sometimes it's: your data isn't in a state where this is possible yet, and here's the smaller piece of work that would change that.
We write it because the alternative — discovering it in month three — is worse for everyone, and expensive for us. A project that shouldn't have started is not a project we want.
Why 48 hours works
Because the plan is mostly your information, organised — and the 30-minute call plus one follow-up gets us most of it. What we're adding is pattern recognition: which parts of what you described are the risky ones, which are routine, where similar workflows have gone wrong before.
That's a two-day job. Stretching it to three weeks wouldn't make it more accurate. It would make it look more expensive, which is a different objective.
What it deliberately isn't: an estimate to three decimal places, a technical architecture, or a commitment to a stack. Those come after phase one, when there's an eval set and real data about how the workflow actually behaves. A detailed architecture written before you've seen a hundred real inputs is fiction with diagrams.
That's the series. If you have a workflow that looks like the ones we've been describing — book the 30 minutes and we'll send you the plan.