Improvements

LagrangeCloud reads an agent's runs and traces for ways to do the same work for less money or in less time. Each one it finds is saved as a candidate: a preview version of the agent with the change, an estimate of what it saves, and the evidence from the runs. Nothing reaches your callers until you promote it, and you can measure a candidate on real inputs and real traffic first.

Candidates are listed under Improvements in the console, and on each agent's Overview tab.

#What it looks for

A candidate only changes the agent's configuration (instructions, skills, MCP servers, model), never the harness.

LagrangeCloud looks every hour, once per live version, after the agent has had a few more finished runs. To look now, click Propose improvement on the agent's page. Set improvement: { mode: off } in lgr.yaml to stop it from looking on its own.

#Replays

Before any caller sees a candidate, Replay recent inputs runs up to 5 recent inputs of the live version again on the candidate, in fresh sandboxes. A model compares each result with the original and judges it better, the same or worse, and the candidate shows cost and time next to the originals. Replays are paid for by LagrangeCloud.

Replays only start when you click the button, because they run for real: an agent that changes things elsewhere, such as posting a message or merging a pull request, does so again.

A workflow candidate can't be promoted until a replay has no result judged worse and costs less in total than the originals.

#Canary and promotion

• Start canary sends a share of runs (5% to 50%) to the candidate, so both versions are measured on the same live traffic. The candidate shows success rate, cost per run, median time and failed tool calls per run for each version.
• Promote to 100% makes the candidate the live version.
• Reject drops it, with an optional reason.
• Roll back on a promoted candidate makes the version it replaced live again.

Canaries guard themselves. While a candidate serves runs, in a canary or in its first 50 runs after promotion, it is compared with the version it was built from once it has 10 finished runs. If its success rate is more than 10 points lower, or its cost per run more than 10% higher, the canary is stopped or the promotion rolled back, with the reason on the candidate.

From the CLI:

lgr improvements                    # candidates and their state
lgr improvements imp_8f2c           # one candidate, with its change and numbers
lgr promote imp_8f2c --traffic 0.1  # canary on 10% of runs
lgr promote imp_8f2c                # make it live
lgr reject imp_8f2c --reason "Answers got shorter"
lgr rollback imp_8f2c

Only runs that name the agent without a version take part in a canary. Runs that name a version, such as support-bot@v3, always get that version.

#Coming next

These aren't available yet. They are what we are building next.

#Lagrange learns from your runs

Today an improvement changes the agent's configuration, and the harness stays the same. Lagrange, our own harness, will also learn from each agent's traces: how it plans, what it keeps in context, which tools it reaches for first, and when it checks its work. It will tune how it runs that agent, and those changes will go through the same candidates, replays and canaries, so you still see the numbers and decide.

#Workflows, optimized step by step

An agent will be able to run as a workflow of steps in one sandbox, such as fetch, review and report. Each step will have its own instructions and model, and share the working directory with the others. Improvements will then work per step:

• run a simple step on a cheaper model while the hard step keeps the strong one,
• propose splitting an agent that does several jobs into steps,
• replay a single step on recent inputs to measure a change to it alone.