What is a pre-build brief for an AI prototype?

A pre-build brief is four short pages written before building an AI prototype. Page 1 maps how the work runs today, step by step. Page 2 states the need in the words of the person with the problem. Page 3 gives the builder's point of view on what should change. Page 4 sets the plan and an adoption check with a date and a number. Anees Merchant recommends it for anyone in their first few years of work.

How does a pre-build brief differ from a project plan?

A pre-build brief starts from how the work runs today and the need of the person with the problem, and reaches the plan only on its last page. Each page has a proof test someone else can check: a stranger can follow the process map, the user agrees with the need, a colleague can argue with the point of view, and the adoption check has a date and a number.

Why do early-career people build AI prototypes before understanding the process?

Building a prototype with AI is now easy and gives a visible result quickly, so it can feel like the most rewarding place to start. Anees Merchant saw this in conversations with a lot of interns: each wanted to build first, and none had spent time on the process, the need or a point of view. Whether a prototype is adopted depends on whether it was the right thing to build, which the build alone cannot tell you.

When should a junior employee write a pre-build brief?

Before opening an AI tool on any assignment that changes how other people work, such as automating a report, a check or a handover. It is most useful when the assignment arrives as a solution, for example 'use AI to speed up X', because pages 1 and 2 can show the real bottleneck sits somewhere else. For a personal productivity experiment that affects nobody else, page 4 alone can be enough.

What is the first step to writing a pre-build brief?

The first step is to write down how the work runs today as numbered steps, noting for each one who does it, what they need to start and what they hand over, including the exceptions. Then give the page to someone outside the team and ask them to walk through the process from it. Every question they ask marks a gap to fill before moving to the need.

The Four Pages to Write Before You Build an AI Prototype

A pre-build brief is four short pages an early-career person writes before building an AI prototype, and each page carries a proof test that someone else can check. The pages cover how the work runs today, the need, a point of view and an adoption check. The brief matters because AI has made the prototype the easy part, and whether a prototype gets adopted depends on whether it was the right thing to build.

Interns who all wanted to build first

A few weeks ago I spoke with a number of interns. Every one of them wanted to prototype with AI first. None of the conversations got as far as how the work runs today, what the users needed, or what the intern thought should change.

Prototypes are cheap to build now, which moves the question to whether anyone will adopt this one.

A related question came up on stage earlier this month, at the AIM Cypher 2026 panel "From AI Teams to AI Systems", where I spoke about how global capability centres are rebuilding their workforce. The moderator, Karan Thapar, asked the one that stayed with the room: if AI takes over the repetitive work young employees learn from, how do companies build their next generation of senior leaders? My answer was that junior roles have to become apprenticeships in judgment, with real decisions from year one.

Three other points from the panel connect to this. One of the roles I described as gaining value is the translator: the person who sits with the business, maps how work happens today, and redesigns it. The translator's work comes before the build. Vishal Kulshrestha of Alshaya Group, also on the panel, argued that entry-level work will move toward analysing why an AI system made a decision. ANSR's analysis, which I cited in my write-up of the panel, finds that nearly 65% of new GCC roles in 2026 require AI skills.

So here is the habit I would hand to anyone in their first few years of work. Write four pages before you open the tool.

The four-page brief

The brief has four pages, in this order. Each page has a proof test, a question someone else can check against what you wrote. If a page fails its test, you are not ready for the next one.

Page 1: How it runs today  --> test: could a stranger follow it?
        |
Page 2: The need           --> test: did the person with the problem agree?
        |
Page 3: Your point of view --> test: could someone disagree with it?
        |
Page 4: Plan and adoption  --> test: is there a date and a number?
        |
     Build the prototype

Page 1: How the work runs today

Write the current process as numbered steps, in the order they happen. For each step, record the person responsible, the inputs that person waits for, and the output that moves on to the next step. Include the exceptions. The steps where someone says "it depends" or "we usually ask the buyer" are usually where the exceptions live, and they are the steps a prototype built from the assignment alone will miss.

The proof test is a stranger. Hand the page to someone outside the team and ask them to walk you through the process from it. Every place they stop to ask a question is a gap in your map.

Summary: the map is finished when someone else can run the process from it.

Page 2: The need

Go back to the person who has the problem and ask for the outcome they are after. Capture it in a single sentence, in their words where you can. Then mark the steps on page 1 where that need breaks down today: where time goes, where errors appear, where people wait.

