Video Title: How to Build a Self-Improving Company with AI
Video Author: YC Root Access
Translation: Peggy

Editor's Note: In this latest YC batch talk, YC Partner Tom Blomfield discusses not "how to use AI to improve employee productivity," but a more fundamental question: when AI is no longer just a Copilot, but can perceive, make decisions, invoke tools, accept feedback, and self-correct, what should the company itself be redesigned to look like?

Tom's core argument is that traditional companies still operate like a "Roman legion": information flows upward through hierarchies, and commands cascade down management chains. However, AI is disrupting this organizational assumption. What truly matters is not getting engineers to write 20% more code, but extracting business knowledge scattered across emails, Slack, meetings, documents, and human brains, and turning it into AI-readable, callable, and iterable organizational context.

In his view, future AI-native companies will be made up of a series of recursive, self-improving AI loops: systems that perceive external changes from customer emails, support tickets, and product data, then make decisions through rule layers, tool layers, and quality gates, and finally learn and correct automatically based on outcomes. YC internally has been experimenting with similar mechanisms: agents not only answer questions but also monitor failed queries, determine the need for new tools, databases, or indexes, and automatically submit code, review, merge, and deploy. In other words, the company can continue to optimize while the founder sleeps.

This also means that AI's impact on the company will not stop at the tooling layer but will further transform the organizational structure. Tom proposes "burn tokens, not headcount"—the bottleneck for future startups may no longer be the number of employees but the use of tokens, the quality of business context, and the readability of organizational knowledge. The coordinating function carried out by middle management will be significantly replaced by AI, while individual contributors, direct managers, and human roles capable of handling high-risk judgments in the real world will become more critical.

What is most noteworthy is not that AI is making companies more efficient, but that it is transforming the very form of the "company" as an organization. When software can be generated on the fly, processes can automatically improve, and expertise can be continuously distilled into the company's brain, what founders may truly need to build is no longer a hierarchically structured team but a set of intelligent systems that can learn and self-optimize continuously.

Original Text:

Rewriting Operations: Companies Should No Longer Operate Like a Roman Legion

This section is somewhat based on Diana's previous speech. The video of that weekend's event has been uploaded and is very exciting. In addition, Jack Dorsey tweeted some interesting thoughts about two to three weeks ago, which I found fascinating, so I "borrowed" many of his ideas and incorporated them into this presentation.

This presentation is more conceptual and high-level, mainly discussing how we should rethink company building.

The design of the Roman Legion was essentially to project power outward from the center of Rome, covering two continents and even extending all the way to Hadrian's Wall near Scotland. It relied on a nested hierarchical structure, with each level having a stable span of control. Each level had a clear leader responsible for cascading commands down and information up.

If you observe most companies today, you will find that they still operate like a Roman Legion: people are conduits for the flow of information. One point from Jack Dorsey's tweets that left a deep impression on me is that we have always assumed that a hierarchical organization is the best way to organize economic value units within an organization. But I believe that AI is fundamentally challenging this assumption.

A year ago, if you asked people about the utility of AI, they would often talk about "productivity": for example, how Copilot boosts an engineer's efficiency by 20% or integrating Copilot into workflows to help teams deliver more software. However, I think this is a problematic understanding. It's like putting a more powerful engine in the old way of working. What is really worth considering is not how to add an AI tool to an old organization but to reimagine what a company is and how it should operate.

For example, what Garry just talked about, I truly believe that the amount of code he can produce alone now may be more than that of an entire engineering team. What I have been thinking about all along is how to extract the domain knowledge within a company and define it as context, a skill set, or whatever you want to call it.

The so-called domain knowledge, business knowledge, know-how, originally scattered in people's minds, Slack messages, emails, Notion documents. All this information collectively defines how your company operates. Once you can make this knowledge clear and accessible, you can transition from a hierarchical organization to an AI-native software-driven intelligent organization.

Making Companies Better While They Sleep: How AI Closed Loop Automatically Discovers, Fixes, and Deploys

AI is not something tacked onto a company. It's not just a tool for engineers to enhance efficiency. I believe we can reimagine a company as a set of recursive, self-improving AI loops. This point is crucial because once a company reaches this stage, it will continue to self-optimize even while you sleep.

Let's take an example.

Diana also mentioned this AI loop in her presentation. It starts with a "sensor layer." While the term may sound sophisticated, it can be quite simple: customer emails, customer support tickets, code changes, user cancellations, product telemetry data – these are all sensor data used to gather information from the external world.

