FastSlow Evo is a dual-loop self-evolution system for AI agents.
It helps an agent improve through two iterative loops:
- Fast loop: rapid local adaptation for small, repeated, low-risk mistakes
- Slow loop: cautious long-term promotion for patterns that have proven stable and worth keeping
FastSlow Evo is not a logging system, not a Python rule engine, and not a black-box self-modification tool.
Its purpose is to help an agent decide:
- what should be fixed quickly
- what should be promoted slowly
- what should stay under observation
- what should be ignored
- what should be explicitly rejected
In OpenClaw, FastSlow Evo works by combining:
- real evidence from incidents, corrections, and repeated wins
- host-model semantic judgment
- markdown protocols for review discipline, convergence, validation, and rollback
The result is a self-evolution workflow that avoids both failure modes:
- under-evolution: useful experience never becomes capability
- over-evolution: local noise hardens into bad long-term policy
FastSlow Evo does not treat every problem equally.
Some issues should stay local:
- a tone correction
- a missed detail in one summary
- a small validation miss
Some issues deserve durable review:
- repeated omissions across similar tasks
- stable failure patterns across contexts
- workflow-level gaps that local fixes no longer contain
That is why FastSlow Evo uses two loops.
FastSlow Evo is a judgment-driven dual-loop system that routes experience into fast local adaptation or slow durable promotion, so an agent can evolve without either forgetting useful lessons or overfitting to noise.
SKILL.md— operating instructions for OpenClawreferences/— protocols, rubrics, reading order, examples, and usable workflowassets/— markdown templatesspecs/— example durable artifacts
Python helpers have been removed from the default design. FastSlow is now protocol-first and model-driven.
Read:
references/runtime-core/minimal-usable-workflow.md
That file is the shortest path to a usable FastSlow workflow.
If you need the full protocol stack, read:
references/runtime-optional/openclaw-judgment-first.mdreferences/runtime-core/protocol-reading-order.mdreferences/runtime-branches/evidence-protocol.mdreferences/runtime-core/review-protocol.mdreferences/runtime-core/evaluation-rubric.mdreferences/runtime-core/review-output-format.mdreferences/runtime-branches/candidate-protocol.mdreferences/runtime-branches/heartbeat-protocol.md
- Write one evidence markdown file from the template.
- Preserve full context and raw signal.
- Let OpenClaw review it using the protocol files.
- Choose one state:
- fast
- slow-candidate
- observe
- ignore
- reject
- Apply the smallest justified next step.
- Read the candidate protocol and checklist.
- Read linked evidence.
- Judge whether the candidate should:
- merge
- stay separate
- split
- supersede
- create
- do nothing
- Write back the review using the standard review output format.
- Read the heartbeat protocol.
- Review recent evidence and current candidates.
- Output either:
- no-action
- update existing candidate
- create one candidate
- split candidate
- reject candidate
Start with:
references/examples/example-fast.mdreferences/examples/example-slow-candidate.mdreferences/examples/example-reject.md
These cover the three highest-value review paths:
- when to keep a fix local
- when to create or update one durable candidate
- when to reject or roll back a weak candidate
Older worked examples remain in references/ for maintenance and deeper study.
It is not:
- a Python rule engine
- a file spammer that turns every event into a candidate
- a shortcut for promoting weak evidence
- an excuse for uncontrolled self-modification
Fast where local adaptation is enough. Slow only when durable promotion is earned.