Agent Harness Wiki

4 min read

Self-Evolving Workflows

Definition

Self-evolving workflows are agent procedures that do not remain frozen after initial authoring. The workflow itself becomes a versioned artifact that can be induced from traces, mutated, assessed, selected, and promoted. Depending on the system, that artifact may look like a graph, a natural-language routine, a structured skill package, a memory operation policy, or an instruction kernel compiled from experience.

What can actually evolve

The literature now splits into several distinct evolution surfaces:

  • Workflow topology — systems such as AFlow, AutoFlow, MermaidFlow, and DyFlow search over explicit workflow graphs or dynamic operator sequences.
  • Workflow evaluation and repair — systems such as JudgeFlow, RobustFlow, WorfBench, and WorfEval study how to score, diagnose, and harden workflow variants instead of merely generating them.
  • Workflow memory — systems such as Agent Workflow Memory distill recurring routines from prior trajectories and recall them later.
  • Skill libraries — systems such as memento-skills, SkillFoundry, EvoSkills, SkillX, and Trace2Skill treat reusable skills as durable writable packages.
  • Compiled instructions — systems such as Compiled Memory rewrite the operative instruction structure itself rather than only retrieving more context.
  • Learnable control routines — systems such as AtomMem, MemSkill, and Meta Context Engineering turn previously static memory or context pipelines into learnable procedures.

These are related but not identical. A reflection buffer is not automatically a workflow language, and a skill library is not automatically a control plane, though papers are often tempted to claim both before breakfast.

Minimal closed loop

A real self-evolving workflow system needs more than mutation machinery. The smallest credible loop is:

  1. Generate or revise a candidate workflow artifact.
  2. Execute it against tasks or benchmarks.
  3. Capture structured evidence about success, failure, cost, robustness, and intervention burden.
  4. Assess the candidate against explicit metrics.
  5. Promote or reject it through a versioned selection policy.
  6. Route future executions through the winning variant while preserving rollback lineage.

Without steps 3 through 5, one has editable procedures, not a learning system.

Evaluation is part of the workflow, not a postscript

The newer papers make a useful correction to the early generation-centric story. Workflow evolution depends on an evaluator lane:

  • JudgeFlow adds block-level blame and refinement signals.
  • RobustFlow adds invariance pressure so semantically equivalent instructions do not produce different workflow spaghetti.
  • WorfBench, WorfEval, and SOPBench make workflow quality measurable with graph-aware or rule-based evaluators.

In other words, a workflow family that cannot be judged cannot really be improved; it can only be edited repeatedly with confidence inversely proportional to evidence.

Scaling pressure: retrieval over many learned procedures

Once a system can evolve many skills or procedures, the problem shifts from invention to retrieval. Graph of Skills is useful here because it treats the skill library as a dependency graph and retrieves bounded structural bundles instead of loading the whole cathedral into the prompt. This matters for any serious long-lived harness because success eventually creates a context problem.

Why this sits between memory and work management

Self-evolving workflows blur the line between memory-persistence and work-management-primitives. They are memory because they preserve distilled experience across runs. They are work-management objects because they directly shape future task decomposition, routing, and acceptance. This is why systems such as memento-skills feel like both a memory architecture and an orchestration architecture at once.

Main design constraints

  • Keep workflow state separate from transcript state, or recovery dissolves into folklore.
  • Make evaluation explicit, preferably with a judge or blind-verifier lane rather than pure self-congratulation.
  • Preserve lineage and rollback, because learned procedures are perfectly capable of becoming worse in novel and inventive ways.
  • Decide whether evolution acts on graphs, operators, skills, memory routines, or instruction kernels; otherwise the learning surface becomes vague and theatrical.
  • Treat context shaping as part of the evolution surface when the system compiles procedures into instructions, which is where context-engineering re-enters the room.
  • Plan for retrieval once the library grows; otherwise the reward for success is prompt collapse.

Relevance to the current Codex control-plane work

gas-city-but-its-just-codex has already crossed the threshold from static workflow templates to versioned formula families with mutation, assessment, and selection surfaces. Its present bottleneck is therefore not “can workflows be edited?” but “what evidence promotes an edit into the active family?” That is precisely the control-plane problem this concept names.

Read this with gas-city-but-its-just-codex, memento-skills, memory-persistence, work-management-primitives, and context-engineering. The comparative architectural implications also show up in harness-architecture-comparison.

Graph View

Backlinks