What is self-improving AI?

Self-improving AI is a system that gets better on its own, without a person rewriting it each cycle. In AI research the phrase usually means recursive self-improvement: a model that improves its own successor, which is why people call it the holy grail of AI. For founders there is a nearer, practical version: wiring parts of a company as AI loops that sense what is happening, act, check their own work, and use the outcome to adjust the next run. The mechanism is the same shape either way, a feedback loop with a learning step. The learning step is what makes it self-improving rather than merely automated.

How is a self-improving company different from just using AI tools?

Using AI tools bolts intelligence onto an existing process: the same steps run, a human still drives, and nothing gets better unless someone changes it. A self-improving company treats a process as a closed loop instead, built from a sensor layer that gathers signal, a policy that decides, tools that act, a quality gate that checks, and a learning step that updates the policy from real outcomes. The difference is the loop closes on itself. It compares what happened against what should have happened and adjusts, so the process improves cycle over cycle without waiting for a person to notice and rewrite it.

Does self-improving AI mean replacing employees?

Not replacing so much as changing the shape of the team. The argument from Y Combinator is that a lot of a company's people go to coordination, routing information and aligning teams, and that AI loops can absorb much of that coordination work. The result is less middle management and a team weighted toward builders and operators who both decide what to do and do it. Growth then comes more from spending on AI usage than from adding headcount, which shows up as higher revenue per employee. Humans stay essential for high-stakes, ethical, and emotional judgment that a loop should not make alone.

How do I start building a self-improving AI loop?

Start with one narrow, high-signal process rather than the whole company. Pick something with a clear input stream and a measurable outcome, like triaging support tickets or catching failures in a sales funnel. Make it legible first: record the inputs, decisions, and results as data an agent can read, because a loop cannot learn from work that was never captured. Then build the five parts (sensor, policy, tool, quality gate, learning) and keep a human on the quality gate until the loop earns trust. Prove one loop works and compounds before you wire up the next.

Self-Improving AI: A Founder's Guide

Self-improving AI is the idea that a system can get better on its own, without a human rewriting it each time. In AI research the phrase usually points at recursive self-improvement: a model that improves its own successor, the AI that makes the AI smarter. People in the field call that the holy grail, and for good reason. It is also still mostly a lab conversation.

There is a nearer version founders can build this quarter. Instead of a model that rewrites its own weights, you wire parts of your company as AI loops that watch what happens, act, check their own work, and adjust, so the business gets a little better every cycle without anyone filing a ticket. Y Combinator group partner Tom Blomfield, who co-founded the payments company GoCardless and the bank Monzo, laid out this blueprint in a batch talk on building a self-improving company. This piece turns it into a practical guide: what self-improving AI actually means, how one loop is built, how it reshapes the org chart, and where to start without losing control.

What self-improving AI actually means

Two things wear the same name, so separate them first.

The research sense is recursive self-improvement: a model that makes a better model, which makes a better one still. That is the version people mean when they call self-improving AI the holy grail, and it is the frontier labs' problem, not yours this week.

The practical sense is the one you can operate. Take any repeated process in your company and build it as a loop that senses, decides, acts, checks, and then learns from what happened. The shape is identical to the research version, a feedback loop with a learning step, just pointed at your business instead of at model weights.

The learning step is the whole point, and it is what separates a self-improving loop from ordinary automation. Automation runs the same step forever: it is faster than a human, but it never gets smarter, and it fails the same way every time until someone rewrites it. A self-improving loop closes the feedback: it compares what happened against what should have happened, and updates its own rules so the next run is better. Take the learning step away and you just have a bot.

The self-improving loop, part by part

Blomfield breaks a single loop into five parts. It is worth building the picture concretely, because the instruction to make your company a loop is useless until you can see the pieces.

Sensor layer. The inputs from the real world that tell the loop something is happening: customer emails, support tickets, cancellations, product telemetry, code changes. This is the loop's eyes. If a signal never reaches the sensor, the loop is blind to it.
Policy layer. The decision rules. Given what the sensors saw, what should happen? Early on this is simple logic and a prompt. Over time it is the part that learns.
Tool layer. The deterministic actions the loop can take: call an API, update a record, open a ticket, send a reply, ship a change. Tools are where decisions become effects in the world.
Quality gate. The check before anything real ships. Did the action meet the bar? This is the safety valve, and it is the piece founders are tempted to skip and should not.
Learning step. The outcome feeds back and updates the policy, and the loop runs again. This is the difference between a process that stays flat and one that climbs.

Make it concrete. Picture a monitoring loop over customer support: the sensor reads the questions coming in and the tickets that got escalated, the policy decides which ones point to a real gap, the tools update a help doc or a canned answer or file a bug, the quality gate confirms the change is sound, and the learning step notices which fixes actually reduced repeat questions and leans harder on those next time. Run that daily and the support experience improves on its own, on the days you are not looking at it.

The reason this is possible now, and was not a few years ago, is that the policy and quality steps can finally be handled by a capable model instead of a brittle rule tree. That same capability is what makes an agent worth building a company on top of AI around, rather than treating AI as a feature you sprinkle on.

