System prompts, in plain English
The invisible instruction sheet at the top of every agent conversation — what it contains, why it's long, and how to read one.
Every conversation with a chat or an agent starts with a message you never wrote: the system prompt. It’s the instruction sheet pinned to the top of the context, sent before your first question, and usually given higher priority than anything that follows.
Where it sits
┌────────────────────────────────────────┐
│ SYSTEM → "You are a careful code │ ← the harness writes this
│ reviewer. Never edit files. │
│ Reply in French. …" │
├────────────────────────────────────────┤
│ USER → "review this function" │ ← you
├────────────────────────────────────────┤
│ ASSISTANT→ "Done, two issues found…" │ ← the model
└────────────────────────────────────────┘
What’s usually in it
| Block | Purpose | Typical line |
|---|---|---|
| 🎭 Role | Who the model is supposed to be | “You are a senior backend engineer” |
| 🗣️ Tone & format | How it should talk and structure answers | “Be concise. Use markdown tables for comparisons” |
| 🧰 Tool policy | Which tools exist, when to use them | “Use read_file before suggesting an edit” |
| 🛡️ Safety rules | Hard limits | “Never run destructive commands without confirmation” |
| 📌 Task state | The current goal, constraints, files in play | “Working in D:/IA/site-ia, do not touch layouts/” |
| 🧠 Memory pointers | Where to look for long-term notes | “Check TASK.md at session start” |
Why agent system prompts are huge
A chatbot might ship with a 200-token system prompt. A serious coding agent carries thousands to tens of thousands of tokens on every single call: tool definitions, project conventions, security policy, examples of good and bad behaviour.
You can read them
Most apps expose their system prompt somewhere (a /system command, a settings panel, or the raw request in network logs), and the prompting-vs-fine-tuning article explains why reading one is a legitimate way to learn how a product is built.