How to Write an AI Agent Brief: What a Developer Needs Up Front

Knowing how to write an AI agent brief is one of the cheapest ways to avoid an expensive project. Most business owners approaching a developer have a clear sense of the pain, such as missed leads, slow support replies, or staff buried in repetitive admin, but only a fuzzy picture of what the agent should actually do. That gap gets filled by the developer's assumptions, and assumptions are where budgets, timelines, and expectations drift apart.

The cost of a weak brief rarely shows up on day one. It shows up six weeks in, when a working demo handles the wrong questions, connects to the wrong system, or takes actions nobody meant to allow. Fixing scope at that point means rework, and rework on an AI agent often means rethinking integrations and guardrails, not just tweaking prompts.

This guide gives you a practical way to prevent that. It covers the eight things every AI agent brief should include, a one-page template you can fill in before your first developer call, a side-by-side comparison of vague and specific answers, the most common mistakes people make when writing briefs, and what a good development team should send back after reading yours. No technical knowledge is needed.

Why Most AI Projects Start Wrong

The most common cause of a failed AI agent project isn't bad technology. It's a bad brief.

A business comes to a developer and says "we want an AI chatbot for customer support." The developer builds something. Six weeks later, the business looks at it and says "this isn't what we meant." Both sides are frustrated. Money has been spent. Nothing useful has shipped. We've been on both sides of that conversation, and it's preventable almost every time.

The disconnect is almost always about specificity. "Customer support" means something different to every business. "AI chatbot" could mean twenty different things. Without a clear brief, developers make assumptions — and assumptions are where projects quietly go sideways.

A good brief doesn't require technical knowledge. It just requires you to think clearly about what you actually want. This walks you through it.

Benefits of Writing an AI Agent Brief

Accurate quotes and timelines

Developers price what they understand. When the brief names the systems, the actions, and the volume of conversations, a team can estimate integration work and guardrails with far less padding. Vague briefs produce either inflated quotes that cover every possible interpretation or low quotes that grow later. A specific brief gives you numbers you can actually compare between vendors, because everyone is pricing the same thing.

Fewer surprises at the first demo

The week-six demo that handles the wrong questions is usually a brief problem, not a build problem. Writing down what the agent handles, what it refuses, and when it escalates means the first working version is measured against an agreed description. Disagreements surface on paper, where they are cheap to resolve, instead of in a half-built system. When the demo does miss something, the brief shows whether it was a misunderstanding or a change of mind, which keeps the conversation about scope rather than blame.

Safer agents by design

Listing actions, limits, and exclusions forces the risk conversation before anything is connected to your systems. Decisions such as a refund cap, read-only access to customer records, or always routing legal complaints to a person become requirements the developer builds around, rather than guardrails bolted on after something goes wrong in production. They also tell the developer which integrations need write access and which can stay read-only, which shapes the whole architecture.

A clear definition of success

Success metrics with a baseline give both sides a shared way to judge the project. You know what to check at 30, 60, and 90 days, and the developer knows what they are optimising for. Without them, evaluation turns into opinions about whether the agent "feels" helpful, which is hard to settle and easy to argue about.

Better internal alignment

Writing a brief often reveals that different people in the business want different things from the agent. Sales may want lead qualification while support wants deflection. Settling that before talking to a developer avoids paying for a build that satisfies nobody, and it gives the project a single owner who can answer the developer's questions.

The Eight Things Every AI Agent Brief Should Cover

1. The Problem You're Trying to Solve

Start with the problem, not the solution. "We want an AI agent" is not a brief. "We're losing 30% of our leads because we can't respond fast enough outside business hours" is a brief.

Be specific about the pain:

• What is happening right now that you don't want to be happening?
• How often does it happen?
• What does it cost you — in time, money, or customer experience?
• What have you already tried?

A developer who understands your problem can tell you whether an AI agent is the right solution — and if it is, what kind. If it isn't, we'd rather say so upfront than build the wrong thing.

2. Who the Agent Talks To

Describe your users as specifically as you can:

• Are they your customers, your employees, or both?
• What do they already know about your business and products?
• What channel do they reach you through — website chat, WhatsApp, email, phone?
• What's their technical comfort level?
• What languages do they communicate in?

The answer changes the agent significantly. An internal HR agent for your own team is a very different build from a customer-facing agent for first-time buyers.

3. What the Agent Should Handle — and What It Should Not

