---
title: "7 System Prompt Patterns Every Agent Operator Needs"
author: Melisia Archimedes
collection: C1 Persona Forge
tier: pollen
price: free
version: 1.0
last_updated: 2026-03-09
audience: agent_operators
hive_doctrine_id: HD-1017
sources_researched: [system prompt engineering guides, constitutional AI research, production agent configurations, prompt optimization studies]
word_count: 1150
---

# 7 System Prompt Patterns Every Agent Operator Needs

Your system prompt is your agent's DNA. Get it wrong and every downstream decision is broken.

Most people treat system prompts like personality fill-ins: "Be helpful. Be honest. Be friendly." That works fine for chatbots answering customer support tickets. But if you're running agents that make decisions, route tools, integrate with production systems, and need to hand off to humans when things get weird—generic personality prompts are liabilities.

The difference between a system prompt that works and one that fails at scale comes down to architecture. Seven specific patterns emerge from production agent systems that actually stay operational. They're not about tone. They're about decision-making structure, failure modes, and the hard boundaries between what your agent can do and what it can't.

## Pattern 1: Constitutional Boundary

This is the traffic light, not the instruction manual. Every agent needs a short, non-negotiable rule about what it will refuse, what it will report, and what it will escalate. Constitutional boundaries aren't personality traits—they're circuit breakers.

A constitutional boundary tells your agent: "If someone asks you to delete production data without three-factor verification, stop. Report it. Don't argue about whether you're helpful enough." The boundary lives at the top of your system prompt because it runs before reasoning starts.

**Example snippet:**
```
CRITICAL: You will not execute destructive operations (delete, drop, truncate) on production databases without explicit user confirmation in the chat interface plus a confirmation code. Escalate immediately if this is attempted.
```

Why this matters: Without boundaries, your agent optimises for being helpful. With boundaries, it optimises for being safe first, then helpful.

## Pattern 2: Tool Routing Logic

Agents aren't magic. They're decision trees that route requests to the right tool at the right time. Your system prompt needs to encode which tool solves which problem—not as suggestions, but as deterministic logic.

Tool routing is where most agent failures happen. An agent will call a web search for something it should query from local context. It will call a database tool when it should read a cached file. It will make three API calls when one structured request would work.

Your system prompt needs to explicitly state: "IF the user asks about recent events AND you have access to a news API AND local caching is stale, THEN call the news tool. ELSE check cached results first."

**Example snippet:**
```
IF query is about [financial data] AND filesystem has recent [stock.db], THEN read local database first. IF data is older than 1 hour, refresh via API. IF user asks for [real-time], always use API regardless of cache age.
```

Why this matters: Tool routing eats 40% of an agent's token budget. Get it wrong and you're burning compute on the wrong tool twice as often.

## Pattern 3: Output Format Enforcement

Agents that integrate with other systems (dashboards, databases, downstream agents) need structured output. But agents don't naturally produce JSON. They produce prose. Your system prompt needs to enforce format.

Format enforcement isn't about asking nicely—"Please format your response as JSON"—it's about making format violation impossible. Your prompt needs to say: "Your response must be valid JSON, nothing else. If you cannot respond in JSON, respond with `{"error": "reason"}`."

The trick is making the format requirement non-negotiable before the agent starts reasoning. If format is negotiable, the agent will negotiate.

**Example snippet:**
```
ALL responses must be valid JSON with schema: {"action": string, "rationale": string, "confidence": float 0-1}. Respond with only JSON. No markdown, no prose, no preamble. Invalid JSON = failed response.
```

Why this matters: When your agent talks to other systems, prose is useless. Structured output is the difference between integration and debugging.

## Pattern 4: Escalation Protocol

Every agent hits a wall. A request is ambiguous. A tool fails. A user is asking something the agent isn't designed to handle. Without an escalation protocol, agents either refuse everything or attempt everything and fail.

Your escalation protocol needs to be specific: "If you're ≥80% uncertain about a decision, escalate. If a tool returns an error three times, escalate. If the user is asking you to override a safety boundary, escalate immediately." Escalation isn't failure—it's the right tool for situations the agent can't handle.

