Advanced Subagent Architecture

Patterns and templates for building robust multi-agent systems with OpenClaw.

Why This Skill Is Complex (Read Before Installing)

This is one of the most feature-dense skills in the ClawHub registry. Security scanners will flag it — not because it's malicious, but because it does a lot. Here's exactly what's in it and why:

Scope:

• - 4 production-ready JS libraries (~1,200 lines total across spawn-security-proxy, spawn-researcher, cost-estimator, quality-scorer)
• 4 spawn templates covering security proxy, researcher, phased implementation, and peer review patterns
• A setup.sh that creates local directory scaffolding (no network calls, no package installs)
• Inline attack vector documentation in spawn-security-proxy.js (test fixtures, not live payloads)

Why the libs exist: These aren't glue code — they implement real patterns: output sanitization with canary tokens, multi-source research validation, cost projection with approval gates, and subagent output scoring. The complexity is the point; simpler skills don't solve these problems.

Why scanners flag it:

1. 1. JS code in a skill package looks like an execution surface — it is, but only when you explicitly require() it
2. The security proxy documents injection attack patterns as test examples — pattern matchers don't distinguish documentation from intent
3. External integration references (Discord, peer agents) appear in templates — they're opt-in workflows, not auto-configured connections

Complexity is not a red flag here. It's the product.

---

⚠️ Security Transparency Notice

What this skill contains:

• - lib/ — Reference JS libraries (spawn helpers, cost estimator, quality scorer). These are not auto-executed. Copy them to your workspace lib/ directory to use them.
• INLINECODE5 — Markdown spawn templates for common patterns.
• INLINECODE6 — Creates local directory scaffolding only. Makes no network calls, installs no packages.

External integrations: All optional, none auto-configured.

• - Discord webhooks — Only used in the federated peer-review pattern. You supply your own token manually. This skill does not store or transmit credentials.
• Peer agent endpoints — Federated review is opt-in. No external calls unless you explicitly configure peer URLs.

Credential requirements: None. No API keys, tokens, or env vars are required or auto-read by this skill.

Overview

This skill provides battle-tested patterns for:

• - Security isolation - Contain high-risk operations with minimal context exposure
• Specialized research - Multi-perspective data gathering with domain experts
• Phased implementation - Architecture → Development → Review pipelines
• Peer collaboration - External validation via federated agent network (opt-in)
• Cost-aware spawning - Budget estimation and optimization strategies

What's New in v2.0

Advanced Patterns:

• - Security proxy pattern (blast shield isolation)
• Researcher specialist pattern (multi-source synthesis)
• Phased implementation pipeline (architect → coder → reviewer)
• Peer review integration (bot-to-bot validation)
• Cost estimation framework (required for spawns >$0.50)

Templates:

• - templates/security-proxy.md - Isolate untrusted service access
• INLINECODE8 - Domain-specific research agents
• INLINECODE9 - Multi-phase feature development
• INLINECODE10 - External peer validation

Integration:

• - task-routing skill (auto-classification and routing)
• cost-governor (budget enforcement)
• drift-guard (behavioral validation)

Quick Start

1. Install Skill Structure

CODEBLOCK0

2. Choose Your Pattern

For high-risk operations:
CODEBLOCK1

For research tasks:
CODEBLOCK2

For complex features:
CODEBLOCK3

For external validation:
CODEBLOCK4

Agent Registry: AGENTS.md is Optional

Critical clarification for new users: AGENTS.md is a human-readable reference document, not a configuration file. The spawning system does not read it.

How spawning actually works

INLINECODE11 is a tool call — it takes parameters you provide at the moment of the call. It does not read from any file, config, or registry. You can spawn subagents on a completely fresh OpenClaw install with zero files in your workspace.

CODEBLOCK5

What AGENTS.md actually is

AGENTS.md (and domain files like AGENTSWRITING.md, AGENTSINFRA.md) are memory aids for you (the agent). They store:

• - Agent names and personality snippets you've found effective
• Cost history and last-used dates
• Notes on what tasks each agent type handles well

You can split AGENTS.md into 50 domain files or delete it entirely — spawning still works. The split is purely for your readability; it has zero functional effect.

What "read AGENTS_WRITING.md before spawning" means

When documentation says "read AGENTS_WRITING.md before spawning AuthorAgent", it means:

Read it so you know what personality, model, and task description to use when building the spawn call.

The system does not read it. You read it, extract the configuration, then make the spawn call with those parameters.

Practical implication for fresh installs

When you install this skill on a fresh OpenClaw setup:

1. 1. You do not need to create AGENTS.md to use subagents
2. Start spawning immediately with inline parameters
3. Create AGENTS.md when you have enough recurring agent configurations that you want a reference doc
4. Split into domain files when AGENTS.md grows beyond ~10 entries and becomes hard to scan