This is the most important part of the brief, and the part most people skip.

List the specific query types or tasks the agent should handle. Be concrete:

Handle: "Questions about our return policy", "Order status lookups", "Appointment booking for consultations", "Qualifying questions for new leads"

Do not handle: "Complaints involving legal claims", "Anything requiring a clinical judgment", "Requests for refunds above £500"

The things the agent should not handle are as important as the things it should. A well-scoped agent is more reliable, faster to build, and easier to measure than one trying to do everything. The projects we've seen fail most often are the ones that started with "and it should also handle…" until the scope was effectively "everything."

4. What Actions the Agent Should Take

There's a big difference between an agent that answers questions and one that takes actions. Be clear about which you need.

Answers only: The agent provides information from your knowledge base but never touches your systems.

Actions included: The agent can look up order status, book appointments, process refunds, update records, send emails.

For each action, note:

• What system does it need to connect to?
• What data does it need to read or write?
• Are there rules or limits on when it can act? (Refunds only under £100, appointments only within the next 14 days, etc.)

Action-taking agents are dramatically more useful and dramatically more risky. Worth thinking through the guardrails before they're built, not after.

5. When and How to Escalate to a Human

Every AI agent needs an escalation path. Define it clearly:

• What types of query should always go to a human, regardless of whether the agent could answer?
• What signal tells the agent to escalate — a certain phrase, an emotional tone, a query type it doesn't recognise?
• Who does it escalate to — a specific team, an inbox, a phone number?
• What information should the agent hand over when it escalates?
• What does the customer experience during the escalation — do they wait, get a callback, get transferred in real time?

Escalation isn't a failure state. It's part of the design. Plan it explicitly, because the agents that frustrate customers most are the ones that won't let go when they should.

6. Your Existing Tools and Systems

The agent needs to plug into something. List your current stack:

• CRM: which one, how data is structured
• Helpdesk or ticketing system
• Calendar or booking system
• E-commerce platform or order management system
• Phone system (if voice is involved)
• Any internal databases the agent needs to query

The more detail you provide here, the more accurately a developer can scope the integration work — and that's usually where the complexity and cost actually live. A "simple" integration with a vendor whose API was last updated in 2014 is anything but.

7. What Success Looks Like

Define measurable outcomes before the project starts. If you can't define success, you won't know when you've reached it — and neither will the developer.

Good success metrics:

• Response time: "All inbound leads responded to within 60 seconds"
• Deflection rate: "60% of support tickets resolved without human involvement"
• Booking rate: "25% of inbound enquiries converted to booked appointments"
• No-show rate: "No-shows reduced from 20% to under 10%"

Avoid vague metrics: "improved customer experience", "better efficiency", "more automation". Those are goals. Success metrics are numbers.

8. Your Timeline and Budget

Be honest about both. A developer who knows your budget can tell you what's achievable within it. A developer who doesn't will either overbuild (expensive) or underbuild (disappointing) — and you won't know which until weeks in.

Useful things to share:

• When do you need this live? Is there a hard deadline — a product launch, a busy season, a board commitment?
• What's your budget range? Even a broad one is more useful than nothing.
• Is there a phased approach you're open to — a simpler v1 now, expanded later?

We genuinely prefer to know the budget upfront. It's not so we can quote to it; it's so we can tell you whether what you're describing is realistic within it.

A Simple Brief Template

Here's a one-page format you can fill in before your first call with a developer:

Problem: [What is happening that you want to change? Be specific.]

User: [Who does the agent talk to? What channel? What do they know?]

Handles: [List specific query types or tasks the agent manages]

Does not handle: [List explicit exclusions]

Actions: [What can the agent do in your systems? What are the limits?]

Escalation: [When does it hand to a human? Who? What does it pass on?]

Systems: [List your CRM, helpdesk, calendar, and any relevant platforms]

