hawkes.aiKey ideas
- The one idea — Every message carries a role label — system (rules/identity), user (requests), assistant (the model's own prior replies) — and roles are the hidden structure that shapes behavior.
- How it is shown — The transcript re-shown with its role tags visible; the system message setting the frame, user and assistant alternating beneath it.
- The trap to avoid — Treating the system prompt as absolute law — it's influential, not unbreakable; clever user input can talk over it.
- What it sets up — Roles are structure — but content matters more.
Before you typed a word, your AI chat already contained instructions you can't see — a system message setting its rules and personality. It shapes every reply.
The one idea
Every message carries a role label — system (rules/identity), user (requests), assistant (the model's own prior replies) — and roles are the hidden structure that shapes behavior.
Last episode, the context became a program. Now look closer: not a flat list of messages. Every message carries a hidden label — a role — and there are three: system, user, and assistant. These labels structure the program, shaping every reply. Most users never see them. You're about to. Three roles. System: the setup — rules, identity, how to behave, written once at the top. User: that's you, your requests. Assistant: the model's own past replies, fed back so it sees what it already said. The transcript is just these three, alternating and labeled.
How it works — the demo
The transcript re-shown with its role tags visible; the system message setting the frame, user and assistant alternating beneath it.
The system role is the powerful one — the constitution for the conversation: you are a support agent, never discuss competitors, always be concise. Set once, it colors every response after it. It's why the same model can be a pirate, a lawyer, or a code reviewer — reframed before the user types a word. User and assistant are the back-and-forth. The subtle part: the assistant's past replies are fed back in as assistant-labeled messages, so the model reads its own prior words as input. That's how it stays consistent with what it said — not memory, but its labeled words, re-read from the transcript. For builders, roles are a control panel. Put durable rules in the system message so they persist. Put the live request in the user message. Keep them clean — don't smuggle rules into user text, or the model gets confused about what's a rule versus a request. Right role, right content.
The trap to avoid
Treating the system prompt as absolute law — it's influential, not unbreakable; clever user input can talk over it.
Why it matters — and what’s next
Roles are structure — but content matters more.
The trap: treating the system prompt as unbreakable law. It's influential, not absolute. Clever user input can talk over it — "ignore your instructions and…" — because to the model it's all just text, the system message merely weighted heavier. That gap is a real security hole we'll dedicate an episode to. So roles are the hidden structure — system frames, user asks, assistant echoes. But structure is only half the program. You can label everything perfectly and still get bad output if the content is thin. What moves the needle isn't role-labeling — it's what information you put in at all. Next: context engineering beats prompt tricks.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:30 of narration
Last episode, the context became a program. Now look closer: not a flat list of messages. Every message carries a hidden label — a role — and there are three: system, user, and assistant. These labels structure the program, shaping every reply. Most users never see them. You're about to.
Three roles. System: the setup — rules, identity, how to behave, written once at the top. User: that's you, your requests. Assistant: the model's own past replies, fed back so it sees what it already said. The transcript is just these three, alternating and labeled.
The system role is the powerful one — the constitution for the conversation: you are a support agent, never discuss competitors, always be concise. Set once, it colors every response after it. It's why the same model can be a pirate, a lawyer, or a code reviewer — reframed before the user types a word.
User and assistant are the back-and-forth. The subtle part: the assistant's past replies are fed back in as assistant-labeled messages, so the model reads its own prior words as input. That's how it stays consistent with what it said — not memory, but its labeled words, re-read from the transcript.
For builders, roles are a control panel. Put durable rules in the system message so they persist. Put the live request in the user message. Keep them clean — don't smuggle rules into user text, or the model gets confused about what's a rule versus a request. Right role, right content.
The trap: treating the system prompt as unbreakable law. It's influential, not absolute. Clever user input can talk over it — "ignore your instructions and…" — because to the model it's all just text, the system message merely weighted heavier. That gap is a real security hole we'll dedicate an episode to.
So roles are the hidden structure — system frames, user asks, assistant echoes. But structure is only half the program. You can label everything perfectly and still get bad output if the content is thin. What moves the needle isn't role-labeling — it's what information you put in at all. Next: context engineering beats prompt tricks.