How to Build a Self-Improving AI Company

In Brief
Tom Blomfield of Y Combinator describes a new way to build companies: not as an old hierarchical organisation where information flows up and down through people, but as a network of AI loops that can measure, act, learn and improve themselves. He calls it a self-improving company.
The old idea is: "How can AI make employees 20 percent more productive?"
The new idea is something else entirely:
How can the company be built so that it improves itself while the people sleep?
Related reading:
What Tom Blomfield is really saying
Blomfield's main point is not just that AI makes people faster. That is too small. That is the old way of thinking.
He says many companies still see AI as a tool you place on top of existing work. A bit like putting a stronger engine on an old horse-drawn carriage. It may go faster, but you still have not understood that the world has actually gained the railway.
Blomfield argues that AI-native companies should be built differently from the start. Not with AI as decoration on the outside of the organisation, but with AI as part of the organisation's nervous system. He describes this as a shift from a hierarchical organisation to a more intelligent, AI-driven organisation where the company's knowledge has been made readable and usable for AI.
A simple mental model:
Traditional company:
AI-native company:
This is not just efficiency. It is a new organisational form.
The old company: a Roman legion
Blomfield starts with a historical analogy: Roman legions.
The Roman Empire had to govern large territories far from Rome. To do this it needed hierarchies: one person was responsible for a group, which in turn reported to a person above them. Information went upward. Orders went downward.
Blomfield says many modern companies still work this way. People become information pipes. They gather status, summarise, pass things on, follow up, remind people of things and make sure decisions move through the system.
It is easy to recognise:
This worked because people were the best tool we had for understanding, sorting and relaying information.
But AI changes this.
If AI can read emails, support requests, Slack messages, customer data, product data, recordings, meeting notes and internal documents, not all information has to be pushed through people all the time.
Then the company can begin to function more like a living nervous system. Not because people become unimportant, but because people no longer have to be the relay for everything.
Why "copilot" is the wrong mental model
Many people talk about AI as a copilot. It sounds smart, but Blomfield thinks it is a limited way to think.
The copilot model says: "You do the job. AI helps you a little."
That can be useful. A developer writes code faster. A support agent answers faster. A marketer creates more drafts. But this does not change the company itself. It just makes existing processes a little faster.
Blomfield argues that this is the wrong frame. He says AI should not be understood as something you "bolt onto the side" of the business. In an AI-native company you have to ask: what really is a company when intelligence can be used directly in every workflow?
A simple analogy:
Copilot AI is like giving every employee a faster pen. An AI-native company is like building an office where the walls, the archive, the calendar, the phone and the project plan understand what is happening and suggest the next step.
That is a much bigger shift.
Extract the domain knowledge
The most valuable thing in a company is often not the software. Nor is it the logo, the website or the dashboards. The most valuable thing is the domain knowledge.
Domain knowledge means everything the company knows about how the work is actually done. It can be:
- how you answer customers
- how you assess sales opportunities
- which mistakes happen often
- what tends to work in onboarding
- how price exceptions are handled
- how support is prioritised
- how an experienced employee thinks
- which decisions are made, and why
The problem is that this knowledge is often scattered. Some of it sits in people's heads. Some of it sits in Slack. Some in email. Some in Notion. Some in old documents. Some in the gut feeling of an experienced person who "just knows" what should be done.
Blomfield says that if you can extract this knowledge and make it readable for AI, the company can move from an ordinary hierarchy to an intelligent, AI-driven organisation.
This is the core:
AI cannot improve what it cannot see.
The self-improving AI loop
Blomfield describes an AI loop with several layers. This is perhaps the most important model in the whole talk.
A self-improving AI loop consists of:
| Layer | What it means | Example |
|---|---|---|
| Sensor layer | The system captures what is happening | Email, support tickets, product data, cancellations |
| Policy layer | Rules for what AI is allowed to do | What requires human approval? What must be logged? |
| Tool layer | The actions AI can perform | Search a database, write code, check a calendar |
| Quality gate | A check before anything is released | Tests, evals, safety filters, human review |
| Learning mechanism | The system sees what did not work and improves | New index, better prompt, new tool, updated skill |
Blomfield uses roughly this model: first a sensor layer, then rules and decisions, then tools the AI can use, a quality gate, and finally a learning mechanism that figures out what failed and sends the lesson back into the system.
This matters because it makes AI more than a chatbot. A chatbot answers. A self-improving loop does this:
It is just like training. If you do strength training once, you will not get dramatically stronger. But if you train, measure, adjust the programme and repeat it for months, the body gets better. The same goes for the company.
The turning point at YC
Blomfield tells a concrete example from Y Combinator.
First they had an agent that could answer questions using deterministic tools. Deterministic here means: tools that give a controlled, predictable result. For example "search the database" or "find the last meeting with this company".
A typical question might be: "When did I last have office hours with this company?"
Then the agent got smarter. It could find relevant people in the YC network, for instance if a founder needed introductions in petrochemicals.
But the big shift came when they placed a monitoring agent over the system. This agent looked at every question YC employees asked. It checked what worked and what did not. When something failed, it asked:
- Why did this not work?
- Are we missing a tool?
- Do we need a better database view?
- Are we missing an index?
- Do we need to update a skill file?
- Should we write new code?
The system could then make a change, open a merge request, have an agent review the change, merge it and roll it out. The next morning, the same kind of question could work better.
This is where the point lands. This is not just AI making one employee 20 or 30 percent more efficient.
This is AI that sees a weakness in the system and suggests or makes an improvement. It is a company that learns from its own mistakes.
Self-optimising product and support loops
Blomfield gives several examples of where such loops can be used.
A product team can have an AI agent that analyses product data. The agent sees where users drop out of the funnel. It researches best practice, suggests an A/B test, runs the test, measures the result and picks the best version. Then it repeats the process.
The same can be done with support. Customers send in questions and suggestions. An agent reads the requests, groups them, finds patterns and assesses what should be done. Some suggestions are discarded. Others fit the roadmap. The system can then make a change, test it and ship the improvement to the customer.
Blomfield describes exactly this as examples of self-optimising product and support loops.
This is powerful because support is no longer just "customer service". Support becomes the sensor of product development. Every customer request becomes a small data packet that can teach the company something.
Burn tokens, not headcount
One of the strongest statements in the talk is:
"Burn tokens, not headcount."
The point is that companies in the AI age should perhaps not primarily measure how many employees they have. They should instead look at how much intelligent work they can get out of AI systems.
Blomfield says YC sees companies arrive at Demo Day with roughly five times more revenue per employee than 18 months ago. He believes this can continue further into Series A and Series B.
This does not mean token usage is automatically good. He also warns that raw token leaderboards can be gamed. If people are rewarded or punished purely based on how many tokens they use, some will use tokens in foolish ways.
But the direction is important. In old companies the constraint was often the number of heads. In AI-native companies the constraint can become how well the company manages to use intelligence.
Old companies asked: "How many people do we need to do this?"
New companies ask: "How much of this can we do with good systems, good data, good agents and good checkpoints?"
Middle management as information routing
Blomfield also says something provocative:
"Middle management is done."
This does not necessarily mean all managers disappear. But it does mean that a certain kind of middle management becomes much less valuable. Middle management that only does this:
- gathers status
- passes information on
- books follow-up meetings
- makes sure people respond
- translates between levels
- keeps the process tidy
This role can increasingly be done better, faster and cheaper by AI.
Blomfield points to two roles he believes become more important:
- IC (Individual Contributor): people who actually build, write, sell, design, analyse or operate.
- DRI (Directly Responsible Individual): one named person who owns a result.
He says you need a named person, not a committee, to get things done.
This is an important point. AI can help with coordination, but responsibility still has to sit with humans. AI can move information, but someone has to own the goal.
Make the whole company readable for AI
If a company is going to improve itself, AI has to be able to see what is happening. Blomfield puts this quite bluntly:
If something is recorded, it happened for the AI. If it is not recorded, it did not happen for the intelligence.
He explains that YC has begun gathering partner emails, Slack messages, direct messages and office hours recordings in the database. The goal is not just an archive. The goal is for AI to be able to understand how the company works.
This is one of the most practical points in the whole talk. AI needs traces. Not because everything should be monitored uncritically, that obviously has to be done with privacy, security and clear rules. But if the company does not write down, log, transcribe or structure its work, the AI does not get enough to learn from.
A simple model:
| What is missing | The consequence for AI |
|---|---|
| Meeting without notes | Lost knowledge |
| Support ticket without a category | Weak learning |
| Decision without a rationale | Useless history |
| Process without documentation | An AI blind spot |
For AI, a company without structure is like a dark room. It cannot help you tidy up if it cannot see the furniture.
The YC manual as a living brain
Blomfield gives a strong example from YC.
YC had a user manual that was written 5 to 10 years ago and was partly outdated. After they had gathered around 2000 hours of recordings from office hours, they could use this material to create a new manual.
They took the recordings, compressed them, categorised them into themes such as fundraising, hiring and cofounder disputes, and asked the system to write a new manual. The result was a 150-page manual that, according to Blomfield, was dramatically better than the old one. Even more importantly: it can be updated every month.
This is perhaps the best picture of what a "company brain" is. Not a static PDF. Not an old Notion page. Not a folder of documents nobody reads. But a living knowledge base that improves whenever the company learns something new.
Then documentation is no longer something you make once and forget. Documentation becomes part of the company's learning system.
Software is temporary, context is valuable
Another important point from Blomfield is that internal software becomes more temporary.
It used to be expensive to build internal dashboards, admin panels and small tools. So you had to plan carefully, build for the long term and maintain for a long time. But if AI can generate internal software quickly, the value shifts.
Then the dashboard itself is not necessarily the most important thing. The most important thing is:
- the data
- the rules
- the workflow
- the instructions
- the domain knowledge
- the context
Blomfield says you should store the data carefully, but treat the software on top as more temporary. Models get better, and then you can regenerate the tools based on the same context.
This is an important shift for everyone who builds internal systems.
In the old days the software was the house. In AI-native companies the software is more like scaffolding: it can be put up, used, taken down and built better the next time. What is valuable is the drawings, the materials and the understanding of what the house is meant to be used for.
Where humans still matter most
This is not a story about humans disappearing.
Blomfield says humans are still needed where AI meets the real world. He mentions new situations, ethical judgements, high-risk moments and emotionally difficult situations. For example a founder considering a break-up with a cofounder. In situations like that you still want a human in the room.
It is a good boundary. AI can help with summarising, searching, analysis, suggestions, pattern recognition, code, documentation, internal tools and follow-up.
But humans should still own judgement, ethics, responsibility, hard priorities, relationships, trust, high risk and emotional situations.
AI can be the engine. Humans still have to be the steering, the brakes and the compass.
How to start safely and smartly
This sounds big. But you do not have to start with a fully self-improving company. Start with one loop.
Choose one area where you already have a lot of repetition:
| Area | First AI loop |
|---|---|
| Customer service | Collect questions, categorise them, find missing answers in the knowledge base |
| Product | Find where users drop off, suggest one improvement, measure the effect |
| Sales | Summarise calls, extract objections, improve the pitch material |
| Accounting | Categorise receipts, flag uncertainty, suggest better rules |
| Internal documentation | Find old documents, update them based on new decisions |
| Codebase | Look at failed agent tasks, suggest better tools, prompts or tests |
A safe starting rule:
Let AI read first. Let AI suggest second. Let AI act last.
Do not give AI full freedom on day one. Build it like this instead:
- AI observes.
- AI summarises.
- AI suggests an improvement.
- The human approves.
- AI makes the change.
- The system logs what happened.
- The next round gets better.
It is like training a new employee. First the person gets to see how things are done. Then the person gets to suggest. Then the person gets to do small tasks. Only later does the person get more responsibility.
A caveat: poor feedback signals make poor loops
Self-improving AI loops sound almost magical. But they can fail.
A good comment under Y Combinator's LinkedIn post sums up the risk well:
"Sleep only helps if the loop knows what a good outcome means."
This is extremely important.
An AI loop has to know what "better" means. If the goal is unclear, the system can improve the wrong thing:
- If support is measured only on response time, answers can become fast but poor.
- If sales is measured only on the number of leads, quality can fall.
- If code is measured only on the number of changes, the system can create more mess.
- If marketing is measured only on clicks, the content can become clickbait.
That is why AI-native companies need good quality gates. Not just "do more", but: do the right thing, in the right way, with the right documentation, within the right limits.
Explained for a 14-year-old
Imagine you have a football team.
The old way is that the coach has to see everything, remember everything, talk to everyone, write everything down and tell each player what to improve. It works, but it is slow.
The new AI-native way is that the team has a smart system around it. The system watches the training sessions. It watches the matches. It sees where the team loses the ball. It sees who often ends up out of position. It sees which drills help. It suggests a new training plan. The coach approves. The team trains. The system measures again.
Then the team gets better because it learns from everything that happens.
A self-improving company is roughly the same. It is a company that does not just work. It learns from its work.
What the talk is really pointing toward
Tom Blomfield's talk points toward a bigger idea: the companies of the future will not just be companies that use AI.
The best companies can become systems that make their own knowledge readable, use AI to improve the workflows, and let humans focus on judgement, relationships and high-value decisions.
This is the difference.
Ordinary AI use: I use ChatGPT to write an email.
AI-native company: every customer request, decision, dataset and process becomes part of a system that improves how the company works.
The first is useful. The second is structural. It changes how the company is built.
In summary
Tom Blomfield's most important idea is that AI should not just be used as a copilot for individuals. AI can be used to build companies that learn from their own actions.
A self-improving AI company needs five things:
- Sensors that capture what is happening.
- Rules for what AI is allowed to do.
- Tools AI can use safely.
- Quality gates that test and limit risk.
- A learning mechanism that improves the system over time.
The big shift is that the company's knowledge has to become readable for AI. Meetings, decisions, support, sales, product data, code changes and internal processes must not just happen. They have to leave traces that AI can learn from.
But humans do not disappear. Humans become more important where judgement, responsibility, ethics, trust and hard decisions matter most.
The simplest way to start is not to build "the whole AI company" at once. Start with one loop. Find one repetitive workflow. Make it visible. Let AI analyse it. Let AI suggest improvements. Set clear limits. Measure the result. Repeat.
That is how a company starts to learn.
Glossary
| Term | Definition |
|---|---|
| AI-native company | A company built around AI as part of the workflow itself, not just as an extra tool. |
| Self-improving loop | A process where the system sees what is happening, acts, measures the result and improves the next round. |
| Sensor layer | The data the system uses to understand the world: email, support, product data, meetings, logs. |
| Policy layer | Rules for what AI is allowed to do, what requires approval and what must be logged. |
| Tool layer | APIs, databases, calendar, codebase or other systems AI can use. |
| Quality gate | A checkpoint that verifies whether an action is safe and good enough before it is let through. |
| Evals | Tests that measure whether AI answers or AI actions meet the desired quality. |
| Domain knowledge | Practical knowledge of how a specific company, field or market works. |
| Company brain | A living knowledge base that gathers a company's data, experience, rules and processes. |
| IC | Individual Contributor. A person who builds, writes, designs, sells, analyses or operates directly. |
| DRI | Directly Responsible Individual. One named person who owns responsibility for a result. |
| Token usage | The amount of AI computation used. Tokens are small pieces of text AI models read and write. |
| Merge request | A proposal to merge a change into a shared project, so others can review it first. |
| Deterministic tool | A tool that gives a controlled, predictable result every time, for example a database search. |
Sources and resources
- How to Build a Self-Improving Company with AI — The source talk with Tom Blomfield of Y Combinator.
- Y Combinator: post about the talk (LinkedIn) — Y Combinator's own summary and transcript, including the description of recursive, self-improving AI loops.