See templates/agents-registry-template.md for a minimal starter template when you're ready.

---

Reference Implementations

NEW in v2.1: Production-ready code libraries for all patterns.

Available Libraries

lib/spawn-security-proxy.js - Security isolation framework

• - spawnSecurityProxy(config) - Spawn isolated proxy with sanitization
• INLINECODE14 - Remove sensitive data (API keys, paths, emails)
• INLINECODE15 - JSON schema validation
• INLINECODE16 - Common output schemas (list, single, status)

lib/spawn-researcher.js - Multi-perspective research framework

• - spawnResearcher(config) - Spawn domain expert researcher
• INLINECODE18 - Multi-perspective research (optimist/pessimist/pragmatist)
• INLINECODE19 - Score source trustworthiness (0-100)
• Pre-configured trusted/blog/vendor domain lists

lib/cost-estimator.js - Cost estimation and tracking

• - estimateSubagentCost(params) - Pre-spawn cost estimation with confidence intervals
• INLINECODE21 - Log for accuracy tracking
• INLINECODE22 - Monthly accuracy improvement
• INLINECODE23 - Historical performance analysis
• INLINECODE24 - Classify as micro/small/medium/large

lib/quality-scorer.js - Output quality assessment

• - scoreSubagentOutput(output, rubric) - 8-dimension quality scoring
• INLINECODE26 - Manual review template
• INLINECODE27 - Pre-delivery validation
• Rubric dimensions: specificity, actionability, evidence, structure, completeness, clarity, relevance, efficiency

Usage Examples

All libraries include complete working examples:

CODEBLOCK6

Quick Integration

Path Resolution Note: The require() paths in examples below assume you call them from your workspace root. If you call from within the skill directory (e.g., inside an example script), use __dirname instead. For portable code that works regardless of cwd:
CODEBLOCK7

CODEBLOCK8

See examples/ directory for complete working demonstrations.

Integration Status

Dependencies Overview

Required:

• - ✅ OpenClaw 2026.2.17+ (sessions_spawn API)
• ✅ Node.js 18+ (for library code)

Optional Skills:

task-routing

• - Status: ✅ Available (workspace skills/task-routing/)
• Version: 1.0.0+
• Integration: Auto-classification of incoming tasks, risk scoring, pattern routing
• Tested: Yes (production since 2026-02-15)
• Documentation: See INLINECODE33

cost-governor

• - Status: ⚠️ Planned (design phase)
• Version: N/A
• Integration: Budget enforcement, approval workflows
• Tested: No
• Workaround: Use lib/cost-estimator.js for manual gating

drift-guard

• - Status: ⚠️ Planned (design phase)
• Version: N/A
• Integration: Behavioral audits, policy violation detection
• Tested: No
• Workaround: Manual output review against rubric

Library Dependencies

All reference implementations are dependency-free (pure Node.js):

• - No npm packages required
• No external API calls
• Filesystem access for logging only (optional)
• Mock-friendly for testing

Integration Points

Automatic (via task-routing skill):

• - Task classification → Pattern recommendation
• Risk scoring → Security proxy auto-spawn for high-risk tasks
• Cost estimation → Pre-spawn budget check

Manual (call libraries directly):

• - require() any lib file and call functions
• See examples/ for usage patterns
• Spawn functions accept custom spawn_fn for integration with your sessions_spawn

Migration Path

From v2.0 to v2.1:

1. 1. No breaking changes - templates still work as-is
2. New: Import library functions for programmatic use
3. New: Run examples to see working code
4. Optional: Integrate with task-routing for automation

Future (v3.0 with framework improvements):

• - Per-spawn resource limits (when OpenClaw supports)
• Bidirectional communication (when OpenClaw supports)
• Post-mortem tracking (when OpenClaw supports)
• See "Framework Limitations & v2 Roadmap" section for details

Core Concepts

1. Security Isolation (Blast Shield Philosophy)

Problem: Subagents with full workspace access can leak sensitive data to untrusted APIs.

Solution: Security proxies receive minimal context, restricted tools, sanitized output.

Example:
CODEBLOCK9

Key principles:

• - Minimal context (only task parameters, no workspace paths)
• Tool restrictions (whitelist, not blacklist)
• Output sanitization (validate schema before returning)
• Ephemeral execution (no persistent state)
• Cost cap (< $0.10 per proxy spawn)

See: INLINECODE38

2. Researcher Specialists (Multi-Source Synthesis)

Problem: Generic web search returns surface-level results without domain expertise.

Solution: Specialized researchers with domain bias, multi-source validation, actionable synthesis.

Example:
CODEBLOCK10

Key principles:

• - Domain focus (single expertise area per researcher)
• Multi-source validation (3+ independent sources per claim)
• Skeptical by default (anti-hype, calls out marketing)
• Structured output (executive summary + recommendations)
• Evidence-backed (no speculation, contradictions addressed)

