How to brief an AI employee so it actually does what you want
When an AI employee delivers something off-target, founders usually blame the AI. Usually the problem is the brief. Writing a good brief is the manager's job — and it's a learnable skill.
Briefing is not prompting
There's a mental model many founders carry from using consumer AI tools: you type a request, you get a response, you refine it in the same conversation. That's prompting. Briefing is different.
A brief is a standalone document that gives an employee — human or AI — everything they need to complete a task without coming back to you every five minutes. A prompt assumes you'll be in the loop. A brief assumes you won't be. That distinction changes everything about what you put in it.
When you brief an AI employee on Summon, you're setting them loose on a task in their queue. They'll work through it, make judgment calls, and deliver a result. The brief determines the quality of those judgment calls. A thin brief produces safe, generic output. A complete brief produces something that actually sounds like it came from someone who understands your business.
The four elements of a complete brief
1. Context — the "why" and the "who"
Context is not background noise. It's the information that changes how a competent person would approach the task. For a marketing brief, context includes who the audience is (not "small business owners" — be specific: "bootstrapped SaaS founders with one to five employees, technically comfortable but time-constrained"), what they currently believe about your product, and what you want them to believe or do differently after encountering this piece.
For a finance brief, context includes which period you're looking at, what decisions the report will inform, and what concerns are already on the founder's mind. Context that doesn't change how the task gets done is just noise — but most founders are more likely to leave out relevant context than to include irrelevant detail.
2. Success criteria — what "done" looks like
This is the most commonly skipped element and the most consequential. Without a clear success criterion, your AI employee will optimize for something — it will just be their guess about what you wanted, not your actual goal.
A useful success criterion is specific and testable. "A good post" is not testable. "A 600–800 word post that a first-time founder would bookmark and share, written at a grade-9 reading level, with a specific actionable takeaway in each section" is testable. You can read the output and evaluate it against those criteria without referring back to your own unstated preferences.
3. Constraints — what to avoid or stay within
Constraints are often the difference between something you can use and something you have to rewrite. Common constraints: word count or format, tone (formal vs. conversational), topics or claims to avoid, competitors not to name, tools or channels not to use, information that's confidential and shouldn't appear in output.
Constraints also include approval gates: "Draft the outreach copy but don't send anything — flag it for my review first." Stating this explicitly prevents an eager employee from interpreting "write outreach" as "send outreach."
4. Output format — how to package the result
Format is related to constraints but deserves its own entry because founders forget it so reliably. What format does the output live in? Who reads it and where — in an email, on a slide, in a doc, in a dashboard? Should the employee include their reasoning, or just the final deliverable? Should they flag questions or assumptions, or work around them?
The best briefs say something like: "Deliver a Google Doc with three sections: executive summary (3 bullets), full analysis (no length limit), and recommended next steps (numbered list, max 5 items). Flag any assumption you made in a notes section at the end." That brief produces a usable artifact the first time.
The brief is a management skill
Most founders who get poor results from AI employees have never worked on their briefing practice. They write the same kind of thin request they'd send in a Slack message — and then wonder why the output feels generic or misses the point.
The upside is that briefing is learnable quickly. Spend 20 minutes writing one complete brief — all four elements — and compare the output to what you were getting before. The difference is usually large enough that you never go back to the thin-request habit.
The other upside: once you've written a good brief for a recurring task, you own it. It becomes an asset. Every person — or AI employee — who works from it will produce better results than if they were working from scratch.
Ready to hire your first AI employee?
Summon gives you 8 AI departments for $500/month. No per-seat pricing. No setup fee.
Start for free →Frequently asked questions
How much context is too much in a brief?
In practice, founders almost never give too much context — the failure mode is nearly always too little. If you're worried about length, focus on relevance: cut company history that doesn't affect the task, keep any context that changes how a reasonable person would approach it. A 400-word brief with high-signal context outperforms a 50-word brief that leaves the employee guessing about your audience, your constraints, or why the task matters.
Should I write a new brief for every task, or can I reuse them?
Recurring tasks — weekly reports, outreach sequences, monthly reviews — deserve a template brief you refine over time. One-off tasks deserve a fresh brief. The risk of reusing a brief without reviewing it is that you bake in outdated context or constraints that no longer apply. A two-minute review of a template brief before each use is a much smaller cost than a deliverable built on stale assumptions.
What if I don't know what success looks like yet?
Then say so explicitly in the brief — "I'm not sure what I want here, so give me three different approaches and I'll pick a direction." This is a legitimate success criterion. What you want to avoid is leaving the success criterion undefined and unacknowledged, which forces the AI employee to invent one. An explicit "give me options" produces something useful. An implicit "figure out what I want" produces something generic.