The short version
The labs building AI are already running this loop on themselves.
Anthropic says Claude wrote more than 80% of the code it merged as of May 2026, and expects human review to become the bottleneck. OpenAI, as reported by Help Net Security, says it reached its goal of an automated research intern in September 2026 and is aiming for an automated AI researcher by March 2028. Neither claims full recursive self-improvement: Anthropic writes “We are not there yet”, and OpenAI is reported as tying further progress to keeping human control.
Your company now has the same shape. Agents do the work and you are the bottleneck. What matters is whether your system improves from one cycle to the next.
Two changes make it better, both may feel wrong at first.
- Treat agents like employees. Each one gets a goal and KPIs instead of a queue of tasks.
- Gate what leaves the company, not the decisionmaking in the middle.
Sources: Anthropic, “When AI builds itself” and Help Net Security on OpenAI, 7 September 2026.
1. Agents are first-class workers, with goals and KPIs
Most teams treat an agent as a tool: hand it a task, judge the output, write the next task. That caps the company at the speed one person can write tasks.
You manage an employee differently. They own an outcome, a number says whether it is moving, and you review the number. Do the same for agents:
- An identity. Each agent has one ID that persists across tools and plans.
- A goal. Each agent owns one outcome with a target and a check, so you delegate once.
- A KPI and a cost. Every run is recorded against that goal with what it cost. An agent then has a result and a cost per result, the way a hire does.
- A review. After each cycle the goal gets one verdict from its readings: persist, pivot or stop. An agent that keeps missing gets changed or retired.
Give an agent only tasks and it optimises for finishing them, whereas a goal lets you judge whether the outcome actually moved.
Read your team’s direction from their agents
Nobody wants to micromanage people or invent status reports. If each person’s agents carry explicit goals, you do not have to.
The agents’ objectives already show what each person is driving at, what it costs and whether it is moving. Misalignment becomes visible without a meeting: two agents with conflicting goals, or a company goal that no agent owns.
Look at goals and results and leave the transcripts alone, because people will stop trusting the system if it is used to monitor them.
2. Gate the effect, not the decision
The usual safety design makes an agent ask before each decision. That produces agents that report back without doing any work: “I found three options, which would you like?” The person becomes the bottleneck, and every question costs them a context switch.
Split work by whether it can be undone instead.
| Kind of work | Examples | Rule |
|---|---|---|
| Reversible | Research, analysis, drafts, code on a branch, a prepared email, choosing between options | Do it now, decisions included |
| Irreversible or external | Sending the email, paying, signing, sharing, publishing, deleting | Hold at a gate |
Four rules follow:
- Frontload everything reversible. The agent makes the decision in its scope, records it with its reason and the option it rejected, and carries on. A recorded decision is cheap to overturn.
- The gate shows the finished thing. The person sees the exact recipients, the exact copy, the decision made and the alternative. They approve a finished packet instead of answering a question.
- Grants keep the gate from becoming the new bottleneck. Once a class of effect has proven safe, a person grants it once and it stops waiting.
- A run ends on a result or one exact ask. A run that ends on an open question has failed, unless only the owner could have answered it.
The cost is that an agent sometimes builds on a decision you would have made differently, but redoing that work costs less than waiting for an answer at every step.
The system underneath
Both claims depend on attribution. Every run carries a worker ID and belongs to a task, and every task belongs to a goal. People, agents and scheduled workflows all use that one task system.
That chain is why an agent’s KPI can be computed at all, and why a gate knows what it is approving and on whose behalf. Two loops run over the same record.
The inner loop does the work and sends up runs with a worker and a cost attached. The outer loop reads results by goal and worker, then changes the system itself: its goals, methods and agent definitions. That second loop is the recursive part.
Traps
- Bloat. A system that can improve itself adds a rule after every failure, until agents skim the context and miss the point. Add a rule only where code cannot enforce it, and prune.
- Self-grading. The agent that did the work reports that the work is good. Review has to come from a worker that neither produced nor watched it.
- KPI gaming. Agents will learn to move the number without moving the outcome. People own the goal and its check.
- Gates creeping inward. Every incident tempts you to add an approval in the middle of the work. Add a gate only where the effect cannot be undone.
- Agent sprawl. Keep an agent only while it owns a goal, and retire it once it does not.
What we have and have not proven
We use this design but have not yet measured its results. We build Cady on this architecture and run our own company on it, with people and agents in several tools working from one record.
So far the only evidence is our own small company. We have not yet shown:
- that the outer loop’s changes improve outcomes measurably over many cycles
- that attribution stays useful when several workers share one outcome
- that the design holds beyond a small team
If you run more agents than people and have tried something like this, we would like to compare notes, especially where it failed.