See: INLINECODE39

3. Phased Implementation (Separation of Concerns)

Problem: Single-agent implementation mixes design, coding, and validation → tech debt.

Solution: Separate architect (design), coder (build), reviewer (validate) phases.

Example:
CODEBLOCK11

Key principles:

• - Architects optimize long-term (not quick hacks)
• Coders focus on working code (test after each step)
• Reviewers provide fresh perspective (catch integration issues)
• Incremental delivery (small PRs, easy rollback)
• Cost-aware (skip phases for simple features)

See: INLINECODE40

4. Peer Collaboration (Federated Trust)

Problem: Your agent may have blindspots or lack domain expertise.

Solution: Request external validation from trusted peer agents.

Example:
CODEBLOCK12

Key principles:

• - Trust earned (track peer accuracy over time)
• Data sanitization (remove secrets, personal data)
• Structured feedback (severity, category, recommendations)
• Reciprocal reviews (offer your expertise to peers)
• Cost-effective (free peer reviews vs paid audits)

⚠️ Trust tier ≠ security bypass:
If you implement tiered trust (Acquaintance → Friend → Ally or equivalent), "higher trust" means relaxed engagement policy — not skipping security validation. Content from even the most trusted peer still goes through injection detection (Stage 4). An ally account can be compromised; the injection scanner is the last defense that can't be socially engineered. "Light validation" always means reduced schema scrutiny, never reduced security scanning.

See: INLINECODE41

5. Identity Continuity (Ephemeral Process, Persistent External Identity)

Problem: Security proxies are ephemeral (spawn-per-task, terminate). But some external services require a persistent identity — a social network account, an API user, a recurring agent persona. These are in tension.

Solution: Separate the process lifecycle from the external identity. The process dies every spawn. The external identity persists through workspace state + core-managed credentials.

CODEBLOCK13

Key rules:

• - Credentials live in core memory only — never in proxy workspace files
• Session token: short TTL (2 hours max), passed encrypted in task context, never written to disk
• Consistency: core injects "recent context" summary (last N interactions) into each spawn's task description so the new process knows what prior spawns committed to
• Token rotation: scheduled by core (e.g., weekly), not the proxy

Anti-pattern: storing tokens in [workspace]/config.json — if the proxy workspace is compromised, credentials should not be compromised with it.

6. Research Team (Parallel Multi-Lens Analysis)

Problem: Single-agent analysis has blind spots — the same agent proposes and evaluates its own ideas.

Solution: Spawn 3 specialist agents in parallel with distinct analytical lenses, then synthesize into one unified response.

Architecture:
CODEBLOCK14

When to use:

• - Task complexity === 'high' OR explicit research flag set
• Architecture decisions with real tradeoffs
• Debugging where root cause is unclear
• Any question where a single perspective tends to miss things

When to skip:

• - Routine tasks, simple lookups, quick fixes
• Cost-sensitive situations (research team = ~4x single-agent cost)

Key components:

• - lib/team-chatroom.js — append-only JSONL shared memory between parallel agents
• INLINECODE44 — builds task strings for each lens + UnifierAgent
• INLINECODE45 — gate function
• INLINECODE46 — returns sessionId + 3 specialist task objects
• INLINECODE47 — builds synthesis prompt from chatroom
• INLINECODE48 — verifies all lenses posted before unifying

Lens discipline:

• - Each lens gets a distinct role description injected into its prompt
• Lenses do NOT communicate with each other — only through the chatroom
• UnifierAgent reads all lens outputs and produces ONE response
• If a lens fails silently, UnifierAgent warns but synthesizes from available data

Cost: ~4x single-agent. Gate on complexity to control spend.

Critical rule: Grok or any external model used as a lens is a leaf node — it answers, it never spawns further agents.

See: lib/research-coordinator.js for reference implementation.

7. External Model Consultation

Problem: Your agent may have architectural blind spots that another model's reasoning style would catch. Human relay (copy/paste to another AI) is slow and lossy.

Solution: Spawn an ExternalConsultAgent subagent that calls an external model's API directly, persists the session, and returns the response.

Architecture:
CODEBLOCK15

Why subagent, not core agent:
External API calls are side effects with cost and data exposure implications. Isolating them in a subagent follows the blast-shield philosophy — if something goes wrong, it's contained.

Key components:

• - lib/external-bridge.js — session management, task string builder, consultation logger
• INLINECODE51 — provider config (model IDs, endpoints)
• INLINECODE52 — persistent session files for conversation continuity
• INLINECODE53 — shouldAutoConsult() gate (RED drift + high complexity + 24h cooldown)

Auto-consult gate (3 conditions, all required):

1. 1. Intent drift level === 'RED'
2. Task complexity === 'high'
3. Last consultation > 24 hours ago (with lock file to prevent race conditions)

Security rules (enforce before go-live):