This page can change the project. In an example I made up, the assignment says "speed up the report". The person says "I need to know by Tuesday which accounts are late". Those lead to different prototypes.

The proof test is agreement. Read the sentence back to the person with the problem. If they correct it, rewrite it until they don't.

Summary: the need is written in the user's sentence, with the broken steps marked.

Page 3: Your point of view

Now write one paragraph that names the change you would make and the reason you believe in it. This is the page the interns I spoke with had not touched. In your first months it can feel presumptuous to hold a view. Skip it and you have no position for the work to test, so every result looks like progress.

A point of view names the step you would remove, merge or hand to a model, and the reason you believe it would help. It can be wrong. That is the point of writing it down.

The proof test is disagreement. Show the paragraph to someone senior. If they can argue with it, it is a real point of view. If all they can do is nod, it is a description of the problem in different words.

Summary: the view is specific enough that a colleague could argue with it.

Page 4: The plan, with an adoption check

Only now decide what to build first. Write three lines: the scope of version one, the features you are deliberately holding back, and the evidence of use you will look for. "The team lead opens it at least twice in the first week" can be marked true or false. A line like "positive feedback" gives you nothing to mark.

The proof test is a date and a number. If the adoption check has neither, you will not be able to tell whether the prototype worked.

Summary: the plan ends with a check you can mark true or false on a set date.

A worked example

Here is how the four pages might look for a typical intern assignment. The example is illustrative, not drawn from a real company.

The assignment: "Use AI to speed up the monthly vendor invoice check."

Page 1 lists seven steps, from downloading the invoice batch to sending the exceptions list to finance. Step 5 reads "if the amount differs from the purchase order by more than a small margin, check with the buyer", and the margin turns out to vary by vendor.

Page 2, after a conversation with the finance analyst: "I need the exceptions list by the third working day, because that is when payments are approved." The broken steps are 4 and 5, where mismatches get matched by hand.

Page 3: "Step 4 should be done by a model that reads the invoice and the purchase order side by side and flags mismatches with a reason. Step 5 should stay with a person, because the margin rules live in the buyer's head and are not written anywhere yet."

Page 4: the first version flags mismatches only and leaves vendor-specific margins out. The adoption check is that the analyst sends the exceptions list from the tool's output in next month's cycle, by the third working day.

Compare that to the prototype the assignment invites: a chatbot that summarises invoices. It would have demoed well and changed nothing, because the bottleneck was the matching.

Why this is the career skill

The four pages put on paper the systems thinking and first-principles work the interns skipped. None of it needs a new tool, and it builds the judgment I argued for on the panel: knowing how work runs, what people need from it, and where a change will hold.

There is a practical benefit too. When you present a prototype with the four pages behind it, the people who will use it can follow what it does and why. The conversation in the review can move from "nice demo" to "should step 5 stay manual?", which is a conversation about the work. A brief that records the intended process also gives the analysis Kulshrestha described something to start from.

Using the pages with your manager

The pages also change the first conversation about an assignment. Take page 1 and page 2 to your manager before you build, and ask two questions: which step on the map did I get wrong, and is this the need you had in mind when you gave me the task? Both take a few minutes to answer, and both are cheaper to correct on paper than in a finished prototype.

Page 3 is the one to bring when you have a view your manager may not share. Put it in writing and ask them to argue with it. Their objections will tell you what you missed about the work, before anyone has spent a week building.

Three things to do this week

Write page 1 for your current assignment. Take the task you are working on and list today's process as numbered steps, with who, what they need and what they hand over. Give it to one person outside your team by Friday and count the questions they ask.
Get one sentence from the person with the problem. Book fifteen minutes with them this week. Ask what they are trying to get done, write it down, and read it back until they stop correcting you.
Add an adoption check to whatever you are building. Write one line with a date and a number that says how you will know someone used it. Put it at the top of your next status update.

Footer

Anees Merchant writes one essay every Tuesday about enterprise AI, agentic systems, and the human side of the work. He is the author of Merchants of AI, a TEDx speaker, and a doctoral researcher in Human-AI Communication at the Swiss School of Business and Management.

The newsletter version, with extra commentary, goes out separately on Mondays. Subscribe at /newsletter.

See you Tuesday.