AI Business Harness · Built in · Recursive self-improvement
Recursive Self-Improvement: How the AI Business Harness Gets Better Every Week
The harness questions its own steps before it speeds them up. It proposes changes from its own logs. A person flips every switch.
Automating a bad process just makes it fail faster. Every workflow we install passes a five-step gate before it is automated, and a built-in improvement loop re-runs that gate on every live workflow, every week, from the harness's own logs. This page explains the gate, the loop, the list of things the loop may never touch, and what one recorded week of it produced.
Short answer: recursive self-improvement, in a business AI system, means the system reads the record of its own work, proposes a small change, tests the change next to the current version on real work, and asks a person to approve it. Repeat weekly. In the AI Business Harness this is built in, with four rules that make it safe:
- it proposes, never applies: a person approves every change, and some changes need the owner's explicit sign-off;
- every change is shadow-run first on real work, and promoted only if the measured number does not fall;
- every version is kept and any change rolls back with one command;
- there is a never-change list: permissions, prices, the compliance rules, who approves, and the number it is measured against are out of the loop's reach.
Why a harness needs this
Most automation projects fail the same way. A process that was never questioned gets automated as-is, so its bad steps run faster and more often. Then the world changes (a new lead source, a new staff member, a tool update) and the automation quietly drifts out of date, because nobody is paid to re-read it. Six months in, the owner has a system that is fast, confident and slightly wrong.
An AI model does not fix this. A model is the engine; the harness is the rest of the car: the connections, the skills, the memory, the guardrails and the triggers around it. The improvement loop is the part of the harness that keeps re-reading the design against what actually happened, so the system in month six is better than the system in month one, and the owner can see why.
The gate: five steps before anything is automated
Every workflow passes this gate before step 5, in this order. Skipping to step 5 is the most common mistake in business automation, and the gate exists to prevent it.
- Make the requirement less dumb. Every requirement names the person who asked for it and why. No name, no requirement. "We log it in the spreadsheet too" with no owner is deleted. "We send three follow-up texts" because "we always did" is re-asked with the current owner.
- Delete the step. Remove steps until something breaks. If you are not adding 10% of them back, you did not delete enough. A qualifying question whose answer never changed routing or booking in 240 runs is a candidate.
- Optimize. Only what survived. Simplify the script, the form, the hand-off.
- Accelerate. Shorten the cycle: fewer approvals in the chain, faster triggers, but only with evidence from the logs.
- Automate. Now, and only now, the harness runs it, with the approval map and logging in place.
The loop: eight steps, every week
| Step | What happens | Who |
|---|---|---|
| 1. Observe | Read the logs: every approval, edit, rejection, escalation, timeout and duplicate catch, per step, per run, plus the outcome of each run. | The loop |
| 2. Diagnose | Find the friction. Always approved untouched: candidate to run without approval. Often edited: the skill text is wrong. Often rejected: the requirement is wrong, go back to step 1. Timeouts: a recovery rule is missing. Escalations with one recurring reason: a rule is missing. | The loop |
| 3. Propose | Write the change as a versioned diff: delete a step, rewrite a skill, add a rule, tighten or loosen one approval. With the evidence and the expected effect. A model drafts rewritten wording; everything else is deterministic. | The loop |
| 4. Human gate | The owner (or we, on the owner's behalf) approves or declines. Wording changes: one approval. Loosening an approval: 20 clean runs plus explicit sign-off. Permissions: never. | A person |
| 5. Test | Shadow run: the new version runs beside the old on a slice of real work. Only the old version's output goes out. Results are compared before anything switches. | The loop |
| 6. Promote or roll back | One switch. The old version is kept. Any drop in the measured number flips it back. A simulated shadow run is never promoted. | The loop, after the person's approval |
| 7. Measure | Against baseline, with the same metrics as the owner's report: edit rate, escalations, time to done, outcome. Dated. | The loop |
| 8. Re-run the gate | Weekly, every live workflow is asked again: is this requirement still needed? Can this step go? | The loop, then the owner |
The loop improves the skills, the approval map and the gate's own checklist. It never improves its own permissions.
What the loop may never change
- Permissions and connection scopes.
- The never-list: offers, pricing, legal, clinical, fair housing and consent rules.
- Prices and offer terms.
- The human gate itself, or who sits at it.
- The measured number it is judged against, so it cannot pick an easier target.
- Anything customer-facing without a shadow run first.
- More than three changes per workflow per week, so the owner can keep up and nothing drifts in a burst.
These are not policies; they are tests. The loop ships with a self-check that tries each of these refusals (thirteen cases in v1.1) and fails loudly if any one is allowed.
What one recorded week produced
We built the loop as working software and ran it on a sample brokerage speed-to-lead workflow: 12 steps, 240 logged runs over four weeks. The logs are sample data with the friction patterns brokerages actually see; the numbers below are from the recorded run, not a client.
| The loop found | It proposed | Shadow run (60 leads) | Result |
|---|---|---|---|
| Agents edited the AI's follow-up email in 75% of runs. Reasons logged: too long, market commentary, wrong tone. | Rewrite the skill: four lines, no commentary, one question the lead answered, the agent's name. | Showings booked unchanged; email edit rate in the 60-lead shadow test 70% → 20% | Promoted (v2) |
| Routing escalated in 6% of runs, every one a Spanish-speaking lead with no bilingual agent on call. | Add a rule: book a callback with the bilingual agent instead of escalating. | Showings booked per lead in the shadow test 36.7% → 40%; escalations for that case 100% → 0% | Promoted (v3) |
| The spreadsheet write timed out in 20% of runs and the harness assumed success. | Add a recovery rule: retry once, then queue and mark uncertain; never assume. | Showings booked unchanged; unreconciled timeouts in the shadow test 22% → 0% | Promoted (v4) |
| The "home to sell?" question never changed routing or booking in 240 runs. | Delete the step. | — | Deferred: weekly budget spent |
| The Monday report was approved untouched 240 times in a row. | Stop requiring approval on it. | — | Deferred: needs owner sign-off |
Then we rolled v4 back with one command (to prove it works), re-ran the guardrail self-check (every refusal passed) and the test suite (every test passed). The loop's state after the week: four versions kept, three changes applied, a written record of why each one was made.
Who does the work: a main agent and five subagents
The definition we use: recursive self-improvement is an agent's ability to build the next version of itself. In this system the agents draft, test and package proposed workflow updates for human review. A person decides whether it goes live. A Verifier checks afterwards whether it did what it claimed, and nothing is reported as fixed until it is verified.
| Agent | Does | Produces |
|---|---|---|
| Main agent | Runs the weekly cycle in order; stores every finding; renders the owner's page. Cannot approve. Cannot promote anything that was not shadow-run for real. | cycles/<week>.json and .md |
| Observer | Per-step statistics from the logs; gate steps 1–2 on the written requirements. | stats, gate findings |
| Diagnoser | Pre-checked, ranked proposals with evidence and expected effect. Judges a changed step only on logs after the change. | proposals |
| Builder | For each approved proposal, the candidate next version: workflow, skills, a regression test generated from the never-change list, a build note marked NOT TESTED. | candidates/<id>/ |
| Tester | Runs the candidate's test; checks never-change drift; shadow-runs old vs new on real inputs; passes, holds or rejects. | test record, verdict |
| Verifier | After promotion: before vs after on the metric the change claimed to fix, 20 runs minimum; verified, unverified or regressed (with a rollback recommendation). | verification on the proposal |
Independently reviewed
Before v1.1, a separate reviewing agent with no part in writing the code audited the loop and returned ten findings, each with a reproduction. Two were serious: the gate judged a change by what it was called rather than by what it did, so an approval could be loosened inside another kind of change; and the weekly budget check was not atomic, so two promotions at once could beat it. Both are fixed and verified the only way we accept: the reviewer's reproduction now fails, and a regression test that failed on the old code passes on the new one. The full list, with what was fixed, what was accepted as a limitation and what was only a hypothesis, is in the downloadable system document.
What this looks like for the owner
One page, every Monday. It shows the measured number for the workflow, the gate findings on the written requirements, a table of every step with its edit, rejection, escalation and timeout rates, and the proposals: what the loop found, what it wants to change, the evidence, and the shadow result if there is one. The owner reads it in five minutes and approves or declines. Approvals take one tap and are logged. If the owner does nothing, nothing changes.
What it is not: an AI rewriting itself unsupervised. Nothing in the loop sends, posts, publishes or changes a live workflow on its own. The model's only job is to draft replacement wording when a skill is being edited too often; the draft then goes through the same pre-checks, human gate and shadow run as every other change.
How it is delivered
The gate runs on every AI Business Harness installation: no workflow is automated until its requirements have an owner and a reason and the steps that do nothing are gone. The weekly loop is part of the AI Operations Partner plan (from $5,000 a month on a 90-day starting term): we run it, bring the owner the Monday page, and handle the shadow runs and switches. Clients who end the Partner plan keep the playbook, the versions and the logs. The loop also runs on our own sales engine: the scorecard questions and the outreach lines go through the same gate.
Next step: book a 20-minute Fit Call. Bring one thing your team does over and over. We will tell you whether it passes the gate, and what the first week of the loop would look for.
Frequently asked questions
What is recursive self-improvement in a business AI system?
A loop in which the system reads the log of its own work, proposes a small change, tests the change beside the current version on real work, and asks a person to approve it before it goes live. Repeated weekly, it keeps the automation matched to how the business actually runs. In the AI Business Harness, the loop can change skills, rules and the approval map; it cannot change permissions, prices, compliance rules, who approves, or its own target.
Does the AI change things on its own?
No. The loop proposes; a person approves every change. Wording changes need one approval. Removing an approval step needs 20 clean runs and the owner's explicit sign-off. Permissions are never changed by the loop. A simulated test run is never promoted; only a shadow run on real work can be.
What is a shadow run?
The new version of the workflow processes the same real inputs as the current version, but only the current version's output is sent. The two are compared on the measured number (bookings, answered calls, whatever the workflow is for) and on the side metric the change was meant to improve. If the measured number drops, the change is rolled back automatically.
What if a change makes things worse after it is live?
Every version is kept. One command restores the previous version as a new version, so the history stays in order and the record shows what was rolled back and why. The change budget (three per workflow per week) keeps any bad week small.
Which AI model does it use?
Any. The loop has one place where a model is used, drafting replacement wording for a skill that people keep editing, and it is model-neutral by design: the business can use whichever model its platforms support, and swap it later. Everything else in the loop is deterministic rules, so the same logs produce the same proposals.
Where does the five-step gate come from?
It is adapted from a well-known five-step engineering process: make the requirements less dumb, delete the part or process, simplify and optimize, accelerate cycle time, automate. The order matters: automating before deleting is the most common mistake, in factories and in offices.
Is the recorded week a client result?
No. It is a test run of the loop on a sample brokerage workflow with sample logs built to show the friction patterns brokerages actually see. We publish it so you can see what the loop does and refuses, not as a promise of results. Client numbers are measured against each client's own baseline and reported with the source and date range.
Who actually builds the next version?
Five subagents under one main agent. The Observer reads the logs, the Diagnoser writes proposals, the Builder builds the candidate version with its own regression test, the Tester runs that test and the shadow run, and the Verifier checks the live result afterwards. A person approves each proposal; the agents never approve, and the main agent never promotes a result that was not shadow-run for real.
Related
- Download: the RSI system document (PDF): architecture, examples, use cases, the review findings and the recorded run.
- The concept: what an AI business harness is.
- The product for brokerages: Broker Harness, and the 60-agent Phoenix example.
- Guides: how human approval works in AI workflows, what to log when an AI agent does business work and AI workflow approval controls.
Results vary by business; nothing on this page is a guarantee. The test run figures come from sample data and are reproducible from the loop's own test suite.