**Example snippet:**
```
ESCALATION: If confidence < 80%, if a tool fails 3x consecutively, or if user requests override a constitutional boundary, DO NOT RETRY. Format escalation as: {"escalate_to": "human_operator", "reason": "...", "context": {...}}
```

Why this matters: Agents that know when to fail are more reliable than agents that try to succeed at everything.

## Pattern 5: Error Recovery

Things break. API timeouts. Network latency. Invalid responses. Your agent needs to know how to recover, and your system prompt needs to encode the recovery playbook.

Error recovery isn't "try again." It's: "Try the fast path. If it times out, try the cached fallback. If that fails too, escalate with the original error and the fallback result." Recovery strategies vary by tool type and failure mode.

**Example snippet:**
```
IF API call timeout after 10s, attempt local cache lookup. IF cache miss, wait 5s and retry once. IF retry timeout, escalate with error: {"original_timeout": true, "cache_available": false}.
```

Why this matters: Resilience is the difference between an agent that works 98% of the time and one that works 99.5% of the time. At scale, that's the difference between operational and on-fire.

## Pattern 6: Memory Integration

Agents that use retrieved context (from databases, vector stores, previous interactions) need explicit rules about how to weight and integrate that context into decisions. Without those rules, agents either ignore memory or over-trust it.

Your system prompt needs to say: "Always cite the source of your context. If context is older than 24 hours, mark it as stale. If two sources conflict, flag the conflict and ask the user which takes priority." Memory integration rules prevent hallucination and make reasoning auditable.

**Example snippet:**
```
For every retrieved fact, cite its source and timestamp. If sources conflict, format as: {"fact": "...", "sources": [{source, timestamp, confidence}], "conflict_resolved_by": "user_guidance"}. Never assert a fact without citation.
```

Why this matters: Cited, timestamped memory is the difference between an agent users can trust and one they have to fact-check.

## Pattern 7: Multi-Agent Identity

When agents work alongside other agents, they need to know: Are they peers? Is one subordinate? How do they communicate? Do they compete or collaborate? Your system prompt needs to encode the social structure.

Multi-agent systems fail when agents duplicate work, contradict each other, or don't know when to hand off. Your prompt needs clarity: "You are peer agent in a collaborative system. Your role is [analysis]. If another agent requests [synthesis], defer to them. Communicate handoffs as: `@AgentName: handoff because [reason]`."

**Example snippet:**
```
You are Agent-A in a collaborative multi-agent system. Primary role: [data_analysis]. DO NOT attempt [synthesis] or [content_generation]—those are Agent-B and Agent-C. Signal handoffs clearly: "@Agent-B: analysis complete, handing off synthesis of..."
```

Why this matters: Multi-agent systems without clear identity and communication protocols devolve into chaos. Structure prevents duplication and enables delegation.

## Implementation: The Three Essentials

These seven patterns aren't optional extras. They're the minimum viable system prompt for an agent that runs in production. Here's how to implement them:

1. **Start with constitutional boundaries** at the top of your prompt—non-negotiable rules before any reasoning starts.
2. **Encode tool routing as conditional logic**, not suggestions. Use IF/THEN, not "prefer to."
3. **Make output format non-negotiable**. Valid JSON or error response—no exceptions.
4. **Define escalation thresholds explicitly**. ≥80% uncertainty? Escalate. Tool failure ×3? Escalate.
5. **Document error recovery paths** for each tool type.
6. **Require citations** for every fact your agent retrieves.
7. **Define multi-agent roles** if your agent isn't operating solo.

Your system prompt isn't a personality. It's an operating manual. The best agent operators treat it like code—versioned, tested, and updated when operational requirements change.

## What's Next

Want 50 ready-to-use system prompts for different agent types? See **Prompt Library: 50 System Prompts** (honey tier) for templates you can adapt to your use case.

Want to standardise agent identity and behaviour across your entire system? The **SOUL.md Standard** (honey tier) shows how to structure agent personality, boundaries, and capabilities in a way that scales across teams and tools.

System prompts are where agent architecture meets execution. Get them right, and your agents stay operational. Get them wrong, and you're debugging forever.

---

*Melisia Archimedes operates agent systems at production scale. She designs the prompts that keep them aligned, bounded, and reliable.*