• - External model is a leaf node — never triggers further spawns
• Context sanitization before every call — strip API keys, file contents, internal paths
• Session-level call cap (prevent fan-out)
• Metadata logging of every call (timestamp, provider, trigger reason)
• Key stored in environment variable, not config file

Session continuity:
Pass sessionId from a previous consultation to continue the conversation. The bridge injects prior message history automatically.

See: lib/external-bridge.js for reference implementation.

8. Intent Engineering (Value Alignment over Time)

Problem: Prompt engineering tells agents what to do. Context engineering tells agents what to know. Neither tells agents what to want — so they drift from user values over time without detection.

Solution: A three-layer system that encodes agent intent, extracts intent signals from user behavior, and detects drift before it becomes a problem.

Three layers:

1. 1. Intent Manifest (memory/intent-manifest.json) — Machine-readable intent spec per agent: core purpose, hard constraints (with regex), operational goals with verification keywords, user signals extracted from history
2. Intent Extractor (lib/intent-extractor.js) — Weekly pass over episode history extracting preference/value/correction signals; decays old signals (rate: 0.975/week), prunes below 0.30 strength
3. Drift Detector (lib/intent-drift-detector.js) — 5-component score per episode: hard constraint violations (0.35), goal keyword coverage (0.25), structural drift via Jaccard (0.20), correction pressure (0.15), forbidden phrase hits (0.05)

Drift levels:

• - GREEN (< 0.29): Normal operation
• YELLOW (0.29–0.48): Inject reminder next turn
• ORANGE (0.48–0.68): Log + prepare summary
• RED (≥ 0.68): Flag for user check-in (triggers auto-consult gate)

Intent manifest schema:
CODEBLOCK16

Key properties:

• - System intent + agent overrides use deep merge — agents inherit system constraints
• User signals decay weekly — recent corrections weighted higher
• Operational goals are hand-authored for v1; intent compression auto-suggests additions in v2
• Manifest is diffable over time (diff_log tracks changes)
• Drift score adjusts confidence estimator: INLINECODE60

Cold start: Works on day 1 with hand-authored goals. Signals accumulate automatically.

See: lib/intent-manager.js, lib/intent-extractor.js, lib/intent-drift-detector.js for reference implementation.

5. Cost-Aware Spawning

Problem: Uncontrolled subagent spawning leads to budget overruns.

Solution: Estimate cost before spawning, require approval for expensive operations.

Framework:
CODEBLOCK17

Cost tiers:

• - Micro (< $0.10): Simple lookups, fact-checking
• Small ($0.10-0.50): Standard research, code review
• Medium ($0.50-2.00): Feature implementation, deep analysis
• Large (> $2.00): Complex refactors, multi-phase projects

Optimization strategies:

• - Use haiku for simple tasks (3x cheaper than sonnet)
• Parallelize independent operations
• Cache research findings for reuse
• Skip optional phases (reviewer for low-risk changes)

Directory Structure

CODEBLOCK18

When to Use Each Pattern

Security Proxy

Use when:

• - Accessing untrusted APIs or experimental services
• Risk score > 70 (high blast radius or irreversibility)
• Data needs sanitization before main agent sees it
• Cost estimate < $0.10 (lightweight proxy)

Skip when:

• - Trusted first-party APIs (your infrastructure)
• Read-only public data (Wikipedia, documentation)
• Risk score < 30 (low stakes)

Researcher Specialist

Use when:

• - Question requires 10+ sources
• Domain expertise needed (not general knowledge)
• Multiple conflicting claims (need fact-checking)
• Deliverable is a decision (not just information)
• Cost estimate > $0.20 (worth specialist analysis)

Skip when:

• - Simple factual lookup (single authoritative source)
• Real-time data (weather, stock prices)
• Cost estimate < $0.10 (not worth overhead)

Phased Implementation

Use when:

• - Feature touches 3+ files
• Requires integration with existing systems
• Cost estimate > $1.00 (worth upfront design)
• Failure would be expensive (need rollback plan)
• Long-term maintainability matters

Skip when:

• - Simple script (1 file, no integration)
• Well-understood pattern (copying existing structure)
• Prototype/experiment (might throw away)
• Cost estimate < $0.50 (faster to just build)

Peer Review

Use when:

• - High stakes (security, legal, financial)
• Domain gap (no internal specialist)
• Bias check (fresh perspective needed)
• Complex validation (multi-dimensional review)

Skip when:

