Skip to content

Self-Improving Skills

G6's evolution loop discovers better strategies using EvoSkill. In the T0-T3 framework, this is the T2 mechanism: two adaptive traverses, data and learning, that enable continuous improvement with fixed learning rules. When the evolution loop itself is improved by the system, such as learning better mutation strategies or better evaluation criteria, it becomes T3: learning how to learn.

Guided reliability workflow, not self-training magic

EvoSkill is designed to support a guided reliability workflow: run a reliability check, review failures, apply a suggested improvement, validate on holdout or frozen data, and export the resulting harness. It should not be treated as a fully autonomous production agent that can improve itself without review. Production claims should be based on the learning_layer validation evidence emitted by a run, especially learning_validation, launch_ready, mutation-disabled holdout/frozen checks, and anti-leakage attestation.

The Problem

LLM agents make the same mistakes repeatedly. A prompt that works for most cases can fail on important edge cases, and ad-hoc prompting gives you no durable record of what improved, what regressed, or what evidence supports deployment.

The 5-Stage Evolution Cycle

graph TD
    A[1. Base Agent Attempts Tasks] --> B[2. Proposer Analyses Failures]
    B --> C[3. Generator Creates New Skill or Prompt]
    C --> D[4. Evaluator Scores Variant]
    D --> E{Improved?}
    E -->|Yes| F[5. Add to Frontier]
    E -->|No| G[Record Feedback]
    F --> H[Learning Layer Validation]
    H --> A
    G --> B

Stage 1: Attempt

The base agent runs on a set of tasks. Failures are collected with execution traces where available.

Stage 2: Propose

The proposer agent analyses failure traces and suggests either a new skill or a prompt mutation. It considers:

  • What capability was missing?
  • Has this failure pattern been seen before?
  • Would a skill or prompt change fix more than one case?

Stage 3: Generate

The generator creates the skill document or rewritten prompt from the proposal.

Stage 4: Evaluate

The new variant is scored against validation data. Scoring uses fuzzy matching with configured tolerance.

For production-facing runs, EvoSkill also replays the selected candidate through the validated learning_layer. That replay is mutation-disabled by default and records sealed attempts, validation phase, anti-leakage attestation, and a conservative launch_ready signal.

Stage 5: Select

If the variant improves on the current best, it enters the frontier. The frontier preserves top performers while worse mutations are recorded as feedback.

The Frontier

G6 maintains a frontier of top-performing program variants. This reduces catastrophic forgetting: even if a new mutation is worse, the previous best is preserved.

The frontier is not, by itself, a production guarantee. A candidate should be presented as launch-ready only when the learning-layer validation evidence supports that claim.

Safety Constraints

The evolution loop is bounded by:

  • Hard iteration cap: 100 maximum, configurable lower
  • Resource bounds through ResourceGuardrail
  • Static safety checks on generated skill code before frontier entry
  • Learning-layer validation with mutation-disabled replay before treating a candidate as launch-ready
  • Optional human-in-the-loop review before using generated skills in production workflows

Expose EvoSkill to end users as a reliability assistant with receipts:

  1. Run reliability check on a named workflow and labeled examples.
  2. Review failures and proposed fixes in plain language.
  3. Apply suggested improvement only inside the bounded train path.
  4. Validate on holdout/frozen data with learning_layer mutation disabled.
  5. Export harness only when validation evidence supports the claim.

Avoid copy that says EvoSkill "automatically makes your app reliable." Prefer evidence-based phrasing such as "EvoSkill proposed an improvement and it passed holdout validation with anti-leakage checks."

MCP Tools

Tool Tier Description
evolve_skills Builder Run the evolution loop and return validation evidence
propose_skill Builder Get a skill proposal for failures
generate_skill Builder Generate code from a proposal
evaluate_program Builder Score a variant
list_programs Researcher List program variants
get_frontier Researcher View the current frontier
feedback_descent_run Builder Generic optimisation loop

FAQ

Q: How long does an evolution run take?
A: Each iteration can require multiple LLM calls. A 5-iteration run typically takes 5-15 minutes depending on task complexity.

Q: Can I control what gets evolved?
A: Yes. You choose the task, dataset, evolution mode (skill_only or prompt_only), budget, and whether learning-layer validation is enabled. Production-facing runs should leave validation enabled.

Q: Is generated code safe?
A: Generated skills pass through static safety checks before frontier entry. Clean safety checks are useful evidence, not a proof of production safety. Use human review and holdout/frozen validation for production workflows.