Startups Should Build Recorded, Queryable Operations That AI Can Improve

Tom Blomfield’s starting point is that most companies still resemble the Roman legion diagram he showed: nested hierarchies, consistent spans of control, named people passing orders down and information back up. In that structure, human beings are the coordination mechanism.

The slide that followed quoted Jack Dorsey: “There’s an underlying assumption that organizations have to be hierarchically organized with humans as the coordination mechanism.” Blomfield’s answer was that AI breaks that assumption. If a company’s know-how can be extracted from heads, Slack, email, Notion, customer interactions, code, and operating history, then the company does not have to route so much coordination through managers and meetings.

That is why he rejected the usual productivity framing. A year ago, he said, founders mostly talked about copilots, engineers becoming 20% more productive, AI added to existing workflows, and more software shipped by the same org chart. To Blomfield, that keeps the old company intact and merely puts a stronger engine inside it. His preferred frame is capability: one person using AI can become more powerful than the structures companies used to require.

The organizational implication is blunt. Blomfield said middle management is “done” because AI should handle much of the coordination problem. He reduced the company to two roles he considers essential: individual contributors, who are builders and operators, and directly responsible individuals, who own outcomes. Everyone builds, including people in engineering, operations, support, and sales. Important work should have one named human responsible for the outcome, not a committee.

Blomfield’s practical prescription is to treat the company as a system AI can observe, query, and improve. He is arguing for an operating model built around recursive loops: record the work, preserve the context, expose deterministic tools, define the rules, and create feedback mechanisms that let the system notice failures and improve the next run.

For Blomfield, the boundary is stark. “If it is recorded, it happened to the AI. If it did not get recorded, it did not happen to your intelligence.” At YC, he said, emails sent to YC partners are now in the YC database; Slack messages, DMs, and office hours are being captured; and office hours had been recorded for the previous three or four months. The reason is not archival neatness. It is that the company’s intelligence can only learn from what it can see.

Recording alone is insufficient. The material has to be compressed, structured, and made retrievable. Blomfield referred to diarization and synthesis: a company cannot put 100,000 hours of recordings into a context window, so it needs systems that aggregate conversations into useful parts and leave “breadcrumbs” for AI to follow.

YC’s user manual was his example. The existing manual, he said, was mostly written five to 10 years ago and had become somewhat out of date. With roughly 2,000 hours of recorded office hours from the previous three months, Blomfield said the material could be categorized into areas such as fundraising, hiring, and co-founder disputes and used to regenerate the manual. By the end of a weekend, he said, YC had produced a 150-page manual that was “dramatically better” than the existing version.

The more important change is that the manual can now keep improving. Each new piece of advice can be compared with the existing manual and either incorporated or discarded. The manual becomes a living record of YC’s advice; the same context can then be supplied to an AI agent so a user can query something like the combined judgment of YC partners. But the condition remains: only legible work can become part of the company brain.

Blomfield’s model for the AI-native company is not a set of copilots attached to existing workflows. It is a set of recursive, self-improving loops. A loop starts with sensors and data, passes through rules and tools, is checked by quality gates, and feeds failures back into a learning mechanism.

The threshold that matters is whether the loop can run with minimal human intervention. If it can, Blomfield said, the company improves while people are asleep.

YC’s internal agent began in a familiar assistant mode: employees could ask when they last had office hours with a company, or ask for introductions to founders in a particular area. The system could query YC’s database and use retrieval methods to find relevant people. That was useful, but Blomfield treated it as last year’s version of AI: a sidekick that makes a group partner 20% or 30% more effective.

The change came when YC added a monitoring agent on top. That agent looked at queries YC employees were running, identified which ones worked and failed, and then asked what would have made the failed query succeed. Did the system need a new deterministic tool, an updated skills file, a different database view, or a new index?

According to Blomfield, that improvement process now happens overnight: the system writes code, opens a merge request against the YC codebase, has an agent review it, merges it, and deploys it. The next day, a similar human query can succeed because the system changed itself. That is the difference he drew between AI-assisted productivity and a self-improving operating system.

The same logic applies beyond internal search. Blomfield described a product analytics loop that inspects a sales funnel, finds the highest-friction point, researches best practices, launches an A/B test, runs it, chooses the better version, deploys it, and repeats. In customer support, he described a loop that ingests requests, triages suggestions, rejects those that do not fit the roadmap, and implements those that do. He said this would require agents making judgments analogous to a chief product officer and chief technology officer; in the aggressive version, the system writes and deploys code without a human in the path.

The spending consequence is that startups should spend more aggressively on AI usage and less reflexively on people. Blomfield’s slide put it as “Burn tokens, not headcount,” adding: “If your API bill doesn’t make you uncomfortable, you’re not doing enough.”

YC, he said, is seeing companies reach Demo Day with about five times more revenue per employee than companies did 18 months earlier, and he expects that pattern to continue through Series A and Series B.

He expects startups to become constrained by token usage before they are constrained by headcount. Measuring individual token usage is, in his view, a crude and gameable proxy if turned into a leaderboard or tied mechanically to promotion and firing. But directionally, it reveals who is experimenting with the new capability and who is not. In this phase, the point is to discover what is possible.

Blomfield treated internal software as increasingly temporary. The durable asset is the company’s data, context, skills, and operational understanding. The software layer can be generated, regenerated, and discarded.

Internal teams, in his view, should sit on a layer of company intelligence and create their own dashboards, workflows, and tools on demand. What used to be “dashboards” becomes broader: internal software for revenue, sales, engineering, hiring, and operations. He said current coding tools are already good enough to one-shot many simple internal dashboards to a high level of quality, based on his own experiments.

The rule is to store the underlying material carefully and treat the interface as ephemeral. Keep emails, records, instructions, and operational context. If models improve in a month or two, throw the software away, provide the original instructions, and build a better version. The value is not the custom app used to run an event; it is the company’s understanding of how that event works.

Blomfield did not argue that humans disappear. He described the emerging structure as “company brain plus humans”: the center is the accumulated company intelligence — data, emails, DMs, skills, know-how, context — while humans sit around the edge, where that intelligence meets reality.

The remaining human role is to handle places models cannot yet go, or should not handle alone: novel situations, ethical considerations, and high-stakes moments. His example was a founder considering a breakup with a co-founder, where the stakes and emotion make human judgment necessary. He also said sales conversations are likely to keep a human in the room “for the next 20 years.”

The challenge for founders is architectural: if they were starting the company today, would they build it in its current shape? Blomfield’s answer is that early-stage companies are small enough to rebuild around AI-native loops now. In his words, they have “no excuse” to preserve a structure designed around human hierarchy if the company can instead be made recorded, queryable, recursive, and self-improving.