The single biggest determinant of what an agent produces is the prompt that frames the work. The model is roughly as capable as it is going to be; what changes between a working request and a failing one is the prompt — the role, the task, the constraints, and the examples.

This piece walks through the four pieces and names the failure modes that show up when each piece is missing. It is meant as a checklist for any new request to an agent.

The four-piece pattern

Every useful request to an agent has the same four pieces. The order matters less than the presence of each one.

1. Role. What kind of work is this? "You are a code reviewer." "You are a research summarizer." "You are a triage operator." The role frames the model's defaults — what it notices, what it ignores, what it treats as success. 2. Task. What is the specific thing to do? "Find the three slowest tests in the suite." "Summarize the meeting transcript into five bullets." "Triage the inbox into today, this week, and ignore." The task is one sentence. If it cannot fit in one sentence, it is not yet a task. 3. Constraints. What are the limits? Length, format, scope, forbidden tools, audience, deadline. "In under 200 words." "In markdown table format." "Do not call external APIs." "Audience is a non-technical operator." 4. Examples. What does a good answer look like? One example is enough. Two examples are usually too many. The example shows the model the shape of the answer, not the answer itself.

The four pieces fit on one screen. A request that does not fit on one screen is a request that has not been thought through.

Why each piece matters

Role

Without a role, the model defaults to "general assistant." That default is fine for casual conversation; it is bad for agent work, because the agent's defaults leak into places they should not. A code reviewer that has not been told it is a code reviewer will spend half its response explaining the code's purpose instead of reviewing it.

The role is not a costume. It is a set of defaults. Naming the role commits the model to those defaults.

Task

Without a task, the model defaults to "tell me more." That default produces agents that ask clarifying questions instead of doing work. The clarifying questions are sometimes useful; more often they are a stall tactic that delays the real work.

A specific task is one sentence. "Find the three slowest tests." "Summarize the meeting." "Triage the inbox." If the task is longer than one sentence, it has not been broken down yet. Break it down.

Constraints

Without constraints, the model produces whatever it thinks makes sense. That output is often too long, in the wrong format, addressing the wrong audience, or calling tools it should not call.

The constraints piece is the cheapest part of the request and the most skipped. A useful set of constraints:

  • Length. "Under 200 words" or "no more than five bullets."
  • Format. "Markdown table" or "JSON" or "plain prose."
  • Scope. "Only files in this folder." "Only the last 30 days." "Only public APIs."
  • Forbidden tools. "Do not call the network." "Do not modify any files."
  • Audience. "For a non-technical operator." "For a senior engineer."
  • Deadline. "Decide in under 60 seconds." "Produce one decision, not five."

Each constraint narrows the output. The narrower the output, the more useful it is.

Examples

Without examples, the model guesses at the shape of the answer. The guess is usually close. Sometimes it is exactly right. Often it is close enough to be unhelpful — the audience expects one shape and gets another.

One example is enough. Two is too many. The example shows the shape — what the model should produce, not what it should say. The example's content can be invented. The shape is what matters.

A useful example has the same constraints the real task has, in the same format, on the same kind of input. The example is the spec, in concrete form.

Failure modes when each piece is missing

  • No role. The model defaults to general assistant. Output is verbose, hedged, and unfocused.
  • No task. The model defaults to clarifying questions or to doing the wrong thing. Output is meta instead of substantive.
  • No constraints. The model produces whatever it thinks makes sense. Output is the right shape about half the time and the wrong shape about half the time.
  • No examples. The model guesses at the shape. Output is close but not quite right; the audience has to interpret.

Each missing piece produces a different kind of failure. The fix is to add the missing piece, not to add more words elsewhere.

Common questions

Do I always need all four pieces?

No. Casual conversation works without them. The four pieces matter when the output has to be specific, auditable, or reproducible. The more the output matters, the more the four pieces matter.

Does the order matter?

No. The pieces can appear in any order. The presence of each piece matters more than the order.

Can the four pieces live in a system prompt?

Yes. Many agent systems put the role in the system prompt and the task, constraints, and examples in the user prompt. That is fine. The system prompt is the agent's persistent role; the user prompt is the agent's current task.

What about chain-of-thought?

Chain-of-thought is one specific technique — asking the model to reason step by step before producing the final answer. It is useful for some tasks and harmful for others. The four-piece pattern is broader; chain-of-thought is one constraint that might appear in the constraints piece.

Takeaway

A good request to an agent has four pieces: role, task, constraints, examples. Each piece fixes a different failure mode. The model is roughly as capable as it is going to be; what changes the output is the prompt. Spend the time on the prompt. The agent will spend its time on the work.

The rest of this manual goes deeper on the kinds of work agents do — research, file work, automation, multi-step orchestration. The four-piece pattern is enough to read any of them.