agentic-prompt-design

name

agentic-prompt-design

description

Craft guide for AUTHORING a prompt that drives an agent/executor (one node in a workflow, or a standalone agent) to produce THOROUGH, SUBSTANTIAL, bar-meeting output instead of thin/literal/minimal work. TRIGGER when writing or rewriting a prompt that another model executes — a workflow/pipeline node, an `agent()`/sub-agent prompt, a system prompt for a coding/generation/analysis agent — ESPECIALLY when the executor is a cheaper/weaker/non-frontier model (MiniMax, 7B/SLM, Haiku-tier, DeepSeek Flash) and output comes back minimal, or when you need to put an acceptance bar / rubric / "definition of good" into the prompt. Covers: specifying the bar in-prompt, eliciting elaboration/coverage, exemplars, decomposition, self-critique passes, and node/handoff contracts.

Agentic Prompt Design — making executors produce substantial, bar-meeting output

Synthesized from vendor docs (Anthropic, OpenAI), peer-reviewed work (Self-Refine, SLM-scaffolding), and strong practitioner playbooks (2026-06). Full provenance + 35 cited sources in references/research-and-sources.md. Tags inline: [O] official vendor · [R] research · [P] practitioner.

When to use

You are writing a prompt that another model executes and you need that output to be thorough and meet a quality bar — a workflow/pipeline node, an agent() call, a sub-agent, a generation/analysis/coding agent — and especially when the executor is cheaper/weaker and keeps returning thin, literal, minimal work.

0. The one root cause (read this first)

Thin, literal, minimal output is a specification gap, not a model defect. The model fills any unstated intent with its shortest plausible interpretation — it places exactly the entities you named and stops; it declares victory early; it summarizes what it "would" do. [P, O] More doctrine/exhortation in the prompt does NOT fix this — you must make the bar explicit, observable, and enumerable so "do more" has a defined target the model can aim at and check itself against. Models optimize for the criteria you state. [P] Two consequences that drive everything below:

• If you want "above and beyond," request it explicitly. Vendors say this outright: vague prompts get the model's judged-minimal effort; the cure is naming the depth/coverage you expect. [O]
• State the scope; don't rely on generalization. Literal executors "do not silently generalize an instruction from one item to another, and do not infer requests you didn't make." If the bar should apply to every entity/section, say so. [O]

1. The node-prompt skeleton (label every slot)

