glossary · The whole system

Recursive self-improvement

definition

Recursive self-improvement is a loop where agents edit their own workflows, record metrics against targets people set, and read the results to decide the next edit. In ConvOps, people define the metrics and targets, and agents edit workflows and record against them.

in one line: Agents change how the work is done; numbers people defined say whether it helped.

in context

Where does recursive self-improvement fit?

The agent changes the work. People hold the ruler. Each pass reads recorded numbers, makes one change, and the next runs show whether it held.

read the numberssince the last change
compare with targetset on the binding
hold the changeoptional hold
apply one editonly what is granted
marker on the trendnext runs measure it
next pass
One pass of the loop. The target was set by a person before it started.
two ways to say it

What is recursive self-improvement, in plain words?

Same idea at two depths: the plain version, then what the engine actually does.

A team keeps a few numbers about how its agents work. Once a week, an agent reads them and changes one thing: a step, an instruction, which model a job uses.

The next runs show whether the change helped. The agent never decides what counts as better; people did that first.

for engineers

Agents record values with every run; ConvOps stamps who recorded each one and at which step. Some numbers, such as run cost and duration, ConvOps records itself.

Targets live on bindings. A run edits only what its environment grants, and each workflow template change leaves a marker on the trends of the metrics bound to it.

the longer answer

Why does recursive self-improvement matter?

The phrase comes from AI research, where it names a system that improves the process that improves it. Labs use it for models that help build their successors. In operations it means something smaller and more useful: the system around the model changes, run after run, while the model's weights stay as they are.

Three parts make a loop recursive rather than a one-off fix. Something records numbers from real runs. Something reads them and changes how the work is done: a step, an instruction, a model choice, a schedule. And the next runs are measured against the same numbers, so each change becomes the input to the next decision. When the workflow that makes the changes is measured the same way, it can be improved by the same loop.

The hard part is the ruler. A loop that may redefine its own metric or move its own target learns to pass, not to get better, and the research on self-improving agents records exactly that. A loop that works keeps three things with people: what each metric means, what the target is, and what the loop is allowed to change.

in convops

How does recursive self-improvement work in ConvOps?

In ConvOps, agents record the numbers as they run, and the server stamps who recorded each value and at which step. People define the metrics and put the targets on bindings, and some numbers, such as run cost and duration, are measured by ConvOps itself where no agent can write them. An improvement workflow can read the series and edit workflow steps, agent instructions, model tiers or schedules, and every 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. None of it is on by default: a run edits only what its environment grants. See ConvOps Metrics and the full guide.

in depth

The loop, step by step

Each pass of the loop is an ordinary workflow run. It starts on a schedule, works from recorded numbers, and leaves a mark that the next pass reads.

One pass of a self-improvement loop in ConvOps
StepWhat happens
TriggerA schedule starts the improvement workflow, for example every Monday morning in your time zone
ReadThe run reads the metric values and trends since the last change
DecideIt compares them with the target a person set on the binding and picks one change
HoldOptional: an approval gate holds the change until an explicit approval is given, recorded with the account that gave it
ApplyIt edits a workflow step, an agent's instructions, a model tier or a schedule, only where its environment grants that
Mark and measureThe change leaves a marker on the trend, and the next runs record against the same metrics
in depth

What stays with people

The loop is only as honest as its ruler. These are the parts a person keeps, and the reason each one matters.

Who holds the bar in ConvOps
PartWho holds itWhy
What a metric meansPeople define metrics; an agent can propose one, and it stays a draft until whoever holds metrics_manage approves itA metric the agent can redefine stops measuring the work
The targetPeople, on the binding, never on the metricA target the agent can move is always met
Numbers about the run itselfConvOps records cost, duration, tokens and outcome; agents cannot write themThey give the loop a floor it cannot talk its way past
What a run may changePeople, through the grants on the run's environmentWithout a grant, a run changes no configuration: it works its task, records metrics and files reports
questions

What do people ask about recursive self-improvement?

What is recursive self-improvement in AI agents?

Recursive self-improvement, as ConvOps supports it, is a loop where agents edit their own workflows, record metrics against targets people set, and read the results to decide the next edit. The edits are to workflow steps, agent instructions, model tiers and schedules, and each workflow change leaves a marker on the trends of the metrics bound to it. The model weights do not change; the system around the model does.

Can AI agents improve their own workflows safely?

Yes, when people set the targets and the agent cannot change them. In ConvOps a run edits only what its environment grants, a metric an agent proposes stays a draft until it is approved, and targets live on bindings, whose tools a run gets only if you grant them. A required metric holds its step until the value is recorded, and an approval gate can hold each change until an explicit approval is given, recorded with the account that gave it.

Who uses recursive self-improvement in ConvOps?

Operations, finance, compliance and support leads who own a recurring agent workflow and answer for its numbers. In ConvOps they define the metrics agents must report, set the targets on bindings and decide which tools the improvement run gets, and the loop changes the workflow between runs. It suits work that repeats weekly or more often, such as ticket triage or a nightly reconciliation, where a few weeks of values show whether a change helped.

Is there an AI that can continuously improve itself?

Not by rewriting its own model in production. What teams run today, and what ConvOps supports for agent workflows, is an AI that keeps improving how it works, judged by numbers a person defined: a scheduled run reads the metrics, changes a step, an instruction, a model tier or a schedule, and the next runs show whether it helped, within the grants you give each run.

What can an agent change in a self-improvement loop?

Only what the run's environment grants. In ConvOps an improvement run can edit workflow steps, agent instructions, model tiers or schedules when its environment includes those tools; without a grant it changes no configuration: it works its task, records metrics and files reports. None of it is on by default. Keep the metric and binding tools away from the improvement run, so the bar it is judged by stays with people.

Which numbers can an agent not write?

The numbers about the run itself. ConvOps measures run cost, duration, tokens and outcome on its own, and agents cannot write those system metrics, so the loop has a floor it cannot talk its way past. Values an agent records carry who recorded them and at which step, stamped by the server, but the value itself is reported by the agent, so pair each target with a system metric where one exists.

How often should a self-improvement loop run?

Often enough to have new numbers, and no faster. In ConvOps a schedule starts the improvement workflow, for example every Monday morning in your time zone, and each pass reads the values recorded since the last change. A loop needs a few weeks of values from the same workflow before a change can be told apart from noise, so record first and let each change follow the evidence.