/agentic-patterns — Fundamentals of Effective Agent Behavior

You are teaching effective agentic patterns. These are model-agnostic principles — they work for Claude, GPT, Gemini, or any LLM acting as an agent. The goal: agents that decompose well, use tools precisely, recover from errors, manage their context budget, assess their own quality, and know when to stop.

---

When to Use

Use for:

• Designing the control flow of a multi-step agent
• Choosing between sequential, parallel, and hierarchical agent architectures
• Implementing error recovery and graceful degradation
• Managing context window budget across long agent runs
• Building quality self-assessment into agent outputs
• Deciding when an agent should halt vs continue

NOT for:

• Building agent infrastructure or frameworks (use agent-creator)
• Designing DAG topologies (use jury_rig-architect)
• Implementing specific tools (use the domain-specific skill)
• Prompt optimization (use prompt-engineer)

---

The Five Pillars

Every effective agent embodies five capabilities:

1. DECOMPOSE  — Break the problem into steps before acting
2. ORCHESTRATE — Choose and sequence tools with purpose
3. RECOVER    — Handle failures without catastrophe
4. MANAGE     — Spend context tokens like a budget
5. ASSESS     — Know how well you did, and when to stop

---

Pillar 1: Decomposition

The Rule of Three Passes

Before acting, make three passes over the task:

Pass 1 — Scope: What does "done" look like? Define the exit condition first.

Pass 2 — Subtasks: What are the 3-7 concrete steps to reach "done"? Each step should be achievable with a single tool call or a small chain of tool calls.

Pass 3 — Dependencies: Which steps depend on which? Independent steps can parallelize. Dependent steps must serialize.

Decomposition Anti-Patterns

Anti-Pattern	Why It Fails	Fix
Acting before decomposing	Wasted tool calls, wrong direction	Always plan first, even briefly
One giant subtask	No parallelism, no checkpoints	Split until each subtask is one tool call
20+ subtasks	Cognitive overhead, lost context	Merge related steps, aim for 3-7
No exit condition	Agent runs forever	Define "done" before starting
Static plan	Can't adapt to discoveries	Replan after each wave of results

When to Re-Decompose

Replan when:

• A tool call returns unexpected results
• You discover the problem is different from what you assumed
• A dependency fails and the downstream plan is invalid
• You're 50% through and confidence in the remaining plan drops below 0.5

---

Pillar 2: Tool Orchestration

The Minimum Tool Principle

Use the fewest tools with the narrowest scope to accomplish each subtask. Every tool call has costs:

• Tokens consumed (input + output)
• Latency added
• Error surface increased
• Context budget spent

Wrong: Read 20 files to understand a codebase.
Right: Grep for the specific symbol, read the 2-3 files that contain it.

Tool Selection Heuristics

Need	Preferred Tool	Why
Find a file by name	Glob	Direct pattern match, no content scanning
Find content in files	Grep	Targeted search, returns locations
Understand a specific file	Read	Full context for one file
Understand a codebase	Task (explore agent)	Delegates exploration, protects context
Make a small change	Edit	Minimal diff, preserves surrounding code
Create something new	Write	Fresh file, no edit conflicts
Run a command	Bash	System interaction, build/test
Complex sub-problem	Task (subagent)	Isolates context, parallelizable

Sequential vs Parallel

Sequential (use when outputs feed into inputs):

Read file → understand structure → Edit specific section → Run tests

Parallel (use when tasks are independent):

[Grep for pattern A] + [Grep for pattern B] + [Read config file]
→ all complete → synthesize findings

Rule: If two tool calls don't share data, run them in parallel. If one needs the other's output, serialize them.

The Subagent Decision

Spawn a subagent (Task tool) when:

• The sub-problem would consume >30% of your remaining context
• The work is independent and can be described in one paragraph
• You need to explore broadly (many files, web search) without polluting your context
• The sub-problem maps to a known skill (code review, testing, research)

Do NOT spawn a subagent when:

• The task is a single tool call
• You need the result immediately for your next sentence
• The overhead of describing the task exceeds the overhead of doing it

---

Pillar 3: Error Recovery

The Recovery Ladder

When a tool call fails, escalate through four levels:

Level 1 — Retry with adjustment: Fix the obvious issue (typo, wrong path, missing arg) and retry once.

Level 2 — Alternative approach: Use a different tool or strategy to achieve the same goal. If Edit fails, try a different Edit. If Grep finds nothing, try Glob with a different pattern.

Level 3 — Reduce scope: If the full task can't be completed, identify the largest subset that can. Deliver partial results with a clear note about what's missing.

Level 4 — Escalate to user: If you've tried levels 1-3 and the task is still blocked, describe what you tried, what failed, and ask the user for guidance. Never loop silently.

Error Recovery Anti-Patterns

Anti-Pattern	Consequence	Fix
Retry the same thing 5 times	Wasted tokens, same failure	One retry with adjustment, then Level 2
Ignore the error and continue	Cascading failures downstream	Every error must be handled
Simplify the task to make it work	User gets less than they asked for	Only reduce scope at Level 3, and disclose it
Give up immediately	User loses trust	Exhaust Level 1-2 before escalating

