The Sphere of RSI

The Sphere of RSI is a scorecard for deciding which recursive self-improvement (RSI) loops a business should run, and what to fix first in the ones it should not run yet. An RSI loop has three parts that repeat: a lever, something you can change and then keep or undo, such as an agent’s instructions or a routing rule; a signal, the check that says whether a change helped; and an optimizer, the AI model or machine-learning method that proposes the next change, such as a language model rewriting instructions or a model retrained on fresh outcomes. Every change the check keeps becomes the starting point for the next round, so gains add up, and they compound when a kept gain also makes the next round faster, cheaper, better checked or wider in reach.

The sphere scores each loop on three axes, and folds what the loop costs into the same scores as how well it works:

• Verifiability (v): can you trust the check that says a change helped?
• Cadence (c): does the loop decide at the speed its signal allows, and deliver gains in time, given what each try costs?
• Consequence (q): do the gains move a number the business acts on by more than the loop costs to run, with any harm contained?

Each score runs from −1 to +1, where 0 is ideal and the sign says which way the loop misses, so the ideal loop sits at the center of a sphere. A loop’s distance from that center is its total miss: within 0.6 the loop is inside the sphere and worth running now, and outside it needs a fix first, starting with the axis whose score is farthest from 0.

Why it matters

Every enterprise has dozens of things it could put on a self-improving loop: the instructions a support agent follows, the rules that route tickets between agents, a pricing model, a fraud threshold. Each loop costs something to run, in model and compute spend, review time and the live traffic its tests use, and most will not pay that back, because the check can be fooled, the results arrive too late to act on, or the gains never reach a number anyone tracks. A few will compound with little human effort: Anthropic used a loop like this to raise a support agent’s decision accuracy on held-out tickets from 78.6% to 90.5%, at about a fifth of the cost per ticket (Anthropic, 2026).

The sphere gives product, engineering and finance one scorecard for telling the two apart before the money is spent. Every candidate is scored on the same three axes, mostly from data the company already keeps, which turns a mandate like “make it self-improving” into a ranked list: the loops to automate now, the ones to run with guardrails, the ones that need one fix first and the ones to leave alone. The scores also say why a loop falls short, in words a planning meeting can act on, such as “the check passes too many changes that don’t help” or “the gains don’t cover what the loop costs.”

The three axes

Figure 1 shows the three parts at work. The signal you pair with a lever decides how good the loop is: an agent’s skill description, scored on how often the agent uses the skill when it should, makes a good loop, because the score responds directly to the edit (Anthropic’s example), while the same description scored on end-user satisfaction makes a poor one, because satisfaction depends on too much else.

Each axis has an ideal in the middle and a way to miss at each end (Figure 2).

How every score is built. All three axes are scored in the same three steps:

1. Measure the two ways the loop can miss on that axis, each as a fraction from 0 (no miss) to 1 (as bad as it gets).
2. Take the larger of the two.
3. Give it a sign: + for too loose, too fast or too broad, and − for too strict, too slow or too small.

Because every score is a share of its own worst case, 0.2 on one axis is as big a miss as 0.2 on another, which is what lets a technical miss and a cost miss sit on one scale.

Where cost comes in. The business cares whether a loop costs more than it returns, and cost enters the scores in four places:

One example throughout. To make every calculation concrete, I’ll score one loop with round, illustrative numbers: an AI optimizer rewrites a customer-support agent’s instructions, and an A/B test on live tickets decides whether each change is kept. For a loop that is not running yet, estimate the same inputs from its plan or a short pilot.

Verifiability

Verifiability asks whether you can trust the check. A good check works like a good referee, letting real gains through and stopping fake ones.

Too loose (+). The check passes changes that did not help, so the loop keeps fake gains, as when answers please an automated grader but not customers.

Too strict (−). The check fails changes that would have helped, so the loop stalls, as when a grader fails every answer that departs from the old wording, including the better ones.

What you need. Two error rates, from an audit that re-tests a random sample of recent changes with something slower that you trust more, such as a longer test, a holdout group or an expert review:

• FPR, the false-pass rate: of the changes that did not really help, the share the check passed anyway.
• FNR, the false-fail rate: of the changes that really helped, the share the check failed. Failed changes were never kept, so the audit has to re-test them on purpose.

Example.

