Agent Prompt Patterns

Battle-tested patterns for agents that ship, not agents that demo.
If your agent works in a live-fire notebook but breaks in production, you have a demo, not an agent.

---

When to Use

• - Designing a new agent's behavioral rules and operating manual
• An agent is hallucinating completions, skipping steps, or claiming work it didn't do
• Building multi-agent pipelines where output quality compounds (or collapses)
• Setting up human-in-the-loop approval tiers for different risk levels
• Enforcing reliability in automated workflows (cron jobs, scheduled tasks, pipelines)
• Writing AGENTS.md or operating manuals for production agent workspaces
• Debugging why an agent keeps violating rules you've already stated
• Evaluating whether an agent should exist at all (deletion test)
• Building harnesses that make autonomy safe and useful

When NOT to Use

• - One-shot prompts with no agent persistence — these patterns assume continuity
• Pure chatbot / conversational UX with no action-taking capability
• Academic prompt engineering research — these are production patterns, not benchmarks
• Agents with no filesystem, no tool access, and no side effects — nothing to harness
• You're still in the "make it work at all" phase — get basic functionality first, then harden

---

1. Consumer-First Design

Principle: Every agent output must have a named consumer. If nobody uses the output, the agent shouldn't exist.

This is the most important pattern because it kills bloat before it starts. Agents proliferate. Each one feels useful when you build it. Six months later you have 14 agents and can't remember what half of them do.

The Deletion Test

Ask: If I delete this agent, which other agent's work breaks?

If the answer is "nothing" or "I'm not sure," the agent is a vanity project.

CODEBLOCK0

How to Apply

Every agent entry in your operating manual should answer:

