What Does an AI Consultant Do in Week One? Deliver a Brief You Keep, Not a Demo

What should an AI consultant hand you in week one?

A competent AI engagement produces a written architecture brief before it writes any code, and that brief belongs to you even if the engagement ends on day five. It is also the deliverable most engagements never produce: what arrives instead is a working prototype, a strategy deck, or a shortlist of vendors, and none of those tell you what to do next month.

The brief comes first for a reason that is financial rather than procedural. A brief is the only artifact that can be finished before the facts become expensive. Where the bottleneck actually is, what systems the work has to touch, what a wrong output costs, what should never be automated, and what observation would make you stop — all of that can be written from observation, interviews, and counts you already have in your ticketing or ERP system. None of it requires a model running in production, so none of it requires you to fund a build before you have a reason.

The first deliverable of a competent AI engagement is a written architecture brief, produced before any code is written, that the client keeps whether or not the engagement continues.

That sentence is the whole test. A consultant who cannot produce it either has not understood your operation, or has understood it and would rather you not see the whole picture written down in one place.

Why is a prototype a worse first deliverable than a document?

Because a prototype answers a question you were not asking. It demonstrates that a model can produce plausible output on the cases that were selected for demonstration. It does not tell you whether your process is stable enough to build on, and those are different questions with very different failure modes.

There are four mechanisms I see repeatedly.

A demo decides nothing. Once there is something to look at, the review conversation becomes "does this look right?" instead of "is this the right process to change, and what is it worth?". Aesthetic approval is easy to give and carries no information.

It transfers nothing. A prototype is an artifact, not a specification. If your own engineer has to reverse-engineer its behaviour to maintain it, you have bought a dependency rather than knowledge. The brief is the opposite: it is written to be handed to someone who has never met the author.

It hides the parts that will cost you money. Demos are typically run on clean inputs. The integration surface, the intake repair, the review queue, and the per-run cost are exactly what a demo omits and exactly what decides whether the system survives contact with your actual volume.

It removes your stop condition. A document can conclude "do not build this yet, fix the data model first". A prototype that already exists creates pressure to continue, because stopping now means writing off what was spent.

What has to be inside the brief for it to be worth paying for?

This is the part I would hold a consultant to. Eight sections, none of them long, and each one answerable in language your operations lead can check against what they see on a Tuesday.

Four to eight pages is the honest length. If the document is forty pages, it is a sales instrument with appendices, and the parts that matter are buried somewhere in the middle where nobody will find them.

The cost of producing it is small and should be quoted as a small fixed number, not as a day rate. In my own practice the first paid step is a scoped de-risking sprint that starts at $200, and that floor is published rather than negotiated. The reason for pricing it that way is that I would rather you compare a small fixed figure against the monthly cost of the process you are trying to fix than against someone else's hourly rate. Substitute your own baseline: the touch time on the process, multiplied by what that time costs you, is the only comparison that means anything.

How do you tell a real brief from a repackaged sales document?

Run these tests on whatever you are handed. They take twenty minutes and they are hard to pass dishonestly.

The third row is the one that separates the two categories most reliably. A consultant who has genuinely looked at your operation will tell you which part of it should stay manual, and will say so in writing, because that judgement is the thing you are paying for. A consultant selling a build cannot afford that sentence.

What does a demo-first start cost you that the invoice does not show?

The invoice for the demo is rarely the expensive part. Three costs arrive later, and none of them appear in a project plan.

The first is the decision you still cannot make. You now have a prototype and no answer to whether the process underneath it is worth changing, so the next quarter is spent extending the demo rather than deciding, and the extension has no natural endpoint because there is no baseline to beat.

The second is the review labour nobody booked. A demo without a labelled evaluation set turns your analysts into an informal grading committee, and their verdicts drift, because there is no agreed definition of correct. I have watched a team spend an afternoon a week for two months arguing about output quality on a system that had no owner and no score.

The third is that discovery gets bought twice. The next consultant repeats the process interviews the first one already did, because the first one's notes were a slide deck rather than a specification.

I will not put a percentage on how often AI pilots fail, because the figures that circulate are not reproducible across process types and I have not seen a method I would defend. What I will say is that the diagnostic is cheap relative to a quarter of engineering time, and that a written brief is the cheapest artifact in the whole sequence. Spending two thousand to avoid spending two hundred thousand is not a sophisticated argument; it is just the correct order of operations.

What does the brief let you do next?

Three things, and only one of them involves the consultant who wrote it.

You can fund a build, because the brief fixes the scope tightly enough to be quoted as a fixed price instead of an estimate. You can hand it to your own engineers and build it in-house, which costs the consultant the build phase and is the reason some will not write it. Or you can take it to a different firm entirely, which is a legitimate move and the reason the brief has to be written so that it stands alone. The willingness to be replaced by your own document is the difference between a brief-first engagement with a fixed-scope build phase and a written handover and a retainer with better typography.

A build phase that follows a real brief has a shape: two to ten weeks, one written scope, working software every week, and a handover that includes a decisions log and runbooks so the reasoning survives staff turnover. If a proposal cannot be written in that shape, the missing ingredient is almost always the brief.

What should be true ten days from now?

You should be holding four to eight pages that name your bottleneck with your numbers, state what must not be automated, and carry a kill condition you agreed to before anyone wrote code. Your operations lead should be able to read it without a translator. Your engineer should be able to build from it without a call. If instead you are being shown a prototype, the honest reading is that you are being sold a process rather than a system, and the question to ask in the next meeting is short: what will I be holding at the end of week one, and do I keep it if I stop? The answer separates the two kinds of consultant faster than any reference check.