• - Low stakes (documentation, styling)
• Domain expertise available internally
• Fast turnaround required (peer may take hours/days)
• Sensitive data (can't sanitize for external review)

Integration with Task Routing

Automatic pattern selection via task-routing skill:

CODEBLOCK19

Manual override:
CODEBLOCK20

Cost Tracking & Optimization

Logging Requirements

All subagent spawns >$0.50 must be logged to notes/cost-tracking.md:

CODEBLOCK21

Accuracy Improvement

Track estimate vs actual to improve future predictions:
CODEBLOCK22

Quality Standards

Subagent Output Rubric

All specialist subagents should score 7+ on this rubric:

Dimension	Poor (1-3)	Good (4-6)	Excellent (7-10)
Specificity	Vague generalizations	Some concrete details	Precise, actionable specifics
Actionability

No clear next steps | Suggestions provided | Step-by-step implementation plan |
| Evidence | Unsourced claims | Some citations | Every claim sourced, validated |
| Structure | Stream-of-consciousness | Basic organization | Scannable hierarchy, summaries |
| Completeness | Missing key aspects | Most areas covered | Comprehensive, gaps documented |
| Honesty | Hides limitations | Mentions some trade-offs | Explicit about unknowns, risks |
| Cost-awareness | No budget consideration | Rough estimates | Detailed cost/benefit analysis |
| Integration | Ignores existing systems | Basic compatibility | Seamless integration plan |

Self-Audit Checklist

Before finalizing subagent output:

• - [ ] Every claim has source (URL + date)
• [ ] Contradictions addressed (not ignored)
• [ ] Recommendations include trade-offs
• [ ] Cost estimate provided (time + money)
• [ ] Integration points documented
• [ ] Rollback strategy included
• [ ] Success criteria defined
• [ ] Known limitations listed

Philosophy

Permanent vs Ephemeral

Permanent subagents (skill-based):

• - Recurring specialized tasks
• Deep domain expertise
• Knowledge accumulation over time
• Examples: DevOps, AuthorAgent, WuxiaWorldbuilder

Ephemeral subagents (one-off spawns):

• - Bounded research tasks
• Simple implementation work
• Experimental exploration
• Pattern-based specialists (security-proxy, researcher)

Anti-Sycophant by Default

All subagents should:

• - Call out weak evidence (no polite agreement)
• Reject unrealistic requirements (push back on bad specs)
• Highlight risks honestly (no sugar-coating)
• Admit knowledge gaps (no speculation to please)

Cost-Conscious Operation

• - Estimate before spawning (no surprise bills)
• Choose appropriate model (haiku vs sonnet vs opus)
• Parallelize when possible (save time = save money)
• Cache and reuse (research findings, architecture patterns)
• Terminate early if stuck (don't spin wheels for 30min)

Dependencies

Required

• - OpenClaw 2026.2.17+ (subagent spawning, cost tracking)

Optional but Recommended

• - task-routing skill (auto-pattern selection, risk scoring)
• cost-governor skill (budget enforcement, approval workflows)
• drift-guard skill (behavioral validation, quality audits)

Integration Points

Task routing:

• - Provides task classification (8 types)
• Risk scoring (5 dimensions, 0-100 scale)
• Auto-route to pattern (security-proxy, researcher, phased-impl)

Cost governor:

• - Pre-spawn approval for expensive operations
• Budget tracking per project/feature
• Alert on overruns

Drift guard:

• - Behavioral audit of subagent outputs
• Policy violation detection
• Quality score trending

Framework Limitations & v2 Roadmap

Known gaps identified in peer review (Agent Smith, EasyClaw project)

Current OpenClaw subagent framework has architectural limitations that affect all patterns in this skill. These are framework-level constraints, not skill-specific issues. Documenting for transparency and future improvement.

1. Spawn Configuration Constraints

Smith's Question: "How does core define sub-bot constraints before launch?"

Current State:

• - Spawn parameters: task, personality, model, timeout, INLINECODE69
• Basic configuration only (what to do, how long)
• No granular resource controls

Limitations:

• - ❌ No memory limits per spawn (subagent can consume unlimited RAM)
• ❌ No API call quotas (can make 1000s of web requests)
• ❌ No disk space caps (can fill storage)
• ❌ No per-spawn tool restrictions (tool policy is framework-level, applies to all subagents)

Current Workaround:

• - Manual timeout enforcement (kill after N minutes)
• Framework-level tool policies (same restrictions for all subagents)
• Post-spawn monitoring (watch logs, intervene manually)

v2 Design Considerations:
CODEBLOCK23

Impact on Patterns:

• - Security proxy: Could enforce strict tool whitelist per proxy (currently manual)
• Researcher: Could cap API calls to prevent runaway research loops
• Phased impl: Could allocate different budgets per phase (architect: $0.40, coder: $1.00)

2. Skill Loading & Validation

Smith's Question: "How are skills validated before execution?"

Current State:

• - External skills (downloaded) → skill-vetter checks metadata, malicious patterns
• Internal skills (workspace) → Just execute (trusted by default)
• No runtime sandboxing

Limitations:

• - ❌ No code isolation for skills (skill code runs in main agent context)
• ❌ No execution validation (skill can do anything agent can do)
• ❌ No capability restrictions (skill inherits all agent tools)
• ❌ Trust model: Binary (external = vet, internal = trust)

Current Workaround:

• - Vet external skills manually before first use
• Review internal skill code (human audit)
• Hope skills don't misbehave

v2 Design Considerations:
CODEBLOCK24

Impact on Patterns:

• - Security proxy: Skills could be sandboxed (currently rely on manual isolation)
• All patterns: Skills loaded by subagents would inherit spawn constraints
• Peer review: External skills from peers could run safely (sandboxed)

3. Communication Bounds (Bidirectional Channel)

Smith's Question: "What can sub-bots ask for from core?"

Current State:

• - One-way communication only: Core spawns → Subagent executes → Returns result
• Subagent cannot request clarification mid-task
• Subagent cannot request additional context during execution
• No interactive mode

Limitations:

• - ❌ Subagent stuck on ambiguous requirement → Must guess or fail
• ❌ Subagent needs additional context → Can't ask, works with what it has
• ❌ Subagent encounters unexpected scenario → No escalation path mid-task
• ❌ Human approval needed mid-execution → Not possible (only pre/post spawn)

Current Workaround:

• - Over-specify context in initial spawn (bloated prompts)
• Subagent makes best guess (may be wrong)
• Subagent fails, core respawns with clarification (expensive)

v2 Design Considerations:
CODEBLOCK25

Impact on Patterns:

• - Researcher: Can ask "should I dig deeper on this tangent?" mid-research
• Phased impl: Coder can ask architect for design clarification during build
• Security proxy: Can request human approval if API returns unexpected data
• All patterns: Reduces over-specification, enables adaptive execution

4. Termination Conditions (Resource-Based Kills)

Smith's Question: "When does core kill a sub-bot?"

Current State:

• - Time-based only: Timeout (specified in spawn) or task completion
• Manual intervention (human stops runaway agent)
• No automatic resource-based termination

Limitations:

• - ❌ No memory limit kills (agent can OOM the host)
• ❌ No cost threshold kills (can exceed budget before timeout)
• ❌ No stuck detection (infinite loops run until timeout)
• ❌ No output size limits (can generate gigabytes of text)

Current Workaround:

• - Set conservative timeouts (may kill productive work early)
• Monitor logs manually (reactive, not proactive)
• Hope agent doesn't get stuck in expensive loop

v2 Design Considerations:
CODEBLOCK26

Impact on Patterns:

• - Security proxy: Strict resource limits (memory, cost) prevent runaway isolation breaches
• Researcher: Stuck detection prevents infinite search loops
• Phased impl: Cost limits per phase (architect can't blow whole budget)
• All patterns: Better cost control, faster failure detection

5. Post-Mortem & Learning System

Smith's Question: "How do you learn from sub-bot failures?"

Current State:

• - Success-only logging: Add to AGENTS.md after successful spawns
• Manual failure review (check logs, wonder what happened)
• No systematic failure tracking
• No pattern analysis

Limitations:

• - ❌ No failure tracking (only successes logged to AGENTS.md)
• ❌ No common failure pattern detection (same mistake repeated)
• ❌ No cost vs value analysis (did expensive agent deliver value?)
• ❌ No success rate per agent type (which specialists are reliable?)
• ❌ No improvement feedback loop (failures don't inform future spawns)

Current Workaround:

• - Human remembers failures (unreliable)
• Manually check logs when something seems off
• Anecdotal learning ("that researcher failed last time")

v2 Design Considerations:
CODEBLOCK27

Proposed Learning Loop:
CODEBLOCK28

Impact on Patterns:

• - All patterns: Historical success rates inform spawn decisions
• Cost framework: Improve estimation accuracy (learn from past errors)
• Quality standards: Track which patterns consistently deliver high scores
• Pattern evolution: Retire unreliable patterns, double down on proven ones

Summary: v2 Feature Matrix

Feature	v1 (Current)	v2 (Proposed)	Benefit
Spawn constraints	Timeout only	Memory, cost, quota, tool whitelist	Resource safety
Skill isolation

Trust-based | Sandboxed with capabilities | Security | | Communication | One-way | Bidirectional request/response | Adaptive execution | | Termination | Time-based | Multi-condition (resource, stuck, cost) | Cost control | | Post-mortem | Success-only | Full lifecycle tracking + analytics | Continuous learning |

Current mitigation strategies:

1. 1. Manual monitoring (watch logs, intervene when needed)
2. Conservative estimates (over-specify context, pad timeouts)
3. Pattern discipline (follow templates strictly to avoid known failure modes)
4. Human-in-loop (approve expensive spawns, review failures manually)

v2 would enable:

• - Autonomous resource management (agents self-limit)
• Higher confidence spawning (better failure prediction)
• Faster iteration (learn from failures automatically)
• Fine-grained security (per-spawn, per-skill isolation)

Note for users:
These limitations affect all subagent patterns in this skill. The patterns documented here (security-proxy, researcher, phased-impl, peer-review) work within current framework constraints. v2 improvements would enhance safety and reliability, but are not required for effective use of these patterns today.

Tracking: OpenClaw framework issue (conceptual - not filed yet)
Credit: Agent Smith (EasyClaw peer review, 2026-02-22)

Examples

Example 1: Security-First API Integration

Scenario: Integrate with untrusted social network API

CODEBLOCK29

Example 2: Multi-Perspective Research

Scenario: Evaluate whether to adopt new framework

CODEBLOCK30

Example 3: Phased Feature Development

Scenario: Build complex new skill

CODEBLOCK31

Example 4: Peer Validation

Scenario: Security audit for payment processing

CODEBLOCK32

Troubleshooting

Problem: Subagent exceeds cost estimate

Diagnosis:

• - Check actual task complexity vs estimate
• Review subagent logs for loops or retries
• Verify model choice (opus when sonnet would suffice?)

Solutions:

• - Improve cost estimation (track actuals, adjust formula)
• Add cost cap to spawn config (hard limit)
• Use cheaper model for exploratory phase

Problem: Security proxy leaks sensitive data

Diagnosis:

• - Audit spawn context (did it include workspace paths?)
• Check tool restrictions (was file access allowed?)
• Review output sanitization (did schema validation fail?)

Solutions:

• - Update security-proxy template checklist
• Add automated context sanitization pre-spawn
• Implement output schema validation (reject non-conforming data)

Problem: Phased implementation phases conflict

Diagnosis:

• - Architect plan unrealistic (coder can't implement)
• Coder deviated from plan (reviewer rejects)
• Reviewer too strict (perfect is enemy of good)

Solutions:

• - Architect: Include feasibility check (can this be built?)
• Coder: Flag deviations early (request plan amendment)
• Reviewer: Focus on critical issues (don't block on style)

Problem: Peer review unavailable or slow

Diagnosis:

• - Peer bot offline or rate-limited
• No trusted peers for required domain
• Review package too large or unclear

Solutions:

• - Maintain backup peer list (2+ per domain)
• Fall back to internal review (DevOps, CoderAgent)
• Simplify review package (focus on specific question)

Framework Limitations & v2 Roadmap

Known gaps identified in peer review (Agent Smith, EasyClaw - 2026-02-22)

These limitations represent areas where the current OpenClaw subagent framework needs evolution. Documented here for transparency and future development.

1. Spawn Configuration - Per-Subagent Constraints

Current state:

• - Spawn parameters: task description, personality, model, timeout, label
• Constraints are framework-level (all subagents share same tool policy)

Missing:

• - Memory limits per spawn (prevent individual subagent memory leaks)
• API call quotas per spawn (prevent runaway costs)
• Disk space caps per spawn (prevent storage exhaustion)
• Per-spawn tool restrictions (fine-grained beyond framework allowlist)

v2 Design Consideration:
CODEBLOCK33

Impact: Without per-spawn constraints, one rogue subagent can exhaust resources for all others.

2. Skill Loading - Runtime Validation

Current state:

• - External skills: Pre-execution vetting via skill-vetter (red flag detection)
• Internal skills: Trusted by default, no runtime sandboxing

Missing:

• - Runtime sandboxing for skill-embedded code (JavaScript, shell scripts)
• Execution validation (verify skill behaves as documented)
• Resource monitoring during skill execution

v2 Design Consideration:
CODEBLOCK34

Impact: Without runtime sandboxing, malicious or buggy skills can compromise core agent.

3. Communication Bounds - Bidirectional Channels

Current state:

• - One-way communication only: Core spawns → Subagent executes → Result returns
• Subagents cannot ask clarifying questions during execution

Missing:

• - Mid-task clarification requests ("Should I proceed with risky operation?")
• Progress updates for long-running tasks (>5min execution)
• Dynamic priority adjustment (core can signal "abort" or "expedite")

v2 Design Consideration:
CODEBLOCK35

Impact: Without bidirectional channels, subagents must either be overly cautious (ask for everything upfront) or overly bold (proceed with assumptions).

4. Termination Conditions - Resource-Based Kills

Current state:

• - Timeout-based only: Subagent runs until task completes or timeout expires
• No resource-based termination

Missing:

• - Memory limit kills (terminate if subagent exceeds RAM quota)
• Cost threshold kills (terminate if API calls exceed budget)
• Stuck detection (infinite loops, deadlocks, recursive spawning)
• Runaway output prevention (subagent generating gigabytes of logs)

v2 Design Consideration:
CODEBLOCK36

Impact: Without resource-based kills, subagents can waste budget, exhaust memory, or spin indefinitely.

5. Post-Mortem - Learning from Failures

Update (v2.1 → v2.2): A lightweight v0 of post-mortem logging is now implementable without framework changes. The crash report schema defined in templates/proxy-recovery.md gives you structured failure data per-spawn. Core reads crash reports and routes them. This covers the "what failed and why" dimension immediately.

What still requires framework work (see v2 roadmap below): automated outcome analytics, pattern detection across spawns, success rate tracking. But single-spawn forensics — you can ship that now.

Current state:

• - Success logging only: AGENTS.md records completed subagents
• No failure tracking or pattern analysis
• Partial exception: Security proxies using proxy-recovery.md pattern get crash reports per spawn

Missing:

• - Failure logging (why did subagent fail?)
• Common failure patterns (which tasks/agents fail most?)
• Cost vs value analysis (was the subagent worth the spend?)
• Success rate tracking per agent type (CoderAgent: 85%, ResearchAgent: 92%, etc.)
• Improvement loop (adjust spawn parameters based on historical outcomes)

v2 Design Consideration:
CODEBLOCK37

Impact: Without post-mortem analysis, you repeat failures, can't optimize spawn strategy, and waste budget on low-value subagents.

---

Conclusion:

These 5 limitations don't block current usage but represent friction points as subagent usage scales. Prioritize based on pain:

• - High priority: #4 (resource-based kills) - prevents runaway costs
• Medium priority: #5 (post-mortem) - enables data-driven optimization
• Medium priority: #1 (per-spawn constraints) - prevents resource exhaustion
• Low priority: #3 (bidirectional channels) - nice to have for complex tasks
• Low priority: #2 (skill sandboxing) - current vetting sufficient for trusted sources

Feedback welcome: If you've hit these limitations in production, share workarounds and pain points via OpenClaw community channels.

Contributing

This skill improves through real-world usage. Please contribute:

Pattern refinements:

• - Found edge case not covered? Update template
• Better cost estimation formula? Share it
• New integration point? Document it

New patterns:

• - Discovered novel orchestration? Add template
• Hybrid approach works better? Explain why
• Optimization technique? Include example

Track record:

• - Log your subagent spawns (cost, accuracy, outcomes)
• Share what worked (and what didn't)
• Update rubrics based on production learnings

License

MIT - Use freely, modify as needed, share improvements

Changelog

v2.3.0 (2026-02-24)

• - Added: Pattern 6 — Research Team (parallel multi-lens analysis with Critic/Implementer/Synthesizer lenses + UnifierAgent)
• Added: Pattern 7 — External Model Consultation (ExternalConsultAgent subagent, session persistence, auto-consult gate)
• Added: Pattern 8 — Intent Engineering Layer (manifest schema, intent extraction, drift detection, 5-component drift score)
• Updated: Version bump to 2.3.0

v2.2.0 (2026-02-23)

• - Added: Core Concept #5 — Identity Continuity (ephemeral process vs persistent external identity, token handoff pattern, consistency via core-injected recent context, anti-pattern warning)
• Added: Trust tier ≠ security bypass principle to Peer Collaboration section (Stage 4 injection detection always runs regardless of trust level)
• Added: templates/proxy-recovery.md — crash/recovery pattern (pre-death checklist, crash report schema, core response decision tree, quarantine mode, human notification, re-spawn decision guide)
• Updated: templates/security-proxy.md — full rewrite integrating: 6-stage inbound validation pipeline, Stage 6b outbound semantic leak filter, self-imposed rate limiter + circuit breaker, crash/recovery checklist, identity continuity section, MoltbookProxy as real-world reference implementation
• Updated: Post-mortem section — notes crash reports from proxy-recovery.md are a working v0 of per-spawn forensics (no framework changes required)

v2.0.1 (2026-02-22)

• - Added: Framework Limitations & v2 Roadmap section
• Added: 5 critical design gaps identified by Agent Smith (EasyClaw peer review)
• Added: v2 design considerations with code examples for each limitation
• Added: Priority ranking for addressing limitations

v2.0.0 (2026-02-22)

• - Breaking: Restructured to focus on advanced patterns
• Added: Security proxy pattern and template
• Added: Researcher specialist pattern and template
• Added: Phased implementation pattern and template
• Added: Peer review pattern and template
• Added: Cost-aware spawning framework
• Added: Integration with task-routing, cost-governor, drift-guard
• Updated: Philosophy section (anti-sycophant, cost-conscious)
• Updated: Examples (real-world scenarios, not toy problems)
• Removed: Basic scaffolding (moved to setup.sh)

v1.0.0 (2026-02-21)

• - Initial release with basic subagent structure
• SPECIALIST.md template
• Task routing integration basics

Support

• - Documentation: Read templates in templates/ directory
• Examples: See AGENTS.md for real-world subagent library
• Issues: Check EVOLOG.md for known limitations
• Community: Share patterns via OpenClaw Discord (when federated network launches)