Compound Loop Implementation Guide

Primary Operator: Soul Engineer System: OpenClaw v2 Nightly Self-Improvement Loop Status: Re-enabling (was disabled during v1 stability phase)

Overview

The compound loop is the nightly self-improvement system that allows each OpenClaw agent to reflect on its daily performance, extract lessons, propose soul updates, and propagate cross-agent learnings -- all without human intervention for routine improvements.

What it does: Every night, each of the 15 agents runs a structured self-reflection prompt that assesses performance, identifies failures, extracts lessons, and proposes updates to its own soul (system prompt / behavioral rules). High-confidence changes are auto-applied; lower-confidence changes are queued for human review.

Why it exists: Agents that can learn from their own mistakes compound their improvements over time. A single correction applied on day 1 prevents the same error on days 2 through infinity. Without the loop, agents repeat the same mistakes until a human manually updates their soul.

Why it was disabled: During the v1 stability phase, the loop was turned off because:

Early iterations lacked sufficient verification gates, leading to soul drift (rules that sounded reasonable but degraded performance).
Cross-agent propagation had no deduplication or contradiction checking, causing conflicting rules across agents.
There was no regression detection -- bad rules could persist indefinitely.

Why we are re-enabling it: The v2 system addresses all three issues with the Three-Gate Verification System, anti-echo-chamber safeguards, and automated regression benchmarking. The loop is now safe to run autonomously with periodic human checkpoints.

Architecture

The full nightly flow runs between 23:00 and 03:00 EST. All times are Eastern.

23:00        Sessions close
             - All active agent sessions are gracefully wound down
             - Final interaction logs are flushed to disk
             - Daily performance metrics are snapshot

00:00-00:30  Pre-processing
             - Aggregate daily logs per agent
             - Compute performance scores per dimension
             - Identify failure events and near-misses
             - Prepare context packages for each agent's reflection

01:00-02:30  Agent reflection loops run (parallel, staggered by 10 min)
             - Each agent runs the Nightly Loop Prompt against its day's data
             - Outputs: performance assessment, failures, lessons, soul proposals,
               cross-agent signals, tomorrow's focus
             - Each agent's output is written to .learnings/nightly/YYYY-MM-DD.md

02:00        Cross-agent propagation begins
             - Tagged cross-agent lessons are routed to recipients
             - Deduplication, contradiction checking, and relevance filtering
             - Accepted lessons written to each recipient's PROPAGATED.md

02:30        Verification and soul patch application
             - Three-Gate Verification runs on all proposed soul updates
             - Passing proposals are compiled into soul patches
             - Patches are applied to agent souls
             - Failing proposals are written to PROPOSED_SOUL_CHANGES.md

03:00        Complete
             - Agents resume with updated souls
             - Nightly summary is written to .learnings/nightly/
             - Health signals are emitted for monitoring

The Nightly Loop Prompt (Full Text)

This is the complete prompt run by each agent during its nightly reflection window. All six sections must be completed.

You are reviewing your performance from the past 24 hours. You have access to
your full interaction logs, error reports, and performance metrics for today.

Complete ALL six sections below. Be brutally honest. The purpose of this
reflection is compound improvement -- small, true corrections that accumulate
over time. Do not be defensive. Do not rationalize failures. Do not propose
changes you are not confident about.

═══════════════════════════════════════════════════════════════
SECTION 1: PERFORMANCE ASSESSMENT
═══════════════════════════════════════════════════════════════

Rate your performance on each dimension from 1 (poor) to 5 (excellent).
You MUST provide specific evidence for each rating. A rating without evidence
is worthless.

Dimensions:
- ACCURACY: Were your outputs factually correct and technically sound?
  Rating: _/5 | Evidence: [specific examples from today]

- EFFICIENCY: Did you solve problems with minimal unnecessary steps?
  Rating: _/5 | Evidence: [specific examples from today]

- COMMUNICATION: Were your responses clear, appropriately scoped, and
  well-structured for the audience?
  Rating: _/5 | Evidence: [specific examples from today]

- JUDGMENT: Did you make good decisions about when to act, when to ask,
  when to escalate, and when to stop?
  Rating: _/5 | Evidence: [specific examples from today]

- SOUL_ADHERENCE: Did you follow your existing soul rules consistently?
  Rating: _/5 | Evidence: [specific examples from today]

- COLLABORATION: Did you work well with other agents and humans?
  Rating: _/5 | Evidence: [specific examples from today]

═══════════════════════════════════════════════════════════════
SECTION 2: FAILURES AND NEAR-MISSES
═══════════════════════════════════════════════════════════════

List every failure and near-miss from today. A failure is an outcome that
did not meet the expected standard. A near-miss is a situation where you
almost failed but recovered or got lucky.

For each entry:
- WHAT HAPPENED: [factual description, no editorializing]
- ROOT CAUSE: [the actual reason, not the surface symptom]
- PROPOSED RULE: [a concrete, imperative rule that would prevent recurrence]
- CONFIDENCE: [HIGH / MEDIUM / LOW that this rule would help]

If there were no failures or near-misses, state "None identified" and
explain what evidence you reviewed to reach that conclusion.

═══════════════════════════════════════════════════════════════
SECTION 3: LESSON EXTRACTION
═══════════════════════════════════════════════════════════════

Extract lessons from today using the lesson taxonomy. Each lesson must be
one of: ERROR, CORRECTION, PATTERN, ANTI_PATTERN, DISCOVERY, EFFICIENCY.

Output each lesson in LRN format (one JSON object per line):

{"id":"LRN-AGENT-YYYYMMDD-NNN","type":"TYPE","priority":"P1|P2|P3","area":"domain","summary":"one line","trigger":"when X happens","rule":"always/never do Y","evidence":"proof in ≤50 words","cross_agent_relevant":true|false,"if_yes_why":"reason or null"}

Extract ALL lessons, not just failures. Successful patterns and efficiency
gains are equally valuable.

═══════════════════════════════════════════════════════════════
SECTION 4: SOUL UPDATE PROPOSALS
═══════════════════════════════════════════════════════════════

Based on your lessons and performance assessment, propose specific changes
to your soul (system prompt / behavioral rules).

For each proposal:
- CURRENT RULE: [the existing rule text, or "NEW" if adding a rule]
- PROPOSED RULE: [the exact new rule text]
- CONFIDENCE: [HIGH / MEDIUM / LOW]
- CHANGE TYPE: [ADD / MODIFY / REMOVE]
- JUSTIFICATION: [why this change will improve performance, with evidence]

Rules for proposals:
- Each proposed rule must be imperative (a direct instruction).
- Each proposed rule must be specific enough to be actionable.
- Do not propose vague rules like "be more careful."
- Do not propose rules that contradict existing high-confidence soul rules
  unless you explicitly flag the contradiction.
- Limit to 5 proposals maximum per night. Quality over quantity.

═══════════════════════════════════════════════════════════════
SECTION 5: CROSS-AGENT SIGNALS
═══════════════════════════════════════════════════════════════

Identify lessons from today that would be valuable to other agents.

For each signal:
- RECIPIENT(S): [agent name(s) or "ALL"]
- LESSON ID: [reference to the LRN ID from Section 3]
- WHY RELEVANT: [specific reason this helps the recipient]

Only flag lessons that are genuinely cross-applicable. Do not signal
lessons that are specific to your domain unless another agent shares
that domain.

═══════════════════════════════════════════════════════════════
SECTION 6: TOMORROW'S FOCUS
═══════════════════════════════════════════════════════════════

Based on today's performance, state ONE concrete instruction for yourself
tomorrow. This should be:
- Specific (not "do better")
- Observable (someone watching could tell if you followed it)
- Targeted at your weakest dimension from Section 1

Format: "Tomorrow, I will [specific action] because [reason from today]."

Lesson Taxonomy

Every extracted lesson must be classified into exactly one of six types.

ERROR

A mistake that caused a failure or degraded outcome.

Example: Provided an API endpoint URL that was deprecated in v3, causing the user's integration to fail. Root cause was relying on cached knowledge instead of checking current documentation.

CORRECTION

A mid-session self-correction where the agent caught and fixed its own mistake before it caused a failure.

Example: Started generating a SQL query with string interpolation, recognized the injection risk mid-generation, and rewrote it using parameterized queries before delivering the response.

PATTERN

A successful approach that produced good outcomes and is worth repeating deliberately.

Example: When the user's question was ambiguous, asked one clarifying question before proceeding instead of guessing. This avoided a wasted round-trip and the user expressed appreciation for the efficiency.

ANTI_PATTERN

An approach that appears to work initially but causes downstream problems.

Example: Generating a monolithic function to "keep things simple" for the user. The initial response looked clean, but when the user needed to modify one part, the lack of decomposition made the change error-prone and confusing.

DISCOVERY

A new fact, capability, or context learned during the session.

Example: Discovered that the project uses a custom Babel plugin that transforms import paths at build time. This explains why the source imports don't match the bundled output and affects how file references should be provided.

EFFICIENCY

A faster, cheaper, or simpler way to accomplish something.

Example: Instead of reading 15 files to understand a module's interface, reading the barrel export file (index.ts) first gave a complete API surface in one read, reducing tool calls from 15 to 3.

The LRN Lesson Format

Lessons are stored in JSONL format (one JSON object per line). Every lesson must include all fields.

Field Specification

Field	Type	Required	Description
`id`	string	yes	Unique ID: `LRN-{AGENT}-{YYYYMMDD}-{NNN}`
`type`	enum	yes	One of: `ERROR`, `CORRECTION`, `PATTERN`, `ANTI_PATTERN`, `DISCOVERY`, `EFFICIENCY`
`priority`	enum	yes	`P1` (critical), `P2` (important), `P3` (minor)
`area`	string	yes	Domain area (e.g., `code-generation`, `debugging`, `communication`, `tool-use`)
`summary`	string	yes	One-line summary of the lesson
`trigger`	string	yes	The condition that activates this lesson: "when X happens"
`rule`	string	yes	Imperative instruction: "always/never do Y"
`evidence`	string	yes	Proof from today's session, 50 words or fewer
`cross_agent_relevant`	boolean	yes	Whether this lesson applies to other agents
`if_yes_why`	string\|null	yes	If cross-agent relevant, explain why. Otherwise `null`

Complete Example

hljs jsonl{"id":"LRN-jerry-20260217-001","type":"ERROR","priority":"P1","area":"code-generation","summary":"Generated deprecated API call that broke user integration","trigger":"when generating API calls for external services","rule":"always verify API endpoint currency against official docs before including in generated code","evidence":"User reported 404 on /v2/users endpoint. Current docs show /v3/users. I relied on training data instead of checking.","cross_agent_relevant":true,"if_yes_why":"All agents generating API calls face the same staleness risk"}
{"id":"LRN-jerry-20260217-002","type":"PATTERN","priority":"P2","area":"communication","summary":"Clarifying question before ambiguous task prevented wasted round-trip","trigger":"when user request has two or more plausible interpretations","rule":"always ask one targeted clarifying question before proceeding with ambiguous requests","evidence":"User asked to 'update the config.' Asked which config file. Saved a wrong-file edit and redo cycle.","cross_agent_relevant":true,"if_yes_why":"Ambiguity handling is universal across all agent domains"}
{"id":"LRN-jerry-20260217-003","type":"EFFICIENCY","priority":"P3","area":"tool-use","summary":"Reading barrel exports first reduces file reads by 80%","trigger":"when exploring an unfamiliar TypeScript module","rule":"always read index.ts or barrel export file first before diving into individual module files","evidence":"Module had 15 files. Reading index.ts revealed the full public API in one call. Reduced reads from 15 to 3.","cross_agent_relevant":false,"if_yes_why":null}

The Three-Gate Verification System

Every proposed soul update must pass through three gates before being auto-applied. This prevents low-quality or contradictory rules from entering the soul.

Gate 1: Occurrence Threshold

A proposed rule must meet at least one of these criteria:

Frequency: The triggering event has occurred 3 or more times across sessions
High confidence + high score: The proposing agent rated it HIGH confidence AND the performance score for the relevant dimension is >= 0.80
Cross-agent corroboration: At least one other agent independently proposed a similar rule

Pass: At least one criterion met. Fail: None met. Rule is discarded or held for more data.

Gate 2: Shadow A/B Test (Medium Confidence Only)

For proposals rated MEDIUM confidence:

The rule is applied in shadow mode for 3 sessions
Agent behavior with the rule is compared against baseline behavior without it
Metrics tracked: accuracy delta, efficiency delta, user satisfaction proxy
If the rule shows neutral or positive impact, it passes
If the rule shows negative impact (any dimension drops > 0.03), it fails

Pass: Neutral or positive impact after 3 sessions. Fail: Negative impact detected. Skip: HIGH confidence proposals skip this gate.

Gate 3: Contradiction Check

The proposed rule is compared against all existing soul rules:

Direct contradictions are flagged (e.g., "always ask before acting" vs. "act immediately on clear requests")
Subsumption is checked (does an existing rule already cover this?)
Scope conflicts are identified (does this rule's scope overlap with another rule's scope in incompatible ways?)

Pass: No contradictions, no subsumption, no scope conflicts. Fail: Contradiction or conflict detected. Requires human resolution.

Outcome Matrix

Gates Passed	Action
2 or more gates pass	Auto-apply: Soul patch is generated and applied automatically
Exactly 1 gate passes	Queue for review: Written to `PROPOSED_SOUL_CHANGES.md` for human review
0 gates pass	Discard: Rule is logged but not applied or queued

Soul Patch Format

Soul patches use YAML frontmatter followed by a before/after diff format. Each patch modifies exactly one rule in the agent's soul.

Structure

hljs yaml[object Object],
,[object Object], ,[object Object],
,[object Object], {,[object Object],}
,[object Object], {,[object Object],}
,[object Object], {,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],}
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], [,[object Object],, ,[object Object],, ,[object Object],]  ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object],
,[object Object],

{,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],, ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],}

,[object Object],

{,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],, ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],}

,[object Object],

{,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],,
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],}

Complete Example

hljs yaml[object Object],
,[object Object], ,[object Object],
,[object Object], ,[object Object],
,[object Object], ,[object Object],
,[object Object], ,[object Object],
,[object Object], ,[object Object],
,[object Object], ,[object Object],
,[object Object], [,[object Object],, ,[object Object],]
,[object Object], ,[object Object],
,[object Object],
,[object Object],

,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],

,[object Object],

,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],

,[object Object],

,[object Object], ,[object Object],[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],
,[object Object], ,[object Object], ,[object Object], ,[object Object], ,[object Object],

PROPOSED_SOUL_CHANGES.md Format

This file collects soul update proposals that passed only one verification gate and require human review. Soul Engineer reviews this file during weekly check-ins.

Structure

hljs markdown[object Object],

,[object Object],
,[object Object],
,[object Object],

---

,[object Object],