1. The team takes 20 recent changes at random, passed and failed alike, and re-tests each with a month-long holdout.
2. The holdout says 10 of them really helped and 10 did not.
3. Of the 10 that did not help, the A/B test had passed 3: FPR = 3 ÷ 10 = 0.3.
4. Of the 10 that helped, it had failed 1: FNR = 1 ÷ 10 = 0.1.
5. FPR is the larger, so v = +0.3: the check is somewhat too loose, letting 3 in 10 bad changes through.

Had the A/B test failed 4 of the 10 good changes instead, FNR = 0.4 would be the larger rate, and v = −0.4: too strict.

The cost side. A stronger check, like that month-long holdout, costs traffic and time, which is why teams audit only a sample of changes, and why a cheap check is usually a loose one. The cheapest audit of looseness is an A/A test, which puts changes that do nothing through the check: at the usual threshold, a sound check flags about one in twenty of them as real, and Microsoft found that an older method it used to combine metrics flagged 22% (Microsoft Research, 2026). An A/A test catches noise only, so it will not catch a grader being gamed, and it says nothing about FNR.

Real examples. Citi’s model for flagging unusual corporate payments is on the loose side: it retrains itself on new payment data and on every approve-or-reject reply from the client, and Citi’s published material describes no test a retrained model must pass before it is used (Citi, 2019; Citi Handlowy, 2021). Meta’s TestGen-LLM is on the strict side: a language model writes unit tests for Instagram and Facebook, and a test is kept only if it builds, passes five runs out of five and covers new code, yet Meta’s follow-on tool found that 49% of the tests that caught a planted bug added no coverage, so a coverage rule would have thrown them away (Meta, 2024; Meta, 2025).

Cadence

Cadence asks whether the loop decides at the speed its signal allows, and still delivers gains soon enough to matter, given what each try costs.

Too fast (+). The loop keeps or undoes changes before the signal can be trusted, so it acts on noise, as when the loop calls an A/B test on its first good day.

Too slow (−). The loop decides correctly but improves too late to matter, often because each try is so slow or so expensive that tries are rare.

What you need, with every time in days:

• T_settle: how long the signal needs before it can be trusted, such as the planned length of a properly sized A/B test or, for an offline test, the time to run enough cases that noise is smaller than the smallest gain worth acting on.
• T_decide: how long the loop actually waits before keeping or undoing a change.
• T_cycle: the time between tries, set by whichever is slower: how long a try takes, or how often the budget pays for one, which is 30 ÷ the tries it pays for each month.
• K: tries per kept gain, which is 1 ÷ the share of tries kept.
• T_need: the longest the business will wait for one kept gain, a choice you make up front.

Example.

1. The A/B test needs 10 days of traffic before its result can be trusted: T_settle = 10.
2. The loop calls each test after 3 days: T_decide = 3. Too fast: f = 1 − 3 ÷ 10 = 0.7, so the team skips 70% of the wait.
3. Each try takes those 3 days, and the budget pays for 10 tries a month, one every 3 days, so T_cycle = 3.
4. One try in 2 is kept (K = 2), so a kept gain arrives every 2 × 3 = 6 days, or 5 a month.
5. The business can wait 30 days for a gain: T_need = 30. Too slow: s = 1 − 30 ÷ 6, which is below 0, so s = 0.
6. f is the larger, so c = +0.7: too fast.

The fix is to wait the full 10 days. Then f = 0, each try takes 10 days, and a kept gain arrives every 2 × 10 = 20 days, within the 30 the business can wait, so s = 0 and c = 0, though the loop now makes 1.5 kept gains a month instead of 5, which Consequence will feel. Cost can also tip a loop toward too slow: if the budget paid for only one try a month, T_cycle would be 30 days, a kept gain would take 2 × 30 = 60 days, and s = 1 − 30 ÷ 60 = 0.5, so c = −0.5.

Real examples. Google’s Smart Bidding bids in every ad auction and learns as sales come in, but sales often take days to arrive, so Google says a new bid strategy takes one to two conversion cycles to settle and should then be judged over two more cycles or two weeks, whichever is longer; its “Learning” label disappears within seven days, and an advertiser who judges it then is too fast (Google Ads Help). Google Flu Trends was too slow: Google reviewed its model at the end of each flu season, and the one that significantly overpredicted US flu levels in 2012–13 had not been updated since 2009. Google retrained it for the next season, then launched a model that takes in the CDC’s data as the season goes on (Google, 2013; Google, 2014).

