What a Real AI Engagement Looks Like, Week by Week

What you should be able to hold at the end

Ask ten vendors what an AI engagement looks like and you will get ten descriptions of a process: discovery, then design, then build, iterating with the client throughout. Every one of those words is unfalsifiable. You cannot tell at week three whether discovery happened.

So the useful question is not what the process is. It is what will exist, on paper, at the end of each week — because a written artefact is the only thing you can hold a vendor to, and the only thing that survives the engagement itself.

A real AI engagement produces four artefacts in a fixed order, and the first one is written before any code exists: a brief that states the bottleneck, the decision rule, the system's shape, and what it must not do.

Why the brief comes first and why you keep it

The first deliverable is a short document. Not a proposal, not a statement of work — a diagnosis. It should answer five things:

1. The bottleneck, in your language. Not "manual data entry is slow" but "every invoice over ten thousand yuan waits for a controller signature, and there are four hundred of them a month."
2. The decision rule, stated out loud. If the process is a judgement, what is the judgement? If nobody can say it, that is the finding, and it is a valuable one.
3. The shape of the system. Where the model sits, where deterministic code sits, and where a human sits.
4. The failure path. What happens when the system cannot decide or is wrong. This is the section vendors skip and the one regulators ask about.
5. What the system must not do, and the bill of materials — what data, what access, what people's time.

A brief like that takes three to ten days and it is the highest-leverage thing in the whole engagement. It is also the cheapest way to discover the project should not proceed, which is why it should come before commitments rather than after.

Two things follow from it. First, you keep it regardless of what happens next. An engagement where you pay for the diagnosis and stop is a legitimate and often correct outcome; a vendor whose commercial model punishes that outcome is not selling you a diagnosis. Second, it converts the rest of the conversation from opinion to reference. "The brief says the failure path is X" is a sentence that ends arguments.

This is what the first paid step in my own practice is: a small, fixed-price de-risking sprint whose output is that document. It is published as part of the engagement model, including the four kinds of work I decline, because a boundary stated in advance is worth more to you than one discovered on a call.

Artefact two: working software every week, not at the end

Once the brief is agreed, the build proceeds in short cycles, and the artefact at the end of each one is something running against real data in a real environment. Not a slide, not a Figma prototype, not a demo video.

Why this specific artefact matters: the failure modes of an AI workflow are invisible until it meets the actual distribution. A document-extraction pipeline is 96% accurate on the sample someone assembled and 71% accurate on the invoices that arrive on the last day of the quarter. You cannot find that in a design document. You find it in week two, on your data, and the finding changes what you build in week three.

The practical test at each checkpoint is therefore not "does this match the plan" but "what did we learn from real data this week, and what did it change". An engagement where nothing changed after contact with real data is an engagement where nobody was looking at real data.

Artefact three: a written decisions log

Every non-obvious choice gets one line: what was decided, what the alternative was, why this one won. Late in the project and after it, this is the only defence against re-litigating settled questions and the only way a new engineer can be useful quickly.

It also has a specific diagnostic value for you as the buyer. A log with twelve entries by week six is a project where someone was thinking. A log with three generic entries is a project where the interesting decisions were made by default, which usually means they were made by whoever wrote code first.

Artefact four: a handover that does not require the author

The end state is not "it works". It is "your team can run, monitor, and modify it". That means runbooks, the failure taxonomy, the evaluation set, and a recorded walkthrough — plus the honest version of what is fragile.

The evaluation set deserves its own mention, because it is the artefact most often missing and the one that determines what happens over the next two years. It is a set of archived real cases with known-good outcomes, replayed whenever the prompt, model or data changes. Without it, every model upgrade is a gamble and nobody can tell whether last month's change degraded anything. With it, an upgrade is a number you can look at.

Ask for this in the brief. If a vendor cannot explain what their evaluation set will contain before the build starts, they are not planning to build one.

The engagement timeline, and what is normal

The shape below is the one I run. It is not the only correct shape, but it is specific enough to compare against, which is the point of publishing it.

Two details worth noting. Week 1 produces no software, and a buyer who measures progress by commits will find that alarming; it is the week that determines whether weeks 2 to 8 are worth doing. And week 2 is where most projects change scope, not because the client changed their mind but because the data did. A plan that cannot absorb that is a plan that will be declared off-track in the second week.

What a demo-stage engagement looks like instead

The contrast is easier to spot once you know what to look for.

The last row is the fastest test. Ask for the failure modes of the specific system being proposed, and see whether they arrive with detail and hesitation or as a confident list of risks that apply to any software project.

Where this model does not fit

Three honest exceptions, because a week-by-week shape is a template and templates have edges.

If the work is genuinely research, the weekly artefact cannot be working software against real data, because there may be no path yet. That is a different engagement with a different shape, and it should be priced and framed as research rather than smuggled into a build.

If the constraint is a regulated process you cannot change, the binding artefact is the audit trail, not the interface. The timeline above still applies but the weeks shift: the failure path section of the brief grows and the build gets shorter.

If you already have an engineering team and need one specific capability, you want augmentation, not an engagement. That is cheaper and faster, and a vendor who steers you toward a full engagement when you asked for augmentation has told you what they are optimising for. My own practice declines that work outright, which is stated on the same page as the model above.

What to do on Monday

Take the four artefacts and turn them into acceptance criteria for your next conversation: a brief you keep, weekly working software on your data, a written decisions log, and a handover that does not need its author. Ask any vendor to commit to producing those four, and ask what happens at each point if they cannot.

The one that most often goes missing is the evaluation set, because it produces no visible progress. Ask for it in the brief anyway. It is the difference between a system you can maintain and a system that quietly rots.