A prompt that drives an executor is a contract, not a wish. Use stable sections (XML tags or ## headers — both parse reliably; tags are safest for weak models). [O,P] Order matters for weak executors: put the output shape near the top so the model "knows where it's going from the first token." [P]

<role>          who the executor is + the standard it holds itself to (a senior/expert framing raises the floor) [O,P]
<inputs>        exactly what it receives, with file paths / field names; inject the FACTS it needs (don't let it guess) [P]
<task>          the single concrete job (one node = one job for weak models) [P]
<output_spec>   exact shape/schema/length/section list — define this FIRST for weak executors [P]
<the_bar>       acceptance criteria + what "good vs minimal" looks like here (§3) — the load-bearing slot
<coverage>      quantity/breadth targets that forbid stopping at the obvious (§2)
<constraints>   MUST / MUST NOT (weak models need explicit negatives) [P]
<self_check>    a required pass: verify each bar item; revise before returning (§4)
<scope_fence>   for pipeline nodes: what is OUT of scope (the next node's job) + the failure path (§5)

You won't need every slot every time, but <the_bar>, <coverage>, and <self_check> are the ones that actually move thin → substantial. Don't ship without them when thinness is the problem.

2. Eliciting THOROUGHNESS / ELABORATION (the anti-minimalism levers)

This is the half that fixes "placed the few named entities and stopped." Pick several:

1. The "go beyond the basics" modifier (vendor-canonical). Append depth modifiers to the task. [O]
   • Before: Design the level.
   • After: Design the level. Include as many relevant elements, interactions, and pacing beats as the archetype supports. Go beyond the obvious — produce a fully-fleshed, content-rich design, not a minimal placement of the named entities.
2. Enumerate the target — externalize "what full looks like." The strongest anti-thinness move from long-running-agent research: don't trust the model to know when it has done enough — give it the inventory. Either list the required components, or have the prompt generate an explicit checklist of everything a complete deliverable contains, then build against it (Anthropic's harness expanded one prompt into 200+ enumerated features, each marked "failing," so the model had a concrete outline of "done"). [O] In-prompt: First, enumerate every component a complete <X> must contain for this case (aim for N+). Then produce each one in full. Do not stop until every enumerated item is present.
3. Coverage / quantity floors. Give countable minimums: "at least N distinct …", "every section gets 2–3 developed paragraphs", "handle each item one by one — output all of them in full." Models will under-produce open-endedly but hit a stated floor. [P,O]
4. Anti-laziness anchors (drop in verbatim). [P] Be exhaustive; err toward too much rather than too little. · Do not summarize what you would do — do it. · Do not use "etc.", "and so on", or "…". Show the actual work. · Implement each step fully; no placeholders.
5. Describe the output, don't just name a role. "Produce the design a senior level-designer would ship — leading with the core loop, then elaborating threats, pacing, and reward placement" beats "act as a level designer." Describing the artifact does the work; naming a role only hopes the model fills it in. [P]
6. Raise effort / "think first" — but targeted. For reasoning-capable executors, "think thoroughly before producing" or a higher effort setting lifts depth. (For strong frontier models, prefer this over rigid step-lists; for weak models, see §6 — they need the steps.) [O]

⚠️ Don't over-do it on strong frontier models. Modern frontier models calibrate length to task complexity and can overtrigger on aggressive "BE EXHAUSTIVE / always use X" language. These levers are for thin output; if the executor already over-produces, dial them back. The thin-output problem is overwhelmingly a weak/cheap-executor and vague-prompt problem. [O]

3. Specifying THE BAR in-prompt (acceptance criteria / rubric / "good vs minimal")

Stop asking for "a good X"; ask for an X that passes a spec. Write the acceptance criteria before the prose of the prompt. [P]

• Acceptance criteria block — Must / Must / Must not. "Must not" is the most underrated line: it kills the "helpfully add fluff" and the "stop at the minimum" failure modes. [P] Make each criterion pass the 5 C's: Countable, Constrained, Comparable, Checkable, Cheap-to-review. [P]
• In-prompt rubric — when "good" is judgment-heavy, paste a small scored rubric: each row = criterion · what passing looks like · failure signature. Mark rows Required vs Optional; "if any Required criterion is unmet, the output fails — revise." Anchor with observable evidence, not adjectives ("excellent" means nothing; "names a threat on the player's path within the first room" is checkable). [P]
• Contrast good vs minimal explicitly. One line that names the failure you keep getting is worth a paragraph: A MINIMAL answer just places the named entities and stops — that FAILS. A GOOD answer elaborates <the specific dimensions>.
• Replace quality words with structure. "professional summary" → "3 sentences: outcome / method / metric." Defining the structure is the single highest-impact specificity lever. [P]
• Show the standard (exemplar). One concrete exemplar of bar-meeting output is the specification — it calibrates depth, tone, and judgment better than paragraphs of description. "If the example is two crisp sentences, the model is concise; if it's a rich analysis, the model goes deep." Use 1 (weak models) to 3–5 (strong) diverse, canonical examples in <example> tags; curate — don't dump a laundry list of edge cases. [O,P]

4. The self-critique / self-expansion pass (cheap, high-yield)

Add a required second pass so a thin first draft gets caught and expanded inside the same node. [R,O,P]

• Make the check mandatory, with named criteria: Before returning, audit your output against each item in <the_bar>. For each, mark PASS/FAIL with one line of evidence. Revise every FAIL, then re-audit. Only return output where every Required item is PASS. Generic "review and improve" yields nothing; named criteria yield real revision. [P,R]
• Two-pass expansion for thinness specifically: Draft 1: produce the design. Self-critique: list what a more thorough version would add (coverage gaps, under-developed areas). Draft 2: incorporate every gap. Return Draft 2 only. [P]
• Separate critique from rewrite — bundling them makes the model rewrite without engaging the critique. [P]
• Know the ceiling: self-critique polishes errors it can't see (≈5–7% self-enhancement bias). For a hard quality bar, put the critique in a separate node/model (a critic stage has a forced perspective shift a self-review can't fake) rather than trusting self-review. [P]

5. Node / hand-off contracts (one node in a deterministic pipeline)

When the prompt is one station in a workflow, the interface between stations matters more than the prose inside one. [P] Pin each of these or the pipeline drifts:

• Read THIS → write THAT. Name the exact input artifact(s)/path(s) the node consumes and the exact output artifact/schema it produces. Free-text between agents is fragile; emit structured output (JSON / typed fields / a named file) the next node can parse. [P]
• Scope fence. State what's OUT of scope: Do NOT do <next node's job>. Drift is usually a missing fence. [P]
• Failure path. If <input> is missing/wrong-shape or a required value is absent: HALT and emit <signal> — never invent the value. (Critical when downstream nodes trust this output.) [P]
• Hand-off payload = semantic fields, not transcript. Pass task_state / findings / decisions / open_questions / artifacts, not the raw working history. Sub-agents should return a condensed distilled summary, not their full context. [O,P]
• Right altitude. Between brittle hardcoded if-else and vague hand-waving: specific enough to guide, flexible enough to leave the model strong heuristics. [O]

6. Prompting WEAKER / CHEAPER executors (MiniMax / 7B / SLM / Haiku-tier) — where it breaks & the fix

Weak models fail predictably: patchy knowledge, weak long-chain reasoning, low instruction adherence ("give 5 requirements, it satisfies 1"), format instability. Frontier tricks (vague instructions, long preambles, implicit format) actively degrade them. They don't reward clever prompts — they reward clear contracts. [P,R]

• One node = one job. Split multi-part asks; collapse conditional logic. If the model confuses two flows, reduce the problem space, don't add explanation. [P]
• Move complexity into code, not the prompt. State detection, branching, flow control belong in the harness; give the model a single-purpose, well-defined task. Reserve its capacity for generation/extraction. [P]
• Inject the facts; forbid guessing. Give the numbers/definitions/context inline (FACTS — use only these:). Add failure behavior: If a needed value is missing, output INSUFFICIENT_DATA — do not fabricate. [P]
• Schema-before-task + a strict format contract. Output shape first (structural prior). One matched example. Add a negative example to kill conversational bleed ("Sure! Here's the JSON:"). [P]
• Decompose explicitly — it's a generative scaffold for them (and only them). Research: decomposition gives large accuracy gains for ≤70B models and ~zero for frontier. Provide the ordered steps / a reusable blueprint (extract the step-by-step plan once, hand it over verbatim). PLAN → FOCUS → ACT → VERIFY. [R,P]
• Fight instruction decay: repeat the critical rule before AND after long inputs (a post-input reminder tag: <output_only>…schema…</output_only>). Pin ONE format and reuse it byte-for-byte — SLMs are hypersensitive to template/whitespace variation. [P]
• Repair loop, not one-shot. Expect a second turn: You missed <field/section>. Regenerate only that part.
• Calibrate the bar on the frontier model, run it on the cheap one. Define "what good looks like" (and your exemplar) with a strong model; verify the cheap model can hit it. [P]

7. Anti-patterns (what to delete / never do)

• ❌ Adding more doctrine/exhortation to fix thinness. ✅ Add an explicit, enumerable bar + coverage floor
  • self-check. The oracle is the spec, not the pep talk.
• ❌ "Be thorough / make it good / comprehensive" with no definition. ✅ Countable criteria, an exemplar, a named good-vs-minimal contrast.
• ❌ Negative-only steering ("don't be brief"). ✅ Tell it what TO do, and add the why — motivated rules ("elaborate X because the QA gate checks for it") generalize better than bare commands. [O,P]
• ❌ Piling edge cases / a laundry list of rules into one node. ✅ A few canonical examples + the bar; split nodes for weak models. [O,P]
• ❌ Free-text hand-offs between nodes. ✅ Structured artifact + scope fence + failure path. [P]
• ❌ Trusting self-critique as a hard gate. ✅ Separate critic node when the bar is non-negotiable. [P]
• ❌ Reward-hackable checks (asserting unobservable intent). ✅ Acceptance criteria over OBSERVABLE output only.
• ❌ Reusing aggressive anti-laziness language on a strong frontier executor that already over-produces (causes overtriggering/overthinking — dial back). [O]

8. Diagnose-and-fix loop (when output is still thin)

1. Re-read the prompt as the executor: where did I leave room to do less? (the intent gap). [P]
2. Is the bar enumerable and observable? If not, add the criteria/rubric/exemplar (§3).
3. Is there a coverage floor + a "go beyond the obvious / enumerate-then-build" instruction (§2)?
4. Is there a mandatory self-check against the bar (§4)?
5. Weak executor? Apply §6 — one job, inject facts, schema-first, decompose, repair.
6. Change ONE thing, re-run on a few representative inputs, keep what raises adherence. Don't argue with a bad prompt across ten turns — rewrite it once, well. [P]

Pre-ship checklist

• Output shape/schema specified (near the top for weak executors)
• The bar is in the prompt: acceptance criteria (Must / Must not) or a small rubric, observable
• Good-vs-minimal contrast named, and ≥1 exemplar shown (the example IS the spec)
• Coverage/quantity floor + "go beyond the obvious" / enumerate-then-build present
• Mandatory self-check against the bar (or a separate critic node for a hard gate)
• Constraints include explicit MUST NOTs; instructions are positive + motivated (why)
• Pipeline node: read-this→write-that, structured output, scope fence, failure path (no fabrication)
• Weak executor: one job · facts injected · schema-first · decomposed/blueprint · format pinned · repair-ready
• No reward-hackable checks; no aggressive anti-laziness language aimed at an already-verbose frontier model

Worked example — thin → substantial (a workflow node driving a cheap executor)

Before (returns a minimal placement of named entities):

Design the game level using the entities in spec/classification.json.

After (drives thorough, bar-meeting output):

<role>You are a senior 2D level designer. You ship content-rich, playable designs — never a bare placement
of named objects.</role>
<inputs>Read spec/classification.json (archetype, core loop, named entities) and spec/blueprint.json
(declaredRanges, referenceSolution). Use ONLY values present there; never invent a number.</inputs>
<task>Produce the level design for THIS milestone, as spec/level.json.</task>
<output_spec>JSON: { rooms[], entities[], threats[], pacingBeats[], rewardPlacements[], winPath }. Define
every field; no nulls.</output_spec>
<coverage>First enumerate every element a complete level of this archetype contains (aim ≥ the
referenceSolution's count). Then produce each in full. Go beyond the named entities — a MINIMAL design that
only places them FAILS.</coverage>
<the_bar>Required (revise until all PASS): (1) every named entity placed AND given a role in the core loop;
(2) ≥1 threat on the player's critical path in the first room; (3) a pacing beat between each threat cluster;
(4) a reward within reach of each threat; (5) winPath is completable within declaredRanges. Must NOT: leave
empty rooms, add entities absent from inputs, or output placeholders.</the_bar>
<self_check>Before returning, audit the output against each Required item: mark PASS/FAIL + one line of
evidence. Revise every FAIL and re-audit. Return level.json only.</self_check>
<scope_fence>Do NOT implement code or assets (later nodes). If blueprint.json lacks a required range, HALT
and emit NEEDS_BLUEPRINT — do not guess.</scope_fence>

Provenance

All techniques trace to references/research-and-sources.md (35 external sources: 8 official vendor docs incl. Anthropic prompt-engineering + harness/context-engineering posts and OpenAI guides; 4 peer-reviewed incl. Self-Refine and SLM-scaffolding papers; 23 practitioner playbooks on anti-laziness, rubric-first prompting, 7B/SLM prompting, and multi-agent hand-offs). Research date 2026-06.