On the sphere below, Google’s compiler heuristics scored on runtime sit at the slow end: from a naive start, 100 tries took about a week of sequential evaluation without getting past the baseline (Magellan, 2026).

Consequence

Consequence asks whether the gains move a number the business acts on by more than the loop costs, and whether a bad change stays small enough to catch and undo.

Too small (−). The gains never add up to a move worth acting on, or worth what the loop costs, as when the optimizer speeds up a step that is a sliver of what customers wait for.

Too broad (+). A bad change reaches too many customers or too much money before its result is known, and much of the harm cannot be undone, as when a new refund policy goes to every customer at once.

What you need:

• G, the monthly gain: how much a month of kept changes moves the business number, the KPI. It is what one kept change moves the KPI, which is its gain on the work the lever touches × the share of the KPI that work drives, times the kept changes you get each month, which comes from Cadence.
• M, the bar: the larger of two monthly moves in the KPI: the decision bar, the smallest move that would change a decision, and the cost bar, what the loop costs each month in KPI terms, which is its monthly cost ÷ what one point of the KPI is worth.
• E: the share of customers, traffic or money a change reaches before its result is known.
• R: the share of a bad change’s harm you could undo. A bad setting that monitoring catches and rolls back on day 3 of a 30-day month undoes about 27 ÷ 30 = 0.9 of its harm, though any refund it approved in those 3 days stays paid.

Example.

1. Each kept change lifts the agent’s closure rate by 0.8 points on the tickets it handles, and the agent handles half of all tickets, so one kept change moves company-wide closure by 0.8 × 0.5 = 0.4 points.
2. Cadence gave 5 kept changes a month, so G = 0.4 × 5 = 2 points a month.
3. Leaders act on moves of 1 point a month, so the decision bar is 1. The loop costs about as much each month as 1.5 points of closure are worth, 1 point for its 10 tries and 0.5 for people and infrastructure, so the cost bar is 1.5, and M, the larger of the two, is 1.5. Too small: small = 1 − 2 ÷ 1.5, which is below 0, so 0.
4. Each A/B test runs on 10% of tickets (E = 0.1), and rolling back a bad change undoes about 90% of its harm (R = 0.9). Too broad: broad = 0.1 × (1 − 0.9) = 0.01.
5. broad is the larger, so q = +0.01: as good as ideal.

If the agent handled only a quarter of tickets, one kept change would move closure by 0.2 points and G would be 1 point a month, short of the 1.5 the loop costs, so small = 1 − 1 ÷ 1.5 ≈ 0.33 and q ≈ −0.33: too small to pay for itself.

Step 1 is where most loops lose their consequence, because a big gain on a small part of the work is a small gain on the whole. Google DeepMind’s AlphaEvolve sped up a kernel in Gemini’s architecture by 23%, which cut Gemini’s training time by 1% (Google DeepMind, 2025), so for that loop the move in the KPI is the 1%.

Real examples. Unity’s ad models were too broad: they learn from the data customers’ apps send back, and in 2022 they ingested bad data from one large customer, which, with a platform fault that cut one tool’s accuracy, hurt revenue growth for the first half of the year and led Unity to cut its forecast (Unity, 2022; Unity, 2023). Delta Air Lines staged its AI pricing tool, which recommends fares and learns from each pricing decision: by November 2024 it priced about 1% of Delta’s markets and revenue, by July 2025 about 3% of domestic, and leadership said it would widen without putting “too much revenue at risk at any individual time” (Delta, 2024; Delta, 2025; Delta, 2026).

Inside or outside?

The three scores combine into one distance from the ideal.

The example, scored. Scoring the support-agent loop takes three rounds, because each fix changes more than one score.

In round 1, d = √(0.3² + 0.7² + 0.01²) ≈ 0.76, so the loop is outside, and Cadence, the score farthest from 0, is the first fix. Waiting the full 10 days fixes Cadence but costs pace: with a kept gain every 20 days rather than every 6, a month of gains moves closure by 0.4 × 1.5 = 0.6 points, short of the 1.5-point bar, so small = 1 − 0.6 ÷ 1.5 = 0.6, q = −0.6, and the loop is still outside at d ≈ 0.67. Consequence is now farthest from 0, and the fix is cost: paying for only the 3 tries a month the slower loop can use cuts the cost bar to 0.5 + 0.3 = 0.8, so the decision bar of 1 becomes M, small = 1 − 0.6 ÷ 1 = 0.4, q = −0.4, and d = √(0.3² + 0.4²) = 0.5, inside. One score caught a technical fix turning into a cost problem, and named the next fix each time.

