Course contents · How AI agents actually work
- 1What is an LLM?
- 2Prompts: brief it like a contractor
- 3Tools: how an AI does things
- 4Context: what's on the desk
- 5Memory: the filing cabinet
- 6What is an AI agent?
- 7Evals: how do you know it works?
- 8Who approves what an agent does?
- 9RAG: finding the right page
- 10Subagents: when an agent delegates
- 11MCP: one plug for every tool
- 12Not everything needs to be an agent
- 13The whole picture
Lesson 2 of 13
Prompts: brief it like a contractor.
What a prompt really is, why it isn't dead, and how to write a clear brief that is neither too vague nor too specific.
CTO and co-founder, LaunchLemonade8 minReading timeImagine briefing a very capable contractor who has never met you, never seen your business and can't ask you a follow-up question. Whatever you leave out, they have to guess. That is what writing a prompt is like.
What a prompt is
A prompt is the instruction and information you give an LLM to shape what it writes next. Since the model predicts the next piece of text from the text so far, your prompt is the start of that text. It sets the direction for everything after it.
The contractor picture is useful because it reminds you what the model doesn't have. Your contractor:
- 01can't see your office, your files or your screen
- 02doesn't automatically know what good looks like
- 03can't get into your systems unless you give it access
- 04probably doesn't remember what happened last week
Every one of those gaps is something your brief has to fill, or something the system around the model has to provide.
Prompt engineering isn't dead
In 2024, prompt engineering meant hunting for magic words: give it a role, specify the format, tell it to think step by step. Then models got better, agents arrived, and people declared prompt engineering dead.
It isn't. The current guidance from both OpenAI and Anthropic still treats clear prompting as one of the most effective ways to improve results: better instruction-following, better tool use, better output. What changed is that the prompt is now one part of a bigger system, not the whole thing.
Too vague, too specific, about right
- Too vague
- The model has to guess what you want. You get something generic, and you can't tell which guess went wrong.
- Too specific
- You end up writing an enormous decision tree in plain English, covering every edge case. It contradicts itself, behaves brittlely and nobody wants to maintain it.
- About right
- A clear brief: the job, who it's for, what to use, what good looks like, what to do when unsure, and when to stop.
Write a reply to this customer complaint.
You reply to customer complaints for a small online bike shop. The job: draft a reply to the complaint below for me to check before sending. Use only the order details I've pasted. Don't promise refunds; say I'll confirm within one working day. Good looks like: under 120 words, warm, plain English, apologises once, says exactly what happens next. If the complaint mentions an injury or a legal threat, don't draft a reply. Tell me to handle it myself.
The second brief isn't longer for the sake of it. Every line answers a question the model would otherwise have to guess: who, what, with what, how good, and what if.
Show, don't just tell
Examples are often worth more than another page of instructions. If you paste two replies you were happy with and say "match this tone", the model has a pattern to follow, and following patterns is what it does best.
Pick examples that differ from each other, so the model copies the quality you want rather than one particular wording.
What a prompt can't do
A prompt can't give the model information it doesn't have. Writing "check the latest invoice" doesn't give it access to your invoices. Writing "remember this for next time" doesn't give it memory. A prompt can't give it a tool, decide when the task is done, or check whether the result worked.
Those come from the rest of the system: context, tools, memory, loops, evals, permissions and human review. That's why the prompt is important but incomplete, and why the rest of this course exists.
Running example
The running job
Chasing last month's unpaid invoices, one lesson at a time.
Here is Priya's brief for the invoice-chasing job. Notice it answers the six questions: the job, who it's for, what to use, what good looks like, what to do when unsure, and when to stop.
You help Priya, who runs an eight-person design studio, chase overdue invoices. The job: for each client with an overdue invoice (unpaid and past its due date), draft one polite reminder. If a client owes more than one, mention them all in the same email. Use only the invoice details and client contacts you're given. Never guess an amount or a date. Good looks like: short, friendly and firm, in Priya's tone (see the examples), with the invoice number, amount and due date, and how to pay. If an invoice is marked as disputed, or a client has replied about it, don't draft a reminder. List it for Priya instead. Stop when every overdue invoice has either a draft or a note for Priya.
On its own, this brief still can't find the invoices or send anything. It tells the model what to do. The next lessons give it the means.
Practice
Try it yourself
About five minutes, in any AI chat app
Turn a vague request into a brief
In any AI chat app, ask: "Write an email asking my team to fill in their timesheets." Keep the answer.
In a new chat, write a brief instead. Say who the team is, why timesheets matter this week, the deadline, the tone you want, and what to leave out. Add one example sentence in your own voice.
Compare the two emails side by side.
What to look for
The first email is probably generic and a bit stiff, full of guesses. The second should sound much closer to something you would send. Each detail you added replaced a guess the model had to make.
Common mistakes
Writing one line and blaming the model for a generic answer.
Answer the six questions: the job, who it's for, what to use, what good looks like, what to do when unsure, when to stop.
Trying to cover every edge case in the prompt.
Keep the brief clear and add examples. If behaviour still goes wrong in a specific case, fix that case, and test it.
Using the prompt to ask for things it can't deliver, like "check our CRM".
Data and actions need context and tools. The prompt can only describe the job.
Quick check
3 questions to see what stuck. Nothing is scored or saved.
1. What's the main risk of a prompt that's too specific?
2. Which of these can a prompt give the model on its own?
3. Why do examples often beat extra instructions?
Remember
A prompt is a brief for a capable contractor who knows nothing about you. Make it clear, not exhaustive, and show what good looks like.
Sources and further reading
- 1.The LinkedIn post this lesson grew out of: Prompt engineering
- 2.Anthropic: prompt engineering overview
- 3.OpenAI: prompt engineering guide
Optional
Try it in LaunchLemonade
Opens a new assistant with the invoice brief from this lesson already in its instructions. Improve this prompt will suggest edits. Everything above works in any AI tool.
Finished this lesson?
0 of 13 done in this course. Progress stays in this browser, no account needed.