1. 1. Who consumes this output? (name the human or agent)
2. What format do they need? (not what's convenient to produce)
3. What breaks if this stops? (the deletion test)
4. What's the feedback loop? (how does the consumer signal quality issues?)

If an agent produces beautiful summaries that nobody reads, it's burning tokens for nothing.

Anti-Pattern: The "Nice to Have" Agent

CODEBLOCK1

---

2. Proof-of-Work Enforcement

Principle: Never claim done unless the action actually started. Every status update needs proof — PID, file path, URL, command output. No proof = didn't happen. Write first, speak second.

This pattern exists because LLMs are pathological completers. They want to say "Done!" because that's the satisfying end of a sequence. The problem is they'll say "Done!" before doing anything, or after attempting something that silently failed.

The Rule

CODEBLOCK2

Examples

CODEBLOCK3

Implementation Pattern

CODEBLOCK4

Agent Operating Manual Rule

CODEBLOCK5

---

3. Cascading Validation

Principle: Dependent sequential steps — each task validates the previous output before starting its own work. Failures loop back with fix instructions, not silent continuations.

Cascading validation prevents the "garbage in, garbage out" problem in multi-step pipelines. Without it, step 3 happily processes the corrupt output of step 2, and you don't discover the problem until step 7.

The Pattern

CODEBLOCK6

Example: Content Pipeline

CODEBLOCK7

Key Rule: Never Trust Upstream

Even if Step 1 "passed," Step 2 should re-validate Step 1's output before proceeding. This catches:

• - Race conditions (output modified between steps)
• Silent corruption (file written but content wrong)
• Upstream validation bugs (Step 1's validator had a gap)

Implementation

CODEBLOCK8

---

4. Advisory Mode Tiers

Principle: Not all actions carry the same risk. Categorize agent capabilities into tiers with different autonomy levels and approval requirements.

The mistake people make is binary: either the agent can do everything, or it can do nothing. Tiers let you give autonomy where it's safe and require approval where it's not.

The Four Tiers

Tier	Risk	Probation	Graduation	Example
Low	Reversible, internal only	3 days	Self-promote after clean streak	Read files, search, summarize
Medium

Visible to user, recoverable | 2 weeks | Human approves promotion | Create files, edit code, run tests | | High | Visible to others, hard to reverse | 2 weeks minimum | Never fully unsupervised | Git push, create PRs, post to Slack | | Restricted | Irreversible or impersonation risk | Permanent | Always draft-only | Send email from user's account, delete data, financial transactions |

Critical Rule: Email = Restricted

Sending email from a user's account is always Restricted tier. No exceptions. No graduation. Always draft-only with human send.

Why: Email is identity. An AI sending email "as you" creates legal, professional, and trust risks that no amount of testing eliminates.

CODEBLOCK9

Probation Protocol

CODEBLOCK10

---

5. Completion Contracts

Principle: Every automated workflow needs binary done-criteria, observable evidence, staged approval, and timeout bounds. No "probably done" — it's done or it's not.

The Contract Template

CODEBLOCK11

Example: Deployment Contract

CODEBLOCK12

---

6. Cross-Validation

Principle: Generate with one model, review with another. Different architectures catch different blind spots.

Single-model pipelines have correlated failure modes. If Claude hallucinates a fact, Claude reviewing its own work will often confirm the hallucination. A different model (or a human) brings uncorrelated errors.

The Sub-Agent QC Workflow

CODEBLOCK13

This isn't about which model is "better." It's about error decorrelation. Each reviewer catches things the others miss.

Implementation

CODEBLOCK14

When Cross-Validation Matters Most

• - Legal or compliance content — different models interpret regulations differently
• Financial calculations — arithmetic errors are model-specific
• Factual claims — hallucination patterns differ across architectures
• Security reviews — different models catch different vulnerability classes

When It's Overkill

• - Internal notes nobody else will read
• Ephemeral content (daily logs, scratch work)
• Tasks where speed matters more than correctness
• Outputs with automated validation (tests, linters) that catch errors mechanically

---

7. Rule Escalation Ladder

Principle: Rules start as prose. If violated, they escalate to loaded rules. If violated again, they become script gates. Critical rules skip the ladder entirely.

The problem with prose rules is enforcement. An agent "knows" the rule but still violates it under pressure (long context, competing instructions, ambiguous situations). The escalation ladder adds mechanical enforcement for rules that matter.

The Three Levels

CODEBLOCK15

Escalation Protocol

CODEBLOCK16

Script Gate Example

CODEBLOCK17

---

8. Heartbeat Protocol

Principle: Periodic health checks batched together. Context monitor, system health, memory maintenance — all in one scheduled pulse, not scattered across individual crons.

Heartbeat vs. Cron Decision

Use Heartbeat When	Use Individual Cron When
Check is lightweight (< 30 seconds)	Task is heavyweight (minutes)
Multiple checks share context

Task is completely independent | | Failure in one check should inform others | Task has its own retry/error handling | | You want a single "system status" view | Task needs its own schedule (not aligned) |

Heartbeat Structure

CODEBLOCK18

Implementation

CODEBLOCK19

---

9. Contradiction Detection

Principle: Actively scan for conflicts between memory entries, between memory and SOUL, stale facts, and decision reversals. Don't wait for contradictions to cause errors — find them during maintenance.

Contradiction Types

Type	Description	Example
Memory-Memory	Two memory entries say opposite things	"Client prefers email" vs "Client prefers Slack"
Memory-SOUL

Memory contradicts core identity/rules | SOUL says "never auto-send email" but memory says "auto-send enabled for digest" | | Stale Facts | Memory entry is outdated | "API endpoint: api.v1.example.com" when v1 was deprecated | | Decision Reversal | decisions.md contradicts earlier decision without noting the change | "Use PostgreSQL" then later "Use SQLite" with no migration note |

Scan Protocol

CODEBLOCK20

Example Contradiction Report

CODEBLOCK21

---

10. Tight Harness Principle

Principle: Autonomy gets useful when the harness is tight. Don't sell agents — sell harnesses. An agent without a harness is a liability. A harness without an agent is just a script.

The Five Harness Components

Every autonomous agent operation needs all five:

Component	Question	Example
Objective Metric	How do we know it worked?	"Test suite passes" not "code looks good"
Bounded Scope

What can it touch? | "Only files in /src/api/" not "any file" |
| Time Budget | When does it stop? | "15 minutes max" not "when it's done" |
| Reversibility | Can we undo it? | "Git branch, not direct commit to main" |
| Observability | Can we see what it did? | "Full command log" not "trust me" |

The Key Insight

Most agent failures aren't capability failures — they're harness failures. The agent could do the task, but:

• - Nobody defined "done" objectively (no metric)
• It modified files it shouldn't have (no scope bound)
• It ran for 3 hours burning tokens (no time budget)
• It pushed directly to main (no reversibility)
• Nobody could tell what it did (no observability)

Harness Configuration Example

CODEBLOCK22

Selling Harnesses, Not Agents

When someone asks "can your agent do X?" — the right answer is "here's the harness that makes X safe":

CODEBLOCK23

The harness IS the product. The agent is just the engine inside it.

---

Quick Reference: Pattern Selection Guide

Situation	Pattern
"Should this agent exist?"	Consumer-First Design (#1)
"Agent says it's done but I don't believe it"

Proof-of-Work (#2) |
| "Multi-step pipeline keeps producing garbage" | Cascading Validation (#3) |
| "How much autonomy should this agent have?" | Advisory Mode Tiers (#4) |
| "When is this workflow actually done?" | Completion Contracts (#5) |
| "Agent keeps making the same kind of error" | Cross-Validation (#6) |
| "Agent keeps violating a rule" | Rule Escalation Ladder (#7) |
| "How do I monitor agent health?" | Heartbeat Protocol (#8) |
| "Agent's memory is inconsistent" | Contradiction Detection (#9) |
| "How do I make autonomy safe?" | Tight Harness Principle (#10) |

---

Combining Patterns

These patterns are composable. A production agent typically uses several together:

CODEBLOCK24

Start with #1 (does this agent need to exist?) and #10 (is the harness tight?). Add the others as complexity demands.