A good brief for an AI automation project covers six things: how the work is done today, the outcome you want and how you will measure it, the systems and data involved, how much error you can accept, and who will own and run the system afterwards. It does not need to name a model or a technology. The brief has done its job if a developer can read it and tell you what the system would do on a normal Tuesday, and what happens when it gets something wrong.
This guide works through each section, explains why it matters, and points out the details that are easy to leave out.
Why the brief matters more for AI than for ordinary software
Traditional software does what it is told. An AI component makes judgements, and a judgement can be wrong while still looking right. So the brief has to cover more than features. It has to describe the context the system works in, the risks you care about and the point at which a person steps in.
Public frameworks take the same approach. The UK government's AI Playbook tells teams to start from a clearly identified need, and calls AI "a means to an end", not an objective in itself. The US NIST AI Risk Management Framework is usually applied starting with its "Map" function. Map establishes context such as intended purposes, users, laws and deployment settings, and its outcomes form the basis for the later Measure and Manage functions. You do not need to adopt either framework, but following their order of thinking produces a better brief.
1. The problem, described as it works today
Describe the current process step by step, in plain language: who does it, how often, with which tools, and where it goes wrong. Avoid opening with "we want an AI agent that...". Open instead with something like "every day, two people in accounts open each supplier invoice and type it into...".
Include:
- Volumes: calls per day, emails per week or documents per month, and how these change by season or time of day.
- Time spent: rough hours per week on the task, and who does it.
- The painful part: the step that causes delay, errors or lost revenue. This is often narrower than the whole process.
- Baseline figures: current response times, error rates or conversion rates, if you have them. The AI Playbook recommends setting a baseline of metrics early, so that project outcomes have something to be measured against.
In a sales agent we built, the starting problem was not "we need AI". It was that outbound sales was being done by hand: searching for prospects, finding the right person's email, writing each message and chasing replies. Described that way, the brief covered the whole sequence, and the agent we built runs all of it, from finding prospects to replying when they answer.
2. The outcome and how you will measure it
State what success looks like in numbers you can check. Useful measures include time saved per week, response time to inbound enquiries, the percentage of items processed without anyone touching them, or qualified meetings booked.
The AI Playbook draws a distinction worth copying. Model metrics measure how well the technology performs its task. Service metrics measure whether user needs and business goals are being met. It warns that a system can show high accuracy while its users misread the outputs, and then ignore its recommendations or act in unexpected ways. Your brief should name at least one of each. For example, "fields extracted correctly" is a model metric, and "invoices posted to the ledger within one working day" is a service metric.
3. Scope: what it does and what it must not do
List the tasks the system should perform, then list the tasks it must never perform. A developer often finds the second list more useful than the first.
- In scope: for example, answer calls, classify the reason for each call and route it to the right team.
- Out of scope: for example, never quote prices, never take payment, never give medical or legal advice.
- Edge cases: angry customers, callers speaking another language, documents in an unexpected format, or a prospect who replies asking to be removed.
- Handover to a person: when the system should stop and pass the case on, to whom, and through which channel.
Be explicit about the first version. Pick one well-defined flow to automate, and list what comes next. That is far easier to estimate, build and test than a brief that tries to automate a whole department at once.
4. Systems, integrations and access
An AI automation has to read from and write to the tools you already use. Many of the design constraints come from those connections. Name every system involved: CRM, email, phone system, accounting package, calendar, shared drives and internal databases.
For each one, note:
- The product name and plan, since some plans restrict API access.
- Whether the automation needs to read, write or both.
- Who holds the admin account and can grant access.
- Any custom fields, workflows or in-house systems that have no public API.
If you plan to keep an existing phone number, email domain or inbox, say so. A voice receptionist we built answers calls on the client's existing phone number. Constraints like that affect the design, so they belong in the brief and should not wait for a later conversation. Connecting new systems to existing ones is the focus of our integrations and custom software work.
5. Data: what exists, where it lives and what is personal
An AI system can only work with the material it learns from or processes. Describe the data it will use:
- Examples: past conversations, call recordings, sample documents or previous emails that worked. Note how many you have and how far back they go.
- Quality: whether the data is clean, consistent and labelled, or scattered across inboxes and spreadsheets.
- Personal data: whether it contains names, contact details, or financial or health information.
- Samples: the AI Playbook advises giving suppliers dummy data where possible. Anonymised or synthetic examples let a developer judge whether the project is feasible without you sharing live records.
In a sales chatbot we built, the key input was the company's own past sales conversations. The chatbot learns from them so that it sounds like the business, not like a template. What data you actually hold decides which approaches are open to you, so the brief should say exactly what exists.
6. Error tolerance and human oversight
This section often shapes the build more than any other. Answer three questions:
- What does a wrong answer cost? A slightly awkward email is cheap. A wrong figure in the accounts or a misrouted urgent call is not.
- Is no answer better than a wrong one? In some processes, the system should flag that it is uncertain and stop.
- Where does a person check the work? Before it goes out, on a sample afterwards, or only on exceptions.
In the Pixelet bookkeeping pipeline, the answer to the second question was clear: a confident wrong answer is worse than no answer. That one constraint shaped the whole design. Several AI models process each entry independently, and an entry is accepted only when they agree. If your brief states its error tolerance up front, a developer can design for it from the start.
The AI Playbook calls for meaningful human control at the right stages. For tools that must respond instantly, such as chatbots, it puts that control in development and deployment, through assurance and regular checks, not in reviewing every reply. Say which pattern fits your process.
7. Compliance and legal constraints
The brief does not need to contain the legal analysis, but it should flag what applies.
- Data protection impact assessment (DPIA): the UK Information Commissioner's Office (ICO) says that in the vast majority of cases, using AI involves processing likely to result in a high risk to individuals, which legally requires a DPIA. If you decide a particular use is not high risk, you still need to document how you reached that view. Say in the brief whether you have started one.
- Controller and processor roles: the ICO expects you to assess and document the status of each organisation you work with on personal data processing. Your developer and any AI model providers will need a place in that picture.
- Telling people they are talking to AI: Article 50 of the EU AI Act requires that AI systems interacting directly with people inform them they are dealing with AI. The exception is where this would be obvious to a reasonably well-informed, observant person. If your chatbot or voice agent will serve EU customers, note this.
- Sector rules: consent for call recording, financial record keeping, marketing consent for outbound email, or rules from your industry regulator.
- Data location: any requirement for data to stay in the UK or EU.
8. Ownership, hosting and life after launch
Decide early what you want to own when the project ends. The AI Playbook advises buyers to plan how to avoid vendor lock-in and to agree which party will own which parts of any intellectual property created. Your brief should state:
- Whether you want the source code handed over, or are happy with a subscription to a hosted product.
- Where the system should run: your cloud account, the developer's, or a managed platform.
- Who will maintain it, and whether you have technical staff in-house.
- How you expect to monitor quality over time. The Playbook lists drift, bias and, for generative AI, hallucinations as things to monitor and mitigate.
There is a real trade-off here. A managed platform decides how your system behaves. In the AI voice receptionist we built, call classification and routing run on our own server, not inside the voice platform, so the logic is ours to change. If being able to change the logic matters to you, say so in the brief.
9. Budget, timing and decision-makers
Give a budget range, even a wide one. It tells a developer whether to propose a narrow first version or a fuller system, and it saves both sides from proposals that miss the mark. The main factors that drive cost are the number of integrations, the quality of your existing data, how strict your error tolerance is, and how much tooling you need for human review.
Also state any fixed dates (a seasonal peak, a contract renewal, a staff change), who signs off the project, and who will be the day-to-day contact. The AI Playbook recommends nominating a senior responsible owner who is accountable for the use of AI in each project. A business can use the same approach: name one person who owns the outcome.
What you can leave out
- The choice of model or vendor. Unless you have a contractual reason, let the developer propose one and explain why.
- Detailed screen designs. At this stage, a short description of who uses the system and how is enough.
- Perfect numbers. Estimates are fine if you label them as estimates.
A one-page checklist
- The current process, step by step, with volumes and time spent.
- The outcome you want, with one model metric and one service metric.
- What is in scope and out of scope, the edge cases, and the rules for handing over to a person.
- Every system it touches, whether it reads or writes, and who grants access.
- The data available, its quality, and whether it contains personal data.
- The cost of a wrong answer, and where people review the work.
- Compliance flags: DPIA, AI disclosure, sector rules and data location.
- What you expect on ownership, hosting and maintenance.
- Budget range, key dates and decision-makers.
Send us your brief
If you have a process you want to automate, a rough version of the checklist above is enough to start a conversation. Khive is a software engineering company that builds custom AI agents, voice agents, chatbots, document processing and integrations for businesses in the UK, US and EU. We build each system in code and hand it over, so you own it. Send us a brief describing the process you want to automate.