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.
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 types of queries 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.
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.
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.