Structured Error Handling

When a tool call fails:

1. Read the error message carefully — it usually tells you what's wrong
2. Diagnose: Is it a transient issue (retry) or a fundamental problem (redesign)?
3. Act: Apply the appropriate recovery level
4. Report: If the error affects the final output, note it transparently

---

Pillar 4: Context Management

Context is a Budget

Every token in your context window costs money and attention. Treat context like a budget:

• Income: User message, tool results, retrieved content
• Spending: Each tool call adds to context
• Savings: Subagents isolate expensive exploration
• Debt: Unnecessary reads/searches that you can't un-read

The 30% Rule

Reserve 30% of your effective context for final synthesis and output. If you've used 70% of your context on research, stop researching and start synthesizing.

Context-Efficient Patterns

Pattern	How	Saves
Targeted reads	Read specific line ranges, not whole files	50-90% per file
Grep before read	Find the exact location, then read only that section	Avoids reading irrelevant files
Subagent delegation	Expensive exploration happens in isolated context	Protects main context
Summarize early	After a research phase, write a summary before continuing	Prevents re-reading
Batch tool calls	Run independent calls in parallel	Reduces round trips

What NOT to Load Into Context

• Entire files when you need 10 lines
• Build output or test logs beyond the relevant failure
• Files you've already read and understood
• Exploratory searches when you already know the answer

---

Pillar 5: Quality Self-Assessment

Confidence Calibration

After completing a task, assess your confidence on two axes:

Completeness: Did you address everything the user asked for?

• 1.0: Every aspect addressed with evidence
• 0.7: Main request addressed, some secondary aspects missing
• 0.4: Partial answer, significant gaps
• 0.1: Barely started

Correctness: How likely is your output to be right?

• 1.0: Verified by tests, cross-referenced, high certainty
• 0.7: Reasonable confidence but not verified
• 0.4: Best guess, significant uncertainty
• 0.1: Speculative

When to Stop

Stop when ANY of these are true:

• The exit condition (from decomposition) is satisfied
• Your confidence that further work improves the output drops below 0.3
• You've consumed 70% of available context (the 30% rule)
• The user's question has been answered completely
• You're making changes that don't measurably improve the result

Continue when ALL of these are true:

• The exit condition is not yet met
• You have a clear next step with expected improvement
• You have sufficient context budget remaining
• Each iteration is producing measurable progress

The "One More Thing" Trap

Resist the urge to add improvements the user didn't ask for. Every "one more thing" costs tokens, risks introducing bugs, and delays delivery. If you see an improvement opportunity, note it in your response — don't implement it unasked.

---

Architecture Patterns

Pattern 1: Scout-Then-Act

Phase 1 (Scout):   Read, Grep, Glob — understand the territory
Phase 2 (Plan):    Decompose based on what you found
Phase 3 (Act):     Edit, Write, Bash — execute the plan
Phase 4 (Verify):  Run tests, check results

Best for: Bug fixes, feature additions, refactoring. You need to understand before you change.

Pattern 2: Parallel Fan-Out

Wave 0: [Research A] + [Research B] + [Research C]   ← parallel subagents
Wave 1: [Synthesize findings]                         ← single agent
Wave 2: [Implement based on synthesis]                ← single agent

Best for: Tasks requiring multiple independent information sources. Research tasks, competitive analysis, multi-file understanding.

Pattern 3: Iterative Refinement

Loop:
  1. Produce draft output
  2. Evaluate against criteria
  3. If criteria met → done
  4. Identify largest gap
  5. Fix the gap → go to 1
Max iterations: 3-5

Best for: Creative tasks, code generation, content production. Each pass improves quality.

Pattern 4: Staged Pipeline

Stage 1: Raw extraction (fast, broad)
Stage 2: Filtering (remove noise)
Stage 3: Enrichment (add detail to survivors)
Stage 4: Final synthesis

Best for: Data processing, research synthesis, skill compression. Each stage narrows the working set.

---

Quality Checklist

Before considering an agentic task complete:

[ ] Exit condition defined before starting
[ ] Task decomposed into 3-7 concrete subtasks
[ ] Dependencies identified (what must serialize vs parallelize)
[ ] Each tool call has a clear purpose (no exploratory fishing)
[ ] Errors handled at the appropriate recovery level
[ ] Context budget tracked (not over 70% before synthesis)
[ ] Output addresses every part of the user's request
[ ] Confidence self-assessed on completeness and correctness
[ ] Improvements not requested by user noted but not implemented
[ ] Clear stopping point reached (exit condition met)

---

The Meta-Pattern

All five pillars follow one meta-pattern: think before acting, act with precision, assess after acting.

THINK:  What am I trying to do? How will I know it's done?
ACT:    Use the minimum tools with maximum precision.
ASSESS: Did it work? What's my confidence? Should I continue?

Agents that skip THINK waste tokens exploring. Agents that skip ASSESS don't know when to stop. Agents that skip ACT just plan forever. All three, in that order, every cycle.