Enterprise RSI
AI systems that improve themselves — inside limits you set.
Recursive self-improvement is the most hyped idea in enterprise AI and the least safely implemented. The hard part was never getting a model to rewrite its own prompt. It is knowing whether the rewrite made anything better — and being able to prove it afterwards.
The problem
Deployment is not the end of the work.
Data changes. Models are updated or deprecated. Tasks evolve. Without ongoing evaluation, a capable agent can lose ground without your team noticing. A repeatable improvement loop helps turn observed failures into testable changes.
Measured against
- Time from identified failure to shipped fix
- Engineering hours per improvement cycle
- Quality drift between releases
- Regression escape rate
- Percentage of improvements promoted without human intervention
Categories of metric we deploy against — not reported results.
How the loop works
Propose, evaluate, gate, promote.
Five stages, and stage four is the one that matters. A self-improvement loop without a gate is just an unsupervised deploy pipeline.
- 01
Observe
Collect permitted production signals: failures, escalations, low-confidence outputs, and human corrections. Agree on access, retention, and use before collecting or reusing customer traces.
- 02
Propose
Generate candidate improvements grounded in those traces. Each candidate is a concrete, versioned diff against the current artifact, not a vague suggestion.
- 03
Evaluate
Run each candidate against the held-out benchmark and regression suite. Keep cases separate from proposal generation, and keep the verifier and scoring criteria outside the loop's control.
- 04
Gate
Require evidence of improvement, passing regression checks, and compliance with declared bounds. Apply your approval policy, with human review for consequential changes. Record every decision.
- 05
Promote or roll back
Release approved changes within the agreed scope and monitor the outcome. If recovery thresholds are crossed, follow the tested rollback plan. The next cycle starts from a reviewed baseline.
Promotion requires evidence of improvement on held-out cases, passing regression checks, and the required approvals. The proposer cannot change the verifier or its gates. Rejected candidates are recorded too.
What we build
Self-improvement you can put in front of a risk committee.
Systems that propose their own improvements
Within agreed data permissions, the loop reviews failed tasks, low-confidence answers, and escalations. It proposes concrete changes: a revised prompt, a better retrieval strategy, or a tool capability for your team to review.
Nothing promotes without beating the baseline
Every proposal runs against a held-out evaluation set and regression checks before it can ship. Promotion requires an improvement against agreed metrics, with no disqualifying regressions. The proposer cannot edit the verifier, criteria, or approval gates.
Explicit bounds, set by you
Maximum iterations per cycle. Which artifacts the loop may touch and which it may never touch. Blast radius. Change budget. A self-improving system without declared limits is not a product, it is an incident waiting to happen.
Human approval where it counts
Your team defines the approval policy. Only explicitly preapproved, low-risk changes are eligible for automatic promotion after passing every gate. Changes to tools, permissions, or customer-facing behaviour require a person's approval.
A complete audit trail
Every proposal, every evaluation result, every promotion and rejection is recorded append-only: what changed, why it was proposed, what it scored, who approved it. When your risk committee asks how the system got this way, the answer is a file, not a shrug.
Versioned recovery
Keep the previous approved configuration and test the rollback path before promotion. Define recovery triggers, owners, and handling for external side effects. Recovery time depends on the system and the change.
One connected approach
From deployed work to targeted learning.
FDEs build the production system. Enterprise RSI makes each proposed improvement reviewable and measurable.
When evaluation reveals a capability gap, a training program can add expert-created examples, agent trajectories, or RL tasks with verifiable rewards. Any resulting candidate returns to the evaluation and approval gates before promotion. A training run alone is never evidence of improvement.
Access, retention, and permitted uses of customer data are agreed for each engagement. Production traces are not automatically reused for training or shared across customers.
What we will not build
- We do not build systems that modify their own safety constraints, evaluation criteria, or approval gates. Those are set by you and are outside the loop's reach.
- We do not build autonomous research agents or anything that self-improves without a human-defined fitness function.
- Improvement is bounded by the quality of your evaluation set. A loop optimising against a weak benchmark will confidently get worse. Building that benchmark properly is most of the work.
- This is continual optimisation under constraint — not emergent capability, and not a step toward general intelligence. Anyone selling you that is selling something else.
A system that improves itself is only as safe as the benchmark it improves against.
Building that benchmark is where we start.