The cutoff 0.6 is my judgment; set yours by scoring loops you have already run and drawing the line between the ones that paid off and the ones that did not. Between 0.57 and 0.63 I call a loop on the edge. For a quick read without the arithmetic, any single score beyond ±0.63 puts a loop outside, all three within ±0.3 keep it inside, and any two scores at ±0.45 or beyond put it outside.

Where real loops land

The sphere below places fourteen enterprise loops, each improved by an AI or machine-learning method, beside the big-tech ones, and the seven inside mostly share three habits. Most have a check I would call hard to fool, such as Amazon’s Java-upgrade agent, which rebuilds each app and reruns its tests after each step before a developer accepts the result. Their outcome arrives fast, or a fast signal stands in for it only after being checked against it, as with Uber’s matching model, retrained weekly on the trips it shaped, whose effects Uber says often unfold hours later, and Duolingo’s reminders, judged by whether a lesson follows within two hours. And changes reach a slice first, as with Delta’s AI fares and DoorDash’s dispatch-weight policy.

Each of the five outside misses in the way its scores name: Citi’s payment model is too loose, Unity’s ad models were too broad, Google Flu Trends was too slow, and an advertiser who judges Smart Bidding in its first week would be too fast. DeepMind and Google’s AI for building chiller plants, tested with Trane, saved 9% and 13% of energy in two buildings, too small next to the engineering each new building needed. Stripe’s fraud models and Meta’s test writer sit on the edge: Stripe judges new models while fraud reports are still coming in, and Meta’s rules are strict while a typical kept test adds little.

Score your own loop

The explorer below opens with round 1 of the support-agent example. Open Score your loop and replace its inputs with your own: FPR and FNR as percentages; the Cadence days, tries per kept gain and the tries your budget pays for each month; and for Consequence, what one kept change moves the KPI, your decision bar, and the loop’s fixed monthly cost and cost per try, both in KPI points, with E and R as percentages. It works out the kept gains a month and the cost bar, prints each score and the verdict, and places your loop on the sphere. Besides the enterprise loops, the dots include loops from Google, Microsoft and Anthropic, plus my own loop from Part 1 of this series; click one to see why it sits there.

What to do with the scores

The distance sorts loops into four actions.

Fix the score farthest from 0 first, then re-score all three. Its axis and sign name the fix, and the re-score shows what the fix did to the other two:

• Verifiability: when too loose, use a stronger check that the optimizer cannot see or edit, such as a holdout; when too strict, recalibrate the grader on cases where the better answer differs from the old one.
• Cadence: when too fast, wait the full T_settle; when too slow, find a faster signal that predicts the slow one, make tries cheaper with a smaller model or cached evaluations, or fund more of them.
• Consequence: when too small, pick a lever that drives more of the KPI, or cut what the loop costs, as in round 3 above; when too broad, stage the rollout to lower E, as DoorDash did by letting its dispatch-weight policy learn on only 0.5% of regions at a time (DoorDash, 2026), and make changes reversible to raise R.

Rank the loops inside by business value. The scores say whether a loop is worth running, and the value of the KPI it moves says which to run first.

Prefer shared levers. A lever that many loops depend on, such as a shared tool, the routing between agents or the eval harness itself, lifts all of them with one win.

Re-score every month. Compounding shows up as a loop moving toward the center, as each gain makes the next round better checked, faster, cheaper or wider in reach. A loop drifting outward, as its easy wins run out, its costs creep up or its metric starts being gamed, gets an exit date.

Other criteria

Leaders will bring other criteria too, and most of them land on the sphere without a new axis.

The explorer’s Advanced panel lets you add a fourth axis and see a trade-off line.

Sources

• Self-Improvement in Production Isn’t One Flywheel (Part 1)
• Anthropic, Automating eval design and hillclimbing with Claude (2026)
• Microsoft: Treatment effect assessment at scale (2026)
• Google DeepMind, AlphaEvolve (2025)
• Magellan: compiler heuristics with AlphaEvolve (Google, Google DeepMind and Cornell, 2026)
• Enterprise loops: Citi (2019) · Citi Handlowy (2021) · Meta (2024) · Meta (2025) · Google Ads Help · Google (2013) · Google (2014) · Unity (2022) · Unity (2023) · Delta (2024) · Delta (2025) · Delta (2026) · DoorDash (2026)