Why the org chart changes shape

Blomfield's sharper claim is not about any single loop. It is about what a company looks like once loops do the routine coordination.

A traditional company spends a large share of its people on coordination: managers routing information, aligning teams, chasing status, deciding who does what. If loops absorb much of that coordination, the argument goes, you need far less middle management, and the people you keep skew toward builders and operators who both decide what to do and do it, rather than committees that mostly decide. It is a provocative framing, and you do not have to accept the strongest version to take the direction seriously.

The metric that follows is revenue per employee. When growth comes from spending more on AI usage rather than from adding headcount, the same small team drives more output, and output per person climbs. That is the same shift other YC founders describe as spending on tokens instead of hires, and it is the scoreboard behind a lot of the AI-native company talk. If you want the metric on its own terms, we wrote about revenue per employee as the number to actually watch. The self-improving loop is one of the concrete mechanisms that moves it.

A fair caution: this reshaping is easy to say and hard to live. Coordination is not only overhead, and some of what middle managers do is judgment that a loop should not own. The point is not to fire your managers this week. It is that the parts of coordination that are really just moving information around are exactly the parts a loop can take, and that frees your people for the parts that need a human.

Make the company legible to the AI

Here is the prerequisite that quietly decides whether any of this works. A loop can only learn from what it can read. If a decision, a customer interaction, or the reasoning behind a fix never got recorded, it did not happen as far as your AI is concerned. Blomfield's blunt version of the rule is that everything has to be recorded to be legible to the AI, because unrecorded work is invisible to it.

For most companies that is the real project. The know-how that runs the business lives in people's heads, in Slack threads, and in habits nobody wrote down. Making it legible means capturing the inputs, the decisions, and the outcomes as structured data an agent can use. This is the same groundwork behind AI knowledge management, the move from a wiki humans skim to a company brain agents act on. Without it, your loops are learning from a fraction of what your company actually knows.

One pattern worth stealing from the talk: instead of hand-maintaining documents that rot, regenerate them from the recorded source. Rebuild the internal manual from recorded decisions and office hours so it updates itself as the company changes, rather than going stale the moment someone changes a policy and forgets to edit the doc. The durable value of the company is the business context and judgment. The specific software and dashboards around it become cheap and regenerable, something a team can spin up on demand and throw away.

Where to start without losing control

I write this as a CISSP, so the governance instinct is not an afterthought here. A self-improving loop that can act in the world without a gate is a self-improving liability. The quality gate is not the boring part of the design. It is the part that lets you sleep.

A sane way to start:

Pick one loop, not the company. Choose a single process with a clear input stream and a measurable outcome. Support triage, funnel-drop detection, and internal-tool generation are common first loops because the signal and the result are both obvious.
Keep a human on the gate until it earns trust. Let the loop propose and act on low-stakes changes automatically, but route anything irreversible or high-stakes through a person. Widen the loop's autonomy as it proves itself, do not grant it up front.
Scope what each loop can touch. Least privilege applies to agents exactly as it does to employees. A support loop does not need production database write access. Decide what each loop may read and do, and log every action so you can audit what happened and why.
Keep humans on judgment. High-stakes, ethical, and emotional calls stay with people. A loop is for the repetitive, legible work, not for the decisions that need a human to own the consequences.

Get one loop compounding and you will feel the difference from ordinary automation: a process that is measurably better this month than last, without a project to make it so. That is the whole promise of self-improving AI, brought down from the frontier to something a founder can run.

What to do this week

Name one process that repeats often, has a clear input stream, and a measurable outcome. That is your first loop candidate.
Check whether its inputs, decisions, and results are actually recorded. If they are not, fixing that legibility gap is step one, because a loop cannot learn from what was never captured.
Sketch the five parts for that one process: what the sensor reads, what the policy decides, what tools it may call, what the quality gate checks, and how outcomes feed back.
Put a human on the quality gate and scope the loop's access to the minimum it needs. Let it act automatically only on low-stakes, reversible steps.
Run it for two weeks and measure whether the outcome improves on its own. If it does, you have a template. Wire up the next loop.

Building a company as a set of self-improving loops is a different operating model, not just a new tool, and getting it right without losing control of cost, quality, or your data is the hard part. That whole operating picture, how to run a company on AI and still ship reliably, is what we teach in the AI Operating System for Startups.

Sources

How to Build a Self-Improving Company with AI (Y Combinator), the batch talk by group partner Tom Blomfield that this article distills, on AI loops, the five-part loop anatomy, company legibility, and the org-chart argument.
Background on the speaker: Tom Blomfield of GoCardless and Monzo is our newest Group Partner (Y Combinator) and Tom Blomfield (Wikipedia), for his roles co-founding GoCardless and Monzo and joining YC as a group partner.
Cross-source context from our video knowledge base: How To Build A Company With AI From The Ground Up (Y Combinator) on spending on AI usage rather than headcount, and This Is The Holy Grail Of AI (Y Combinator) on recursive self-improvement as the field's north star.