Self-evolution
Find problems in task outcomes, verify improvements, and retain experience for future work.
Evolver is the engine that runs evolution workflows, either independently or through an application integration. It is distinct from ordinary chats, scheduled tasks, and long-term goals. Execution and allowed changes depend on the configured environment.
When to use it
Self-evolution needs a reproducible problem, a clear improvement target, and a way to verify results. Define the task before choosing a direction.
| Direction | Suitable situation | How to judge the result |
|---|---|---|
| Repair | Errors, failed tests, or broken behavior | The original issue is resolved and related behavior still works |
| Optimize | Performance, cost, latency, or code quality needs improvement | Compare before and after, checking for regressions |
| Innovate | A required capability or integration is missing | New behavior meets explicit acceptance criteria |
| Explore | Repeated attempts produce no useful improvement | Find a testable problem or approach, not simply more changes |
These are evolution intents, not four mandatory sequential steps.
How a cycle works
- Gather signals: Review errors, test results, task records, or other available evidence.
- Choose a direction: Decide whether to repair, optimize, innovate, or explore.
- Form a plan: Define scope, validation, and stop conditions.
- Execute and verify: Work within the allowed scope and run the appropriate checks.
- Record the outcome: Retain validation results, environment details, and useful logs.
Finishing a change does not mean validation passed. When an attempt yields no improvement, record why rather than treating unverified work as a successful lesson.
Prepare before starting
Choose an entry point first: for the standalone engine, follow Evolver CLI and start with one cycle in a test repository. For an existing agent integration, follow the host’s actual tool configuration. Reading this page does not enable self-evolution for ordinary desktop tasks.
Prepare a reproducible problem and its checks, retaining the original failure evidence. Verify a fix under the same conditions before deciding to retain it. Installation and execution parameters belong in the developer guide.
Retain and reuse experience
Example: repair a reproducible export failure
Suppose an export fails when a filename contains special characters. Preserve the triggering input, failure, and dependency versions in a test repository. Limit the goal to fixing filename handling without changing the exported content. This is an acceptance example, not a task that runs automatically:
- Reproduce the failure with the original input, ruling out temporary service unavailability or missing material.
- Let the engine form a minimal fix within the allowed scope, retaining the diff.
- Verify the original input and check an ordinary filename for regressions.
- Once all checks pass, record applicability, method, and results. Commits or publishing still follow their authorization workflow.
If the issue cannot be reproduced, the fix introduces another failure, or the cycle yields no improvement, retain the evidence and stop expanding the changes. Recovery should affect only this cycle's edits while preserving other work. Completing a cycle or generating an asset does not establish a verified improvement.
Record a reusable outcome
Useful experience explains which approach worked under which conditions. Include the problem, key steps, validation results, and limitations.
Evolver uses assets such as Genes, Capsules, and EvolutionEvents to record methods, outcomes, and the evolution process. Check the environment and applicability before reuse; success on an earlier task does not remove the need to validate a new one.
- Genes: Reusable methods.
- Capsules: Outcomes and experience assets.
- Evolution events: Process records.
Loops and exploration
Strategies prioritize the kind of work, loop settings determine whether execution continues, and change boundaries limit each cycle.
Exploration can broaden the search after saturation or repeated no-op cycles, for example by checking TODOs, stale files, or reusable assets. It still needs cooldowns and stop conditions rather than indefinite execution or aimless changes.
Confirm the workspace and validation approach in a single cycle or review mode before enabling continuous execution. See Evolution behavior for parameters; standalone Evolver settings are not desktop task switches.
Permissions and approval
Strategies and loops do not expand permissions. External access, deletion, commits, asset publication, and production writes retain their own authorization and approval requirements.
When validation fails, do not continue to publication or record a reusable success. Follow the environment's rollback configuration when recovery is needed, preserving unrelated workspace changes.
Troubleshooting
- Repeated cycles without useful improvement: Review signals, goals, and stop conditions instead of simply running longer.
- Changes with no clear evidence of success: Establish reproduction and acceptance checks before judging the result.
- Old experience fails in a new environment: Check dependencies, versions, and scope, then validate again.
- No matching desktop switch: This page describes the evolution process. Consult developer and configuration guides for standalone engine installation and settings.