How to Brief an AI Agent So It Actually Does What You Want
Most AI agents fail not because the technology is weak, but because the brief is vague. Here's how to write instructions that produce work you'd actually sign off on.
How to Brief an AI Agent So It Actually Does What You Want
Most AI agents fail because the person setting them up briefs them the way they'd brief a colleague who already knows the business.
You've probably tried this. You give an agent a task — "reply to customer enquiries", "summarise this contract", "qualify leads from the form" — and the output is technically correct but useless. It misses context. It uses the wrong tone. It skips the one thing that mattered.
The problem isn't the model. The problem is that you're briefing a system that has no memory of your last five years in business, no idea who your customers are, and no clue what "good" looks like to you. If you brief it properly, it will do the work of a decent junior. If you don't, it will produce generic output forever.
Here's how to write a brief that actually works.
Start with the outcome, not the task
Bad brief: "Reply to customer emails."
Good brief: "Reply to customer emails so that the customer feels heard, gets the specific answer they need, and either books a call or is told clearly why we can't help them."
The first version tells the agent what to do. The second tells it what success looks like. Every decision the agent makes downstream — tone, length, whether to ask a clarifying question, whether to escalate — flows from that outcome statement.
Write the outcome the way you'd describe the job to a new hire on their first day. Not "process invoices" but "make sure every invoice is paid within 14 days without me having to chase". The agent needs to know what it's optimising for, because it will make trade-offs, and you want those trade-offs made in the right direction.
Give it the context a new hire would need
A new employee walks into your business with zero context. On day one, you tell them: who your customers are, what you sell, what you don't sell, who your competitors are, what your prices are, how you talk to clients, and what the red lines are.
An AI agent needs the same briefing, written down. Most people skip this because it feels obvious. It isn't obvious to the agent.
At minimum, include:
- Who you are. One paragraph on the business, what you do, who you serve.
- Who the customer usually is. The typical enquirer — their role, their likely question, their level of technical knowledge.
- What you charge, in ranges. So the agent doesn't quote figures you'd never quote.
- What you don't do. The requests you turn down. The industries you won't work with. The scope you won't take on.
- How you sound. Two or three example replies you've actually sent, with a note on why they work.
This context block is boring to write. It's also the difference between an agent that sounds like your business and one that sounds like ChatGPT wearing your logo.
Show it examples of good and bad
Rules tell an agent what to do. Examples show it what "done well" looks like. Examples win almost every time.
If you want the agent to qualify leads, don't just describe a qualified lead. Paste three real enquiries that were good fits and three that weren't, with one line explaining why for each. If you want it to write follow-up messages, paste four follow-ups you've sent that got replies, and two that didn't, with a note on the difference.
You'd be surprised how few people do this. They write a 400-word instruction document and include zero examples. Then they wonder why the output is generic. The model is a pattern-matcher. Give it patterns.
A useful ratio: for every rule you write, include at least one example of the rule being followed correctly, and one of it being broken. Three examples of each is better.
Define the edges — what to do when things go wrong
Half of a real job is knowing what to do when the situation doesn't match the script. Your brief needs to cover the edges, or the agent will invent an answer.
Cover these explicitly:
- What if the request is outside scope? Give the exact response. "Thanks for reaching out — we don't handle X, but I'd recommend Y."
- What if the customer is angry? Tell it to acknowledge, not defend, and to flag the message to you.
- What if it doesn't know the answer? Tell it to say so and escalate, not to guess. This one instruction alone prevents most agent disasters.
- What if the request needs a human decision? Define what those decisions are. Refunds over a certain amount. Custom pricing. Anything legal. Anything about a specific existing client.
An agent without edge-case instructions will confidently do the wrong thing. An agent with them will hand off cleanly when it should.
Tell it what tools it has and when to use them
If your agent can send emails, check a calendar, look up a customer in your CRM, or create a task in your project tool, it needs to know:
- That the tool exists.
- What it's for.
- When to use it versus when not to.
"You have access to the calendar. Use it to check availability before offering a time. Never offer a time you haven't verified." That's a complete instruction. The agent now knows the tool, the purpose, and the rule.
The most common failure mode we see: an agent has ten tools available, no guidance on which to use when, and it either uses the wrong one or ignores them all and hallucinates an answer. Rank the tools. Say which is default. Say which requires a specific condition.
Test it against real work, not made-up scenarios
Once the brief is written, don't test with a clean, obvious example. Test with the last twenty real messages you got. The awkward ones. The half-typed ones. The one where the customer replied to the wrong thread. The one written in pidgin. The one where they attached a photo of a receipt with no context.
If the agent handles ten out of twenty well, your brief needs another round. If it handles seventeen out of twenty, you're close — look at the three failures and add instructions or examples that would have caught them.
Two rounds of this and you'll have an agent that handles the bulk of the work at a standard you'd sign off on. Skip this step and you'll have an agent that works in the demo and fails in production.
The bottom line
Briefing an AI agent is not a technical skill. It's a management skill. If you can write a job description that a new hire could actually follow on day one — with the context, the examples, the edge cases, and the escalation rules — you can brief an agent.
The businesses getting real work out of AI right now aren't the ones with the best models. They're the ones whose founders sat down and wrote a proper brief. Two hours of writing beats two months of tweaking prompts every time.
If you want to see how this applies to your business, book a 30-minute audit with LVD Labs. We'll look at your current setup and tell you exactly where AI and automation can make a measurable difference.