Success: [What specific numbers would tell you it's working?]

Timeline: [When do you need it live?]

Budget: [What range are you working within?]

One page. Ten minutes to fill in. Worth more than an hour of vague discovery calls.

Vague Brief vs Specific Brief: What the Difference Looks Like

The table below shows how the same eight brief sections read when written vaguely versus written with the specificity a developer actually needs. The right column is what gets you an accurate quote and a build that matches what you imagined.

If most of your answers currently look like the middle column, spend another 20 minutes on the brief before your first developer call. The specificity pays for itself many times over.

AI Agent Brief Use Cases

Briefing a customer support agent

Support agents live or die on scope. The brief should list the top query types by volume, the knowledge sources the agent may use, and the categories that must always reach a person, such as complaints mentioning legal action. Including a sample of real tickets helps the developer see how customers actually phrase things. The outcome is an agent built around your real ticket mix rather than a generic idea of support.

Briefing a lead qualification agent

For lead follow-up, the important details are response-time targets, the qualifying questions sales actually uses, and what makes a lead "hot." The brief should say which CRM fields the agent writes, how sales is notified, and when automated follow-up stops. With those defined, the developer can build routing that matches how your sales team works instead of inventing criteria.

Briefing an appointment booking agent

Booking agents need clear rules: which services can be booked, how far ahead, with which staff, and what happens with cancellations and no-shows. The brief should name the calendar or booking system and any constraints, such as consultation length or buffer times. Precise rules here prevent double bookings and avoid an agent offering slots the business cannot honour.

Briefing an internal operations agent

Agents for HR questions, policy lookups, or internal requests serve employees rather than customers. The brief should describe which documents are authoritative, who can see what, and when a request must go to a manager. Because internal data often includes sensitive information, access rules belong in the brief from the start, not in a later security review.

Briefing a document processing agent

When the agent reads invoices, forms, or contracts, the brief should include example documents, the fields to extract, where results go, and what accuracy is acceptable before a human checks the output. Real samples, including the messy ones, let the developer estimate effort accurately and design the review step around the cases that will actually cause trouble. Note how many documents arrive per week and how quickly results are needed, since volume and turnaround drive the cost of the build.

Common Mistakes When Writing an AI Agent Brief

Even business owners who use the template above tend to fall into a few predictable traps.

Describing a solution instead of a problem

"We need a GPT-powered chatbot with RAG" is a solution, and it may be the wrong one. Lead with the business problem and the numbers behind it, and let the development team propose the architecture. You may find a simpler automation, or an existing tool, solves most of it.

Leaving out the exclusions

Teams list everything the agent should do and nothing it should avoid. The result is an agent that tries to answer legal questions, refund disputes, or medical queries it was never designed for. The "does not handle" list is what keeps the agent safe and the project measurable.

Treating actions and answers as the same scope

An agent that answers questions from a knowledge base and an agent that issues refunds in your payment system are very different builds with very different risk. If the agent will take actions, say which ones, in which systems, and with what limits. Frameworks like the NIST AI Risk Management Framework are a useful prompt for thinking through those risks.

Forgetting the data the agent depends on

An agent is only as good as the information it can reach. If your return policy lives in three inconsistent documents, or order data only exists in a spreadsheet one person updates, say so in the brief. Data clean-up is often a hidden part of the project.

Setting success metrics nobody can measure

A metric is only useful if you can actually collect it. Before writing "60% deflection," check that your helpdesk can report how tickets were resolved today, so there is a baseline to compare against. If it cannot, measuring the baseline becomes the first task of the project.

AI Agent Brief Best Practices

• Write the brief before the first developer call. Even a rough one-page draft makes the first conversation about your business rather than a generic sales pitch, and it gives you a fixed reference point when comparing vendors.
• Use real examples. Attach a handful of actual customer messages, tickets, or documents, including awkward ones. Examples show a developer what the agent will really face far better than descriptions do.
• Put numbers on everything you can. Volumes, response times, current costs, and target metrics turn opinions into requirements. Approximate numbers are fine; missing numbers are what cause scoping errors.
• Separate must-haves from later phases. Mark which tasks are essential for version one and which can wait. A clear first phase keeps cost and timeline realistic and gets something useful live sooner.
• Name one owner on your side. Choose the person who can answer the developer's questions and make scope decisions. Briefs written by committee tend to contradict themselves, and projects without an owner stall at every decision.
• Involve the people who do the work today. The support lead, salesperson, or administrator who handles the task now knows the edge cases. Ask them to review the handles, exclusions, and escalation sections before you send the brief.
• State constraints you cannot change. Note regulatory requirements, data that must stay in a particular region, systems that cannot be modified, and hard deadlines. Constraints discovered mid-build are some of the most expensive surprises.
• Describe what happens today when things go wrong. Explain how complaints, errors, and unusual requests are handled by people now. That process is the starting point for the agent's escalation design.
• Revise the brief after the developer responds. Treat the questions and pushback you receive as input. Update the brief so it becomes the shared reference for scope, and keep it current as decisions change.

What Happens When You Share This Brief

A good AI development team reads your brief and comes back with:

• Confirmation of what they can build within your constraints
• Questions about anything that's still ambiguous
• A clear recommendation on scope — what to build first, what to defer
• A realistic timeline and cost estimate based on what you've described

If they don't ask clarifying questions after reading your brief, that's a warning sign. It means they're either not reading carefully or they're planning to make assumptions and bill you for them later.

Related guides

• How to write an AI agent scope of work
• How to run an AI agent discovery workshop
• How to evaluate AI agent vendors
• 7 red flags that your AI agent developer can't deliver
• Our AI agent development services

We Can Help You Write Your Brief Too

If you're not sure how to answer some of these questions — or you want a developer to help you think through the scope before committing — that's a normal part of how we work.

We're happy to spend 30 minutes on a call going through your brief together, helping you get clarity on what to build, in what order, and whether it makes financial sense at all. Sometimes the conclusion is "you don't need this yet," and we'd rather get there together than after a contract.

Talk to us about your business — bring what you have, even if it's just a rough idea.

Frequently Asked Questions

What should I include in an AI agent brief before approaching a developer?

Cover eight key areas: the problem you're solving, who the agent talks to, what it should and should not handle, what actions it can take, how it escalates to humans, your existing tech stack, how you define success, and your timeline and budget. Even rough answers to these questions will save weeks of back-and-forth and help a developer give you an accurate quote.

How long should an AI agent brief be?

One page is enough. The goal isn't volume — it's specificity. A single page that clearly defines the problem, the users, the scope, and a success metric is worth more than a 20-page document full of vague aspirations. Use the template in this article as a starting point and fill in the blanks before your first developer call.

Do I need technical knowledge to write a brief for an AI agent?

No. A good brief is a business document, not a technical one. You describe what you want to achieve, who it's for, and what systems the agent needs to work with. The developer translates those requirements into technical decisions. Your job is to be specific about the business problem; their job is to figure out how to solve it.

What happens if I don't define what the agent should NOT handle?

Scope creep sets in fast. Without clear exclusions, developers make assumptions about what's in scope — and so do the agents themselves at runtime. Customers end up asking for things the agent wasn't designed to handle, leading to poor experiences and expensive rebuilds. Defining explicit exclusions upfront is one of the most valuable things you can do in a brief.

How detailed should my success metrics be in the brief?

As specific as possible. "Improved customer experience" is not a metric. "60% of support tickets resolved without human involvement within 90 days of launch" is a metric. If you can't define a number, you won't be able to evaluate whether the project worked — and neither will the developer. Even a rough target gives both sides something concrete to aim for and measure against.

Should I share my budget range with the AI development team?

Yes, always. A developer who knows your budget can tell you what's realistically achievable and recommend a sensible phasing — a simpler v1 now, more features later. Without a budget, developers either build to an assumed scope that turns out to be unaffordable, or underscope and deliver something disappointing. A broad range is more useful than no number at all.

What if I don't know which AI tools or platforms to use?

You don't need to. Your brief should describe what you need the agent to do, not how it should be built. A good development team will recommend the right underlying model, platform, and integration approach based on your requirements. Specifying technology in the brief before you understand the trade-offs often constrains the solution unnecessarily.

Conclusion

Most failed AI agent projects can be traced back to the first conversation, when "we want a chatbot" was treated as a specification. A clear brief closes that gap before any money is spent. It forces the decisions that matter: the exact problem, who the agent serves, what it handles and refuses, which actions it can take and under what limits, when it hands over to a person, which systems it touches, and how success will be measured.

The most useful parts of the brief are often the least obvious ones. Exclusions keep the scope realistic and the agent safe. Action limits define your risk. Measurable success metrics, with a baseline, let both sides judge whether the project worked. Sharing a budget range lets a good team propose a sensible first phase instead of guessing.

One caveat: a brief is a starting point, not a contract. Expect a good team to come back with questions, push back on parts of the scope, and sometimes suggest that a simpler tool or a later start makes more sense. For background on agent design patterns, Anthropic's guide to building effective agents is worth reading.

When your one-page brief is ready, book a call and we will go through it with you and tell you honestly what is worth building first.