How to Write an AI Brief: What to Tell Your Agency So They Build the Right Thing

Your Brief Determines Your Outcome

The quality of what you get from an AI agency is directly proportional to the quality of what you give them. Most briefs we receive are either three sentences or thirty pages. Both are problems.

Three sentences gives us nothing to work with. Thirty pages buries the actual problem under technical specifications nobody asked for. The best briefs we have ever received fit on a single page. They were clear, specific, and focused entirely on the problem.

Here is how to write one.

Why Most Briefs Fail

Briefs fail in two predictable ways.

The first is too vague. "We want AI." That tells us nothing. What part of the business? Which team? What are they struggling with? "We want AI" is like telling an architect "we want a building." True, but useless.

The second is too prescriptive. "Build us a GPT-4 RAG pipeline with vector embeddings and a fine-tuned model served through a Kubernetes cluster." That is not a brief. That is a solution looking for a problem.

The first gives no direction. The second gives the wrong direction. When a client tells us exactly what to build, they are usually describing what they read about last week. Not what their business actually needs. We have thrown away dozens of detailed technical specs from clients because the solution they described would not have solved the problem they had.

Your job is to explain the problem. Our job is to figure out the solution.

What to Include

A good brief answers six questions. That is it.

What is the problem? Be specific. "Our sales team spends 4 hours per day on data entry" is useful. "We need to be more efficient" is not. Quantify wherever possible. Hours wasted, revenue lost, customers churned, errors made. Numbers make problems real.

Who is affected? Name the team, the role, or the department. "Our three account managers" is better than "the company." The more specific you are about who feels the pain, the better we can design something that fits their actual workflow.

How is it handled today? Walk us through the current process. Step by step. This is where most of the value lives. We need to understand what your people actually do, not what they are supposed to do. Include the workarounds. Include the spreadsheets nobody is proud of. Include the copy-paste routines. Those are the things we fix.

What does good look like? Describe the outcome you want. Not the tool. "Account managers spend less than 30 minutes on data entry" is a clear target. "An AI dashboard" is not. We need to know what success means to you so we can measure whether we hit it.

What have you already tried? Tell us about the tools you tested, the processes you changed, the vendors you spoke with. This saves us from recommending something you already ruled out. It also shows us what did not work and why. That is some of the most valuable information in a brief.

What is your timeline and budget range? You do not need exact numbers. But "we need this before Q3" is different from "sometime this year." And "$10K" is a different project than "$100K." Knowing the ballpark lets us scope appropriately instead of designing something you cannot afford or delivering something below what you need.

What to Leave Out

Technical requirements. That is our job. When you specify that you want GPT-4 instead of Claude, or that you want a vector database instead of a knowledge graph, you are constraining us to a solution before we understand the problem.

Detailed architecture diagrams. Same reason. You would not hand your surgeon a diagram of the operation before they examined you.

Specific model preferences. The model is a tool. We pick the right one based on your use case, data, latency requirements, and budget. It changes frequently. What was best three months ago is not necessarily best today.

Your brief should be technology-agnostic. Describe the world you want to live in. Let us figure out how to build it.

The Framework: Problem, People, Process, Proof

If you want a simple structure, use this.

Problem. One paragraph. What is broken, slow, expensive, or error-prone? Use numbers.

People. Who deals with this problem daily? What is their role? How many of them are there?

Process. How do they handle it right now? Walk through a real example from start to finish. Screenshot a typical day if that is easier.

Proof. How would you know if the problem was solved? What would change? What metric would move?

That is four paragraphs. Maybe a page. It tells us everything we need to start.

Red Flags in Your Own Brief

Read your brief before you send it. Look for these warning signs.

You cannot describe the problem without mentioning AI. If the word "AI" appears in your problem statement, you do not have a problem yet. You have a solution in search of one. The problem should stand on its own. "Our support team answers the same 40 questions 200 times a month" is a problem. "We need an AI chatbot" is not.

The brief mentions a solution before a problem. If the first paragraph describes what you want built instead of what is wrong, flip it around. Start with the pain. The solution comes later.

There are no numbers. "It takes too long" does not help us. "It takes 6 hours per week per person across a team of 12" does. Vague problems lead to vague solutions.

You describe the tool, not the outcome. "We want a dashboard" is a tool. "We want to see pipeline health without pulling data from four systems" is an outcome. Design for outcomes.

Everyone on your team would describe the problem differently. If your head of sales says "we need better lead scoring" and your CTO says "we need a data warehouse" and your CEO says "we need AI," the brief is not ready. Align internally before you brief externally. Otherwise we are solving three different problems and delivering something that satisfies none of them.

Why We Start by Embedding With Your Team

This is how we work at Deadly. Before we write a single line of code, we embed with your team. We watch how they work. We sit in on calls. We look at the tools they actually use, not the ones they are supposed to use.

The best brief is watching your people work. We see the inefficiencies they have stopped noticing. We catch the workarounds that have become routine. We find the problems worth solving, not just the ones that are top of mind.

But a good written brief gets us 80% there before day one. It means our first conversations are about clarifying details instead of discovering basics. It means we spend our embedded time validating what you told us, not starting from scratch.

If you want to understand more about how this works in practice, take a look at how we work.

The One-Page Test

Here is a simple test. If your brief is longer than one page, it probably contains solutions disguised as requirements. Cut it down. Focus on the problem, the people, the process, and the proof.

If your brief is shorter than half a page, it probably lacks the specificity we need. Add numbers. Add a walkthrough of the current process. Add what you have already tried.

The sweet spot is one page that makes us say "we know exactly what to go look at." That is the brief that gets you the right solution. Not just a solution.