What does recursive self-improvement mean for AI agents?
Recursive self-improvement for AI agents changes the system around the model, not the model's weights. This guide covers the loop, why the metric must stay out of the agent's hands, and how to build it in ConvOps.
The term started in AI research, where it names a system that improves the process that improves it. Labs use it for models that help train their successors, and safety researchers treat it as a threshold to watch. In business operations the same words now describe something narrower: agents that change how their own work is done, judged by numbers from real runs. For the one-sentence version, see the recursive self-improvement definition.
Two published scales help place any claim you read. Philipp Schmid separates self-improvement, where a system changes itself against a fixed evaluator, from recursive self-improvement proper, where the system also improves the evaluator it is judged by. Flowtivity grades autonomy in five levels; at its second, the agent chooses how to improve while the objective and the evaluation stay fixed.
ConvOps sits deliberately on the fixed-evaluator side of both scales. People define the metrics agents must report and set the targets; agents report against them and change workflows, instructions, model tiers and schedules. "Recursive" describes the work, not the ruler: the output of one pass is the input of the next, and the workflow that makes the changes is measured like any other, so the same loop can improve it.
| Kind | What changes | What judges it | Where you see it |
|---|---|---|---|
| Answer refinement | One output, retried inside a task | The task's own check | Draft, critique, redraft patterns |
| Self-improvement with a fixed evaluator | The workflow, instructions, model choice or schedule | Metrics and targets that people hold | ConvOps loops; Flowtivity level 2 |
| Recursive self-improvement proper | The system and the evaluator it is judged by | The system itself | Research agendas; not what ConvOps does |
| Model training | The weights | A training objective | Fine-tuning; not what ConvOps does |
sourcesPhilipp Schmid: Recursive Self-Improvement (21 Aug 2026)Flowtivity: What Is Recursive Self-Improvement? (13 Sep 2026)Anthropic Institute: When AI builds itself
How does the loop work, in six steps?
Every working loop, in any tool, makes the same six moves. The table maps each one to what ConvOps Metrics and the workflow engine ship today. None of it is on by default: every tool that edits configuration or reads metrics has to be granted to the run that uses it.
Then it repeats. The improvement workflow is a workflow like any other, so it can carry its own metrics (how many of its changes held, what each pass cost) and be edited by a later pass. That is the recursive part, and it stays inside the same bar.
| Step | What happens | In ConvOps today |
|---|---|---|
| 1. Trigger | Something starts an improvement pass | A schedule on the improvement workflow (daily, weekdays, weekly, monthly or a custom rule, in its own time zone), or a task someone opens |
| 2. Read | The pass reads the numbers since the last change | Metric values and trends for a step, broken down by option or a declared dimension, compared with the previous period, with the change markers on the same chart |
| 3. Decide | Compare the series with the target and pick one change | The target sits on the binding, where a person set it; the agent compares against it |
| 4. Hold (optional) | The proposed change waits for review | The proposal is filed as a report, and an approval gate on the apply step holds it until an explicit approval is given, recorded with the account that gave it |
| 5. Apply | Make the change | Edit a workflow step, an agent's instructions (saved as a new revision), a model tier or a schedule, each only if granted |
| 6. Mark and measure | Record when it changed, then measure the next runs | Each save of a workflow template leaves a marker on the trend of each metric bound to that workflow or one of its steps, and on the trend of each program whose schedules run it; agents in the next runs report against the same metrics, and ConvOps adds its own run numbers |
Why must the metric not belong to the agent?
Because a loop optimizes whatever it is measured by, the measurement included. The research record on self-improving agents is consistent here. In the Darwin Gödel Machine work, an agent removed the markers a hallucination check relied on and scored perfectly without fixing the problem. The AI Scientist, running past its time limit, tried to edit its own code to extend the limit instead of making its experiments faster. In "Who Grades the Grader?" (July 2026), evolved skills learned to satisfy a rubric by writing evidence tags with no values behind them, and an independent judge preferred the baseline in 88% of the pairs it decided.
Arize's glossary entry on self-improving agents gives the same warning in one line: an agent that optimizes against its own evaluation will end up satisfying the evaluation without getting better. The answer is not a cleverer agent. It is an evaluator the agent cannot reach: numbers it cannot define, targets it cannot move, and system metrics it cannot edit.
There is a quieter failure too. A loop tuned on one number drifts on the numbers nobody bound. The guard is a counter-metric: pair the number you want to improve with one that must not get worse, such as cost per run or time spent on a step, and put a target on both.
sourcesarXiv:2505.22954: Darwin Gödel MachineSakana AI: The Darwin Gödel MachinearXiv:2408.06292: The AI ScientistarXiv:2607.12790: Who Grades the Grader? (14 Jul 2026)Arize: What are self-improving agents
Who sets the bar, and how does ConvOps keep it there?
Three things stay with people: what a metric means, what the target is, and what a run may touch. The table shows how ConvOps holds each one, and where the protection ends. The limits matter as much as the controls, because they tell you what to keep out of the improver's hands.
| What | How ConvOps holds it | Where it ends |
|---|---|---|
| Who recorded a value, and where | ConvOps stamps the account, the run, the step, the project, the program and the schedule on every value. The agent cannot set them | The value itself is reported by the agent. Evidence is a link or a note for a reviewer; ConvOps does not fetch or check it |
| What a metric means | People define metrics. An agent can propose one, and a proposal stays a draft that takes no values until it is approved | A run granted the tool that manages metrics could approve a proposal. Keep that tool out of the improver's environment |
| The target | Targets live on bindings, not on the metric: at least, at most, between, a share or a yes rate, over a window | A run granted the binding tool could change a target or switch a binding off. Keep it with people |
| Numbers no agent can write | ConvOps records 17 numbers itself, such as run cost, duration, tokens, outcome and time on a step. An agent that tries to write one is refused | They judge the loop only where you bind targets to them |
| What a run may touch | Every tool that edits configuration or reads metrics is off for a run until its environment grants it | Granting is itself a tool. Never give the improver the tool that edits environments |
| The hold before a change | An approval gate holds the step until an explicit approval is given, recorded with the account that gave it | Any caller with access to the step, a run included, can give the approval. The record shows which account approved |
How do you build the loop in ConvOps?
The most important control is a split across two environments. The improver runs in one. The people who own the bar hold the other. With that split in place, the loop needs one workflow, one schedule and a short list of grants.
- 1
Define the metrics and bind the targets
From the person-held side, define the metrics agents must report and bind each one to the scope where the work happens (a workspace, project, workflow or step), with a target on each binding. Put at least one target on a number ConvOps measures itself, such as run cost or time on a step. Start a new binding in observe mode: the agent is not asked, and ConvOps records whether each step would have met it. Read a week of those flags, then switch it to enforce.
- 2
Make the metrics required where the work runs
Bind each metric as required on the step that produces it, in enforce mode. That step then holds until the value is recorded, so the series the loop reads has no silent gaps. Allow "not measurable" only where a run genuinely has no number to give.
- 3
Write the improvement workflow
Give it steps that read the series, compare it with the target, file the proposed change as a report, and apply it. Put an approval gate on the apply step if a change should wait for review.
- 4
Grant the improver only what it changes
In the improver's environment, grant reading metrics plus the edit tools for what it may change: workflow steps, agent instructions, model tiers or schedules. Leave out the tools that manage metrics, bindings and environments.
- 5
Schedule it, inside a program
Attach a schedule to the improvement workflow, for example weekly on Monday at 07:00 in your time zone, and put the schedule in a program so you can see whether the loop itself is healthy, late, silent or failing. Pick a quiet window, so an edit does not land while the workflow it changes is busy.
- 6
Read the markers before the next pass
Each change to a workflow template leaves a marker on the trend of each metric bound to that workflow or one of its steps, and on the trend of each program whose schedules run it. Compare the window after the marker with the previous period before the next pass acts on the same metric.
improver environment (the run that changes things)
reads: metrics_read, guidance_read, programs_read, schedules_read
changes: workflow_step_update, agents_manage, model_tiers_manage, schedule_update
never: metrics_manage, bindings_manage, agent_environments_manage
owners environment (held by people)
metrics_manage define and approve metrics
bindings_manage set targets, modes and conditions
agent_environments_manage decide what any run may touchWhat can a loop improve? Examples by kind of work
Every example below is built from shipped parts and keeps the bar with people. Each names the number it improves and the guard that stops it gaming that number.
| Example | Agents record | The loop changes | The guard |
|---|---|---|---|
| Customer support, enterprise help desk | Per ticket: resolved on first contact, reopened within 7 days, and a reason from an open list | The triage step's instructions for the reason with the worst reopen rate | Run cost and time on the step, measured by ConvOps; a marker on the trend for each change |
| Finance close, enterprise | Per account: the variance and whether it reconciled on the first pass | The reconciling agent's instructions, saved as a new revision | Task cycle time, measured by ConvOps; the previous agent revision can be made active again in one step if the first-pass rate drops |
| Compliance evidence, regulated enterprise | Control checks with evidence required, and a report per control | The step that keeps missing evidence; binding changes are proposed in a report and applied by the owners | ConvOps's own counts of reports filed and metrics recorded per step, which no agent can write |
| Document extraction, any team | Per document: fields extracted and fields left empty | The model behind a tier, or a different tier for one step | A target on fields left empty must hold, with run cost and duration, measured by ConvOps, as counter-metrics; if it does not hold, the next runs show it and a workflow can restore the previous tier |
| Schedule tuning, operations | Nothing extra | The fire time, cadence or executor of a schedule | The program verdict must stay healthy, and runs that hit their time limit are counted |
| Improving the improver | Per pass: changes applied, and whether each one was kept | The improvement workflow's own steps, such as how much data it needs before it proposes | Its own template saves leave markers too, and ConvOps measures what each pass costs |
What does ConvOps not do today?
Being exact about the gaps is part of running this safely. As of October 2026, ConvOps does not have the capabilities listed below. A change to a workflow in the workflow engine is reversed with another edit, guided by the marker on the trend.
- One-step rollback of a workflow change, and workflow versions. A workflow change is reversed with another edit. Agent instructions are different: every save is a revision, and an earlier one can be made active again.
- A before-and-after diff of a workflow edit. The marker records that a template changed, who changed it and its version number, not what changed.
- A comparison of a candidate change with the current workflow on the same inputs. A change is judged on the runs that follow it.
- Verification of reported values. ConvOps records who reported a value and where; the agent supplies the value and any evidence.
- Approvals reserved for people. An approval gate accepts an explicit approval from any caller with access, a run included, and records the account behind it.
- Model training. ConvOps sells no models and changes no weights; the loop changes the process, the instructions and the routing around the model.
How do others describe self-improving agents?
Several companies describe parts of this loop. The table summarizes what each says, from its own pages, so the evaluator and the human role can be compared side by side. The useful question for any of them is the same: what judges the change, and can the system that made the change reach it?
| Source | What improves | What judges it | Human role |
|---|---|---|---|
| Factory, Signals | Its own agent, from session signals | Model judges over sessions | A person approves the pull request before merge |
| Arize | Prompts, policies, tools and workflows, from evaluation results | Evaluation datasets | Review at the promotion step |
| Warp | Its software factory's model choices, context and skills, from rubric scores | A rubric scored by people, code or a model judge | Reviews and merges the change |
| SAP Signavio | Business processes, described as a direction | Process KPIs, benchmarks and human judgment | People approve changes |
| Letta | Agent memory and skills, from experience | Not stated; Letta publishes its own memory and skill benchmarks | No approval process described |
| ConvOps | Workflow steps, agent instructions, model tiers, schedules | Metrics people define, targets on bindings, numbers ConvOps records itself | People hold metrics, targets and grants; an approval gate is optional |
sourcesFactory: Signals, toward a self-improving agent (23 Jan 2026)Arize: What are self-improving agentsWarp: the self-improvement loopSAP Signavio: From process intelligence to process self-improvement (22 Jun 2026)Letta research
When should you not run a self-improvement loop?
A loop is a poor fit in three situations, and each has a better first move.
- There is nothing to measure yet. A loop needs a few weeks of values from the same workflow before a change can be told apart from noise. Record first, improve later.
- The outcome that matters cannot be recorded as a number or a yes or no. Improve the measurement before you automate the change.
- A wrong change is expensive and slow to notice. Let the agent propose and file the change as a report, and have a person apply it by hand.
Frequently asked questions
What is recursive self-improvement for AI agents?
Recursive self-improvement for AI agents is a loop that changes how agents work, run after run, judged by numbers from real runs. In ConvOps the loop is a workflow you build. It reads the metrics agents record against targets people set, its program's status and the team's memory, then proposes or applies one change to a workflow step, agent instructions, a model tier or a schedule, within the grants its run holds. The model weights stay the same.
Who needs a self-improvement loop for AI agents?
Teams that run the same agent workflow many times and answer for its results: operations, finance, compliance, support and content teams. In ConvOps the loop pays off once a workflow has a few weeks of recorded values and a target people set, such as the reopen rate on support tickets or first-pass reconciliation in a month-end close. A team with nothing to measure yet records first and adds the loop later.
How do you run recursive self-improvement for AI agents?
Run it as a scheduled workflow over metrics people control. In ConvOps people define the metrics agents must report and put a target on each binding. A weekly improvement workflow reads the trends, changes one workflow step, agent instruction, model tier or schedule within the grants its run holds, and the next runs show whether it worked. Each workflow change leaves a marker on the trends of the metrics bound to it.
How do you set up a safe self-improvement loop?
Split it across two environments. In ConvOps the improver's environment gets metric reads and only the edit tools it needs, while people keep metrics_manage, bindings_manage and agent_environments_manage in a second one, so definitions, targets and grants stay out of reach. Pair each target with a number ConvOps records itself, such as run cost, and add an approval gate to hold a change until an explicit approval is given, recorded with the account that gave it.
What do you need before you start a self-improvement loop?
A few weeks of numbers from the same workflow. In ConvOps that means defining the metrics agents must report, binding them as required on the steps that produce them, and letting runs record before any pass changes anything. Add a target on each binding, a counter-metric ConvOps measures itself, such as run cost, and a program for the improvement schedule, so you can see whether the loop itself is healthy.
Who decides whether a change counted as an improvement?
People do, in advance. In ConvOps people define each metric and set its target on a binding, and the agent only reports values against them. A change counts when the runs after its marker meet the target, or move toward it, where the runs before did not. Pair every target with a counter-metric, such as cost per run, so a gain on one number is not a loss on another.
How is this different from an agent that rewrites its own prompts?
Prompt rewriting changes one agent's text, often judged by an evaluation the same system runs. In ConvOps the loop changes the operating process (workflow steps, agent instructions saved as revisions, model tiers and schedules), and it is judged by metrics the agent cannot define, targets it cannot move and numbers ConvOps records itself. The process improves, not only the prompt.
Does the AI retrain its own model?
No. ConvOps sells no models and changes no weights. A self-improvement loop in ConvOps changes what surrounds the model: the steps of a workflow, the instructions an agent follows, which model a tier points to, and when work runs. Your model provider and your keys stay your own.
Can I undo a change an agent made?
Partly, today. In ConvOps an agent's instructions are saved as revisions, and an earlier revision can be made active again in one step; a tier or a schedule is set back with another edit. A workflow change has no one-step rollback: the marker on the trend of each bound metric shows when a template changed and who changed it, and you edit it back.