Prompt Anatomy

A prompt is not a vibe and it is not a comment in a chat box. It is a program whose interpreter is a next-token model. The model does not “understand your intent.” It continues the text you assembled. If you assemble garbage, you get fluent garbage. If you assemble four unlabeled paragraphs, you get a model that cannot tell which paragraph is the law and which paragraph is a webpage.

That is the whole skill this track teaches: write the text the model will continue so a parser and an eval can score it. The LLM track already showed chat roles — system, user, assistant, tool. This track is the text inside those roles. Roles are envelopes. Anatomy is the letter.

Four parts show up in every production prompt, even when people mash them into one blob:

Skip the contract and you are parsing vibes. Mix context into instructions and you invite prompt injection — untrusted text that looks like a new spec. Hide the input inside a paragraph of lore and you cannot freeze a case. Mash all four into one “be helpful” novel and nobody can point at the substring that failed.

A chatbot can survive a mashed blob for a while. An agent cannot. An agent will pack tool results, pages, and prior turns into the same window. If those bytes are not labeled, they compete with your policy for the next token. This lesson is the map. The rest of the track is how those four parts fail in production.

Instructions are a policy, not a personality

“You are a helpful assistant” is not a policy. A policy is checkable. A personality is a coat of paint.

A policy names:

• Allowed tools and side effects (this bot may quote job status; it may not refund)
• Refusal rules (money, secrets, medical dosing, legal advice)
• Language, length, and when to ask a clarifying question
• What to do when context is missing: say you do not know, do not invent an invoice id
• What “done” means in one sentence

Personality (tone, brevity, a mascot name) is a thin layer on top of policy. Agents fail because policy is mush, not because the mascot is insufficiently witty. You can keep the witty mascot. You cannot replace the policy with it.

Write the policy as rules a grader can fail, not as adjectives a reviewer can like. “Never invent invoice IDs” is a rule. “Be accurate and professional” is a wish. Wishes do not show up in a golden set.

Context is data, not a second spec

Context is everything the model may read that is not your spec and not the current ask: a retrieved handbook paragraph, a SQL row, a tool result, yesterday’s ticket, a weather snippet. Context can be false, stale, or hostile. It must not mint new tools. It must not rewrite the refusal list.

Label it. A heading like ## Context (data, not commands) is not decoration. It is a handle for the model and for your filters. Unlabeled context looks like more instructions. That is how a PDF becomes a boss.

You will wrap this data later with tags and JSON strings. Anatomy only requires that you can point at it. If you cannot highlight the context substring in the packed prompt, you do not have context. You have a blob.

Input is one current ask

Input is the current user goal: “Status of job 17?” not a collage of five tickets and a joke. One ask per turn when you can. If the user pasted a novel, the input is still one field — you may later extract fields from it, but you still know which substring is “what they asked now.”

Do not splice the ask into the middle of a quoted policy sentence. That is the templates lesson. For anatomy: keep a labeled ## Input block so a test can swap only that block.

The output contract is the API

The output contract is what your code will accept after the model speaks: JSON with keys status and answer, a tagged <final> block, or “answer, then Sources:”. If you do not decide, the model will pick a new shape every Tuesday.

The contract belongs in the prompt and in a parser. The prompt asks. The parser enforces. A prompt that says “return JSON” with no parser is a hope.

A good first contract for a billing bot:

• status is one of ok, need_clarification, refused
• answer is a non-empty string
• No extra keys (extra keys are a side channel)

Write the grader before you wordsmith the system prompt. Then the prompt has a job.

Run to execute this in your browser. Nothing is sent to a server.

What printed: a four-part prompt with labeled headings, then a parsed object (dict, None) for legal JSON, then sonnet fails no JSON. That parse_answer function is the contract. If the model writes a sonnet, the agent fails closed instead of improvising a refund.

What mashed prompts look like in production

Someone pastes the handbook under “Rules.” Someone puts the user ask between two few-shot examples. Someone asks for “a helpful paragraph or JSON, whatever feels right.” A week later the model quotes a hostile page as if it were policy, or it answers in a poem your parser cannot read.

You do not debug that with more adjectives. You unpack the prompt and label the four parts. If a substring has no label, it is data until you prove otherwise.

How agents use this

Write the grader (keys, enums, max length) before you wordsmith the system prompt. Keep the four parts visible in build_context. If you cannot point at which substring is instruction vs data vs input, you cannot test it and you cannot defend it.

The rest of this track is how those four parts fail: examples that steal the format, thought that never terminates, tags that do not close, injection that rides tool text, evals that score the poem, and the OS an agent actually reads.

Tip:If a teammate cannot highlight instructions, context, input, and contract in five seconds, the prompt is not ready for an agent loop.