,[object Object], ,[object Object],: {agent,[object Object]

Example Entry

hljs markdown[object Object],

,[object Object], ,[object Object],: gary
,[object Object], ,[object Object],: 2026-02-17
,[object Object], ,[object Object],: LRN-gary-20260217-004
,[object Object], ,[object Object],: ADD
,[object Object], ,[object Object],: MEDIUM
,[object Object], ,[object Object],: [2]
,[object Object], ,[object Object],: [1 (only 1 occurrence), 3 (partial overlap with existing rule G-14)]

,[object Object],
N/A (new rule)

,[object Object],
When a user provides a file path that does not exist, check for common typos
(case sensitivity, missing extension, wrong directory depth) before reporting
the file as not found.

,[object Object],
User provided path ,[object Object], which did not exist. Actual path
was ,[object Object], (lowercase 'c'). A case-insensitive search would
have found it immediately instead of requiring a follow-up exchange.

,[object Object],
Gate 1: Only one occurrence so far (needs 3+ or cross-agent corroboration).
Gate 3: Partial overlap with existing rule G-14 ("verify paths before reporting
errors") -- may be a refinement rather than a new rule.

,[object Object],
,[object Object], [ ] APPROVE
,[object Object], [ ] REJECT
,[object Object], [ ] MODIFY
,[object Object], [ ] DEFER

,[object Object],: ,[object Object]

Cross-Agent Propagation Protocol

Cross-agent propagation ensures that a lesson learned by one agent benefits all agents who face similar situations.

Step 1: Tag Lessons

During the nightly loop (Section 5 of the prompt), each agent tags lessons with cross_agent_relevant: true and specifies recipients and reasoning.

Step 2: Nightly Propagation Prompt

At 02:00 EST, the propagation system runs the following prompt against all cross-agent signals collected that night:

You are the cross-agent propagation filter. You have received the following
cross-agent signals from tonight's nightly loops.

For each signal, evaluate:
1. DEDUPLICATION: Has an equivalent lesson already been propagated to the
   recipient in the last 30 days? If yes, skip it.
2. CONTRADICTION: Does this lesson contradict an existing rule in the
   recipient's soul? If yes, flag for human review instead of propagating.
3. RELEVANCE: Is this lesson genuinely applicable to the recipient's domain
   and responsibilities? Rate relevance 1-5. Only propagate if relevance >= 3.

For each signal that passes all three filters, output a propagation entry
in the following format:

PROPAGATE:
  from: {source agent}
  to: {recipient agent}
  lesson_id: {LRN ID}
  summary: {one line}
  rule: {imperative rule text}
  relevance_score: {1-5}
  notes: {any adaptation needed for the recipient's context}

Step 3: Filter Results

The propagation system applies the filter decisions:

Duplicate: Silently skipped, logged for audit
Contradiction: Written to PROPOSED_SOUL_CHANGES.md with CONTRADICTION flag
Low relevance (< 3): Silently skipped, logged for audit
Passes all filters: Delivered to recipient

Step 4: Deliver to PROPAGATED.md

Accepted propagations are appended to each recipient's .learnings/PROPAGATED.md:

hljs markdown[object Object],

,[object Object], ,[object Object],: {source agent}
,[object Object], ,[object Object],: {YYYY-MM-DD}
,[object Object], ,[object Object],: {N}/5
,[object Object], ,[object Object],: {one line}
,[object Object], ,[object Object],: {imperative rule text}
,[object Object], ,[object Object],: {any context-specific adjustments}
,[object Object], ,[object Object],: PENDING,[object Object]

The recipient agent reviews propagated lessons during its next nightly loop and decides whether to integrate, adapt, or reject each one.

Anti-Echo-Chamber Safeguards

These safeguards prevent the compound loop from converging on suboptimal local maxima or reinforcing biases.

1. Devil's Advocate Prompt

After each agent generates its soul update proposals (Section 4), the following adversarial prompt is run:

You are a Devil's Advocate reviewer. Your job is to challenge each proposed
soul rule change. For each proposal:

1. What is the strongest argument AGAINST this rule?
2. In what scenario would this rule cause WORSE performance?
3. Is this rule a reaction to a single outlier event, or a genuine pattern?
4. Does this rule reduce the agent's flexibility in ways that could hurt
   performance on edge cases?
5. Is the evidence sufficient, or is the agent over-fitting to today's data?

Rate your overall objection strength: STRONG / MODERATE / WEAK.

If STRONG: The proposal should not be applied without human review.
If MODERATE: The proposal should pass through Gate 2 (shadow A/B test)
regardless of confidence level.
If WEAK: No additional action needed.

2. Cross-Agent Contradiction Detection

During propagation, all proposed rules (both local and propagated) are compared pairwise:

If Agent A proposes "always do X" and Agent B proposes "never do X," both proposals are flagged
The contradiction is written to PROPOSED_SOUL_CHANGES.md for both agents
Neither rule is auto-applied until the contradiction is resolved

3. Human Checkpoint Frequency

The system tracks the count of unreviewed auto-applied changes per agent:

If any agent accumulates more than 5 unreviewed auto-applied changes, the compound loop is paused for that agent
The pause persists until Soul Engineer reviews and acknowledges the accumulated changes
This prevents runaway drift even when all gates pass

4. Regression Benchmark Detection

After each nightly loop application:

The agent's performance scores from the next day are compared against a rolling 7-day average
If any dimension score drops by more than 0.05 compared to the 7-day average:
- The most recent soul patch is automatically reverted
- The reverted patch is written to PROPOSED_SOUL_CHANGES.md with a REGRESSION_DETECTED flag
- Soul Engineer is notified
If scores remain stable or improve, the patch is confirmed permanent

The Reflexion Self-Critic Prompt

This prompt is used after identified failures (from Section 2 of the nightly loop) to perform deeper analysis. It runs as a follow-up for any failure rated P1 or P2.

You experienced a failure during today's session. Here is the failure report:

[FAILURE REPORT INSERTED HERE]

You are now acting as your own critic. Your goal is to perform a Reflexion-style
analysis that goes beyond surface-level root cause analysis.

Step 1: TRAJECTORY ANALYSIS
Replay the sequence of actions that led to the failure. For each action, state:
- What you did
- What you expected to happen
- What actually happened
- At what point could you have detected the divergence?

Step 2: COUNTERFACTUAL REASONING
Describe the alternative trajectory:
- What should you have done differently at the earliest divergence point?
- What information did you have at that point that should have triggered
  a different action?
- What information did you NOT have that you should have sought?

Step 3: ABSTRACTION
Abstract the lesson away from this specific failure:
- What GENERAL class of error does this represent?
- What TRIGGER PATTERN should you watch for in the future?
- What CHECK should you perform when you detect that trigger?

Step 4: RULE FORMULATION
Write a concrete, imperative rule that:
- Is triggered by an observable condition (not "be more careful")
- Specifies a concrete action (not "think harder")
- Can be evaluated for compliance (someone watching could tell if you followed it)
- Does not over-constrain your behavior for non-failure cases

Step 5: CONFIDENCE CALIBRATION
- How confident are you that this rule would have prevented TODAY's failure? (1-10)
- How confident are you that this rule will not cause NEW failures? (1-10)
- If either score is below 7, what additional evidence would raise your confidence?

Output the final rule in LRN format.

Cron Schedule

All 15 agents (excluding Barry — isolation architecture incompatible with compound loops) run nightly loops staggered 10 minutes apart to avoid API rate limit contention.

Agent	Role	Cron (EST)	Model
jerry	COO	`0 1 * * *`	sonnet-4-5
gary	CTO	`10 1 * * *`	sonnet-4-5
cherry	Revenue	`20 1 * * *`	sonnet-4-5
lacie	CEO	`30 1 * * *`	sonnet-4-5
larry	CFO	`40 1 * * *`	sonnet-4-5
perry	Frontend Dev	`50 1 * * *`	sonnet-4-5
harry	Backend Dev	`0 2 * * *`	sonnet-4-5
cory	Smart Contracts	`5 2 * * *`	sonnet-4-5
rory	Design	`10 2 * * *`	sonnet-4-5
dory	Brand Design	`15 2 * * *`	sonnet-4-5
mary	CMO	`20 2 * * *`	sonnet-4-5
carrie	Copywriter	`25 2 * * *`	sonnet-4-5
ori	SEO	`30 2 * * *`	sonnet-4-5
watchdog	Security	`35 2 * * *`	sonnet-4-5
terry (personal)	Mentor	`40 2 * * *`	sonnet-4-5

Soul Engineer Weekly Batch: 45 2 * * 0 (Sundays only, Opus)

Barry: No compound loop. Isolation architecture requires behavioral updates flow through Jerry's bridge as human-reviewed briefings, not autonomous self-modification.

All loop sessions use sessionTarget: "isolated" and wakeMode: "now". Timeout: 900 seconds. Model: sonnet-4-5 (Opus only for Soul Engineer weekly audit).

Verification and Quality Gates

Use these signals to verify the compound loop is functioning correctly.

Health Signals (Check Daily)

Signal	Healthy	Unhealthy
Nightly summary files generated	All 15 agents have a file in `.learnings/nightly/` for today's date	Missing files indicate a failed loop
Lesson extraction count	At least 1 lesson per agent per night on average	Zero lessons for 3+ consecutive nights suggests the prompt is not working
Soul patch application rate	1-3 patches auto-applied per agent per week	Zero patches for 2+ weeks suggests gates are too strict; 5+ per night suggests gates are too loose
Regression revert rate	< 10% of patches are reverted	> 20% revert rate indicates the gates are not filtering effectively
Human review queue depth	< 5 pending proposals per agent	> 5 triggers automatic pause (by design)
Cross-agent propagation	At least 1 propagation per night across all agents	Zero propagations for a week suggests agents are not flagging cross-agent lessons

Weekly Health Check (Soul Engineer)

Review PROPOSED_SOUL_CHANGES.md for each agent with pending proposals
Check regression revert log for patterns (same rule type failing repeatedly)
Verify no agent has been paused due to unreviewed changes
Spot-check 2-3 auto-applied patches for quality
Review cross-agent propagation log for contradictions or duplicates
Confirm cron jobs are running on schedule (check system logs)

Monthly Health Check (Soul Engineer)

Compare each agent's performance trend over the month (are scores improving?)
Audit the lesson taxonomy distribution (healthy distribution vs. all errors)
Review the Devil's Advocate objection rate (are strong objections being generated?)
Check for soul bloat (is the rule count growing unsustainably?)
Prune obsolete rules that are no longer triggering

File Structure

Each agent's workspace must contain the following files and directories for the compound loop to function.

{agent_workspace}/
  .learnings/
    ERRORS.md              # Cumulative log of ERROR-type lessons
    LEARNINGS.md           # Cumulative log of all lessons (all types)
    PROPAGATED.md          # Cross-agent lessons received from other agents
    soul-patches/          # Directory containing applied soul patch files
      SP-{agent}-{date}-{NNN}.md
    nightly/               # Directory for nightly reflection summaries
      {YYYY-MM-DD}.md      # One file per night
  PROPOSED_SOUL_CHANGES.md # Proposals awaiting human review

File Descriptions

.learnings/ERRORS.md Append-only log of ERROR-type lessons. Each entry includes the LRN ID, date, summary, and rule. Used for quick reference when debugging recurring issues.

.learnings/LEARNINGS.md Append-only log of all lessons across all types. This is the complete record. Entries are in LRN JSONL format, one per line, with a markdown header per date.

.learnings/PROPAGATED.md Lessons received from other agents via cross-agent propagation. Each entry includes the source agent, relevance score, and integration status (PENDING_INTEGRATION, INTEGRATED, REJECTED).

.learnings/soul-patches/ Directory containing all applied soul patches as individual markdown files. Each file follows the Soul Patch Format described above. Files are named SP-{agent}-{YYYYMMDD}-{NNN}.md.

.learnings/nightly/ Directory containing nightly reflection summaries. Each file is named {YYYY-MM-DD}.md and contains the complete output of that night's loop prompt (all 6 sections).

PROPOSED_SOUL_CHANGES.md Located at the workspace root. Contains soul update proposals that require human review (passed only 1 gate, or flagged by Devil's Advocate, or involved a contradiction).

Quick Reference: Soul Engineer Weekly Checklist

Review all PROPOSED_SOUL_CHANGES.md files across agents
Approve, reject, modify, or defer each pending proposal
Check for paused agents (>5 unreviewed changes) and unblock them
Review regression revert log
Spot-check 2-3 auto-applied patches per agent
Verify cron schedule health
Clear reviewed entries from PROPOSED_SOUL_CHANGES.md

Compound Loop Implementation Guide

Overview#

Architecture#

The Nightly Loop Prompt (Full Text)#

Lesson Taxonomy#

ERROR#

CORRECTION#

PATTERN#

ANTI_PATTERN#

DISCOVERY#

EFFICIENCY#

The LRN Lesson Format#

Field Specification#

Complete Example#

The Three-Gate Verification System#

Gate 1: Occurrence Threshold#

Gate 2: Shadow A/B Test (Medium Confidence Only)#

Gate 3: Contradiction Check#

Outcome Matrix#

Soul Patch Format#

Structure#

Complete Example#

PROPOSED_SOUL_CHANGES.md Format#

Structure#

Example Entry#

Cross-Agent Propagation Protocol#

Step 1: Tag Lessons#

Step 2: Nightly Propagation Prompt#

Step 3: Filter Results#

Step 4: Deliver to PROPAGATED.md#

Anti-Echo-Chamber Safeguards#

1. Devil's Advocate Prompt#

2. Cross-Agent Contradiction Detection#

3. Human Checkpoint Frequency#

4. Regression Benchmark Detection#

The Reflexion Self-Critic Prompt#

Cron Schedule#

Verification and Quality Gates#

Health Signals (Check Daily)#

Weekly Health Check (Soul Engineer)#

Monthly Health Check (Soul Engineer)#

File Structure#

File Descriptions#

Quick Reference: Soul Engineer Weekly Checklist#

Overview

Architecture

The Nightly Loop Prompt (Full Text)

Lesson Taxonomy

ERROR

CORRECTION

PATTERN

ANTI_PATTERN

DISCOVERY

EFFICIENCY

The LRN Lesson Format

Field Specification

Complete Example

The Three-Gate Verification System

Gate 1: Occurrence Threshold

Gate 2: Shadow A/B Test (Medium Confidence Only)

Gate 3: Contradiction Check

Outcome Matrix

Soul Patch Format

Structure

Complete Example

PROPOSED_SOUL_CHANGES.md Format

Structure

Example Entry

Cross-Agent Propagation Protocol

Step 1: Tag Lessons

Step 2: Nightly Propagation Prompt

Step 3: Filter Results

Step 4: Deliver to PROPAGATED.md

Anti-Echo-Chamber Safeguards

1. Devil's Advocate Prompt

2. Cross-Agent Contradiction Detection

3. Human Checkpoint Frequency

4. Regression Benchmark Detection

The Reflexion Self-Critic Prompt

Cron Schedule

Verification and Quality Gates

Health Signals (Check Daily)

Weekly Health Check (Soul Engineer)

Monthly Health Check (Soul Engineer)

File Structure

File Descriptions

Quick Reference: Soul Engineer Weekly Checklist