Next is the policy or decision layer, which consists of rules: what AI can do, which tasks require human permission, which operations need to be logged. Below that is the tool layer, somewhat similar to what Garry referred to as skills and code, essentially a deterministic API, such as querying a database, checking a calendar, etc. – a set of tools that AI can invoke.

Then comes the quality checkpoint, including deterministic checks, security filters as Eva mentioned, and human reviews of high-risk items. Finally, there's the learning mechanism: the system interacts with the real world, discovers where it's falling short, and then feeds that feedback back into the beginning of the loop.

If each step can operate without human intervention, or with minimal human intervention, the system will continue to improve while you sleep.

I can provide you with some examples of what we are currently running in practice. Initially, we created an agent that you could ask questions, with some deterministic tools to query our database. For instance, a simple question: When was the last time I held office hours with this company?

Later, it became a bit smarter. For example, if I'm conducting office hours with a company that needs to meet people in the petrochemical industry, this system can query the database in different ways, use methods like RAG, and identify five relevant founders to recommend for your acquaintance.

But this was still just a sidekick, an assistant-type agent. It was still last year's type of AI usage: AI making me more efficient as a group partner, increasing my work efficiency by 20% or 30%.

What truly gave me an 'aha moment' was when we added a monitoring agent on top of this system. It would examine every query initiated by each YC employee, determine which queries succeeded, which failed. Then it would ask: Why did it fail? How can we make this query successful? Do we need a new deterministic tool? Do we need to update the skills file? Do we need a new database? Do we need new indexes?

These things now actually happen automatically at night. It will write code, submit a merge request to YC's codebase for another agent to review, and then merge and deploy. So the next day, when a human asks the same question again, the query will succeed.

For me, this is the crucial moment. It's not just about making a human 20% or 30% more valuable. It's about AI going through this loop on its own, finding ways to self-improve.

I believe that if you can identify which parts of the company can operate this way, and minimize the human execution and oversight role as much as possible, then you can invest tokens in this problem, and the company itself will continue to get better.

There are many other examples. For instance, if you have product analytics data, you can have an agent analyze the product data, identify the most frictional point in the sales funnel. It can research best practices, set up an A/B test, run for a week, select the best-performing version, and then deploy it.

This will happen over and over again. Your product will have a self-optimizing product loop.

The same goes for customer service. Customer suggestions keep coming in, and you can use an agent to triage. This agent is somewhat like your Chief Product Officer and Chief Technology Officer; it has to make judgments: we don't want to do this suggestion, discard it; but that suggestion aligns with our roadmap and can be completed tonight. Then write the code, deploy, go live, delivered directly to the customer, no human intervention needed throughout.

Therefore, if you can view every part of the company as a self-improving recursive AI loop, it will become something completely different from a "Roman legion-style" hierarchical company.

Less Headcount, More Token Burning: AI-Native Companies Will Reshape Organizational Structure

So, what does it mean if you want to do this?

The first point is: consume tokens, not headcount. We now see that many companies by Demo Day have seen a per capita income increase of about 5 times compared to 18 months ago. I believe this trend will continue into the A and B round stages. Soon, what truly limits you will not be the headcount but the amount of token usage.

The crudest approach now is to measure each person's token usage. Of course, this metric can be ridiculous in extreme cases and easily gamified. But directionally, I think it's right. We are now in a stage of exploring "what is possible," so everyone should experiment to the maximum and see what this crazy new intelligence can really do.

Once you turn it into a leaderboard and tie promotion or firing to that metric, it will undoubtedly be gamed, and of course distorted. But directionally, figuring out who in the organization is really pushing the token to its limits, and who isn't, is a way to assess where you should be spending your time on employees.

I think middle management is over. At least for this kind of coordination issue, I don't think you need middle management anymore, I think AI should solve this.

For me, there are two key roles in the future. Jack Dorsey proposed three, but I don't like the third one much, so I cut it. I think the really important thing is two roles: everyone must be an IC, which is an individual contributor, a builder, a driver. And the key there is having individual ownership. Anything that needs to move forward needs a named person responsible, not a committee, not a group of people.

I think a company can entirely be built on ICs. Middle management is truly over. And building a company that is self-improving, that is the vision.

By the way, I think everyone is still at the frontier of this. I'm really curious where you guys are at. It feels like everyone is still exploring the boundaries. I'm not sure if anyone has truly built a self-improving company in every function. Maybe I'm wrong, you can prove me wrong.

If it were me, what would I do first?

The first very important thing is to make the entire organization AI-readable, AI-comprehensible. What does that mean? It means you have to document everything.

In essence, every email of all our partners now, if you email a YC partner, that email goes into the YC database. Every Slack message, every DM, every office hours, we've been recording all of them for the last three to four months. Everything that happens, as long as it's documented, it happens for the AI; if it's not documented, it didn't happen for your smart system.

Just now, as I was chatting with some founders here, we had a lot of good content about their company. Every time I talk, I think, I should really record this conversation. Because someone just now asked me to introduce them to someone, and I can't even remember who that introduction was for now. I said yes at the time, and then told him to email me later, because I know I will forget, I have 20 more people to talk to next.

So, this might require using a phone, a voice recorder, smart glasses, or put a microphone in every room. Basically, everything needs to be recorded so that AI can understand it.

Next, as Garry mentioned, we also need to work on speaker separation and summary compilation. You can't just stuff 100,000 hours of recordings into the context window. You need to organize them, aggregate, compress, distill them into key parts, and leave some clues for the AI.

For example: How many of you have read the YC manual? I hope everyone in this room has opened it at least once. No worries. Most of the manual was written five to ten years ago and is a bit outdated.

Last weekend, Harsh suddenly thought: since we have accumulated about 2,000 hours of office hours recordings over the past three months, why not regenerate a new version of the user manual?

So you can give the system a set of instructions to first organize, compress, and synthesize the recordings, categorize them by topics such as fundraising, hiring, and co-founder disputes, and then have it write a new version of the user manual. By the end of the weekend, he had generated a 150-page user manual, significantly better than the current version.

More importantly, now we can update it monthly. So our user manual has become a self-improving system. Every new suggestion is compared with the existing user manual and either absorbed or discarded. This way, the user manual has become a continuously updated living brain, carrying our weekly advice to founders.

Of course, it doesn't stop at the user manual. You can use it as context input for an AI agent. Suddenly, you can ask a super-intelligent AI questions and get the synthesized wisdom of a 16-bit YC partner. But the prerequisite is that this knowledge must be readable by AI. So you have to record everything.

The second point is actually similar: if something can create an artifact that can self-improve and be read by AI, then keep it; if not, discard it.

The third point is that every function should be able to generate its own software. In the past, we might have said "dashboard," but now it's not just a dashboard, it's on-demand generated software. Codex 5.5 is now good enough that for most simple internal software and dashboards, you can generate them once to a fairly high quality. I tried it with some of our internal stuff over the weekend, and the results were truly amazing.

So, all internal operations teams should sit on top of this layer: have an intelligent understanding of the business and then generate their own dashboards and workflows.

And I consider this software as completely disposable. What should really be cherished and preserved is data. Like Garry said, he saves all emails as Markdown, never discarding anything. But the software itself is ephemeral, temporary. You can generate it, and you can regenerate it.

What is truly valuable is the understanding in people's minds of the business: how this function operates, how we run a YC event, and so on. As for the software used to actually execute the event, you can generate one for the event, use it, and then throw it away. A month or two later, the model becomes smarter, so you throw away the old software, give it the original instructions again, and generate a new version of the software.

Therefore, I believe that what is valuable is the business context and skills. The software built on top of them is transient.

So, in this world, what is the role of humans?

I believe that what we are actually discussing is a "company's brain." I know that many people in this room are doing similar things. The middle part—the sum of all your data, all emails, DMs, skills, know-how—is the company's brain.

Humans, on the other hand, are at the edge of this brain, responsible for interacting with the real world. In other words, humans are where this intelligent system touches reality. Humans can enter scenarios that the model cannot yet enter temporarily. For example, a conference venue or some novel, complex situations. I originally thought of using the phone as an example, but now AI can easily handle phone scenarios as well.

More typically, these are unfamiliar situations, ethical judgments, high-risk moments. For example, a founder comes to us and says he is considering parting ways with a co-founder. In such truly high-risk, high-emotion moments, you still want a human present.

This is the position of humans. For many of your companies, sales conversations are also like this. In the next 20 years, I believe that human presence will still be needed in sales scenarios.

Therefore, I believe that humans will live at the edge of the company's brain, responsible for bringing intelligence into the real world.

I am running out of time, and the host may be about to pull me off the stage. Finally, I leave you with a question: If you were starting your own company today, would you design it in this way from the beginning?

Many of your companies are still small enough to do this. So, I think you have no excuse. And I know that there are a few people here who are tearing down and rebuilding their companies.

So, I will stop here and hand over the time to Pete. Thank you, everyone.

[Video Link]

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia