Every Company Needs a Brain

Source: AI Engineer · Speaker: Garry Tan, Y Combinator · Video ID: eBUyTS7SzV4 · Published July 17, 2026

The AI-native company is not a normal company with smarter autocomplete. It is an organization whose memory, procedures, routing, reviews, and operating judgment have been encoded so agents can do real work without forcing humans to start from scratch every morning.

Who Is Garry Tan?

Garry Tan is the president and CEO of Y Combinator, a founder, investor, and former YC partner who has spent more than a decade close to the mechanics of early-stage company formation. His perspective matters because YC is both an investor in the fastest-moving AI-native startups and a 20-year-old institution trying to become AI-native itself.

That dual vantage point gives Tan a sharper frame than the usual “AI will make engineers faster” story. He is not just watching founders use agents; he is trying to rewire YC’s own media, finance, events, investing, and internal software work around the same primitives.

The 400X Claim Is Really an Organization Design Claim

Tan opens with a provocation: in 2013, while working as a YC partner and building YC’s internal social network, he estimates he produced around 14 usable logical lines of code per day. In 2026, running YC full-time with fewer coding hours and a 5 p.m. kid pickup, he calculates his output at roughly 400X.

He immediately deflates the easy objection. Penalize the code for verbosity. Assume half is scaffolding. Assume self-flattery. Even then, the range is still meaningfully large: perhaps 8X at the floor and 80X in the middle. The precise multiplier matters less than the cause.

“It’s not the model. The 2X people and the 100X people are using the exact same Claude. Same weights, same context window, same API. The leverage is not in the weights. It’s in how you wire the work.”

That is the central thesis. The performance gap between AI dabblers and AI-native operators is no longer primarily model access. It is whether the work has been structured so agents can act like a managed workforce rather than a magical text box.

Skill Files Are Employees, Resolver Tables Are Org Charts

Tan’s most useful metaphor is organizational. A skill file is an employee: one capability, one job, written clearly enough that another system can execute it. A resolver table is an org chart: when a task arrives, the resolver determines which skill or context should handle it. Filing rules are internal process. Trigger evals are performance reviews: if a task requires altering tests, does the system actually load the testing skill?

In that framing, the old thousand-person organization becomes a set of written capabilities, routing rules, memories, and verification loops. The management layer is no longer only people and meetings. It is markdown, TypeScript, evals, harnesses, and the discipline of keeping the machinery current.

Tan’s line is deliberately jarring: when a founder sits down with Claude Code, Codex, or another coding harness, they are not simply writing software. They are hiring, training, and managing a workforce made of markdown.

AI-Native Companies Treat AI as a Workforce, Not Autocomplete

YC’s recent batches give Tan concrete examples. In the Winter 2025 batch, a quarter of companies had codebases that were 95% AI-generated, and that batch became the fastest-growing and most profitable in YC history. Tan does not claim AI-generated code caused the growth. His narrower, stronger claim is that the fastest-growing founders are not treating AI as autocomplete. They are treating it as a workforce.

He points to companies operating at revenue-per-head levels that previously did not exist. Emergence, an AI app builder from Summer 2024, reportedly went from public launch to nine figures of ARR in eight months and had only 15 people when it crossed $15 million ARR. Retell, from Winter 2024, reached $60 million with about 40 people. Tan’s argument is not that these companies are freaks; it is that they are early examples of “the new physics.”

The operating pattern is different. Instead of hiring hundreds across sales, support, ops, and finance, AI-native companies encode those functions as skills and hire engineers whose job is to maintain the skills, do the work the skills cannot yet do, and improve the management system around them. At YC itself, Tan says media people, event staff, and finance staff—not just engineers—are building skill files and cron jobs. One finance person collapsed around 100 Excel workbooks into a single internal app built with YC’s internal agent stack and company brain.

Where the Computation Lives Determines Whether the System Works

One of Tan’s most practical engineering lessons is to separate latent space from deterministic space. Latent space is the LLM: taste, judgment, interpretation, ambiguous human intent, and non-deterministic calls steered by markdown. Deterministic space is software: TypeScript, Erlang, databases, arrays, algorithms, state, and verifiable computation.

Many AI engineering bugs happen because computation is placed on the wrong side. If a task requires judgment, forcing it into rigid code can make it brittle. If a task requires exact storage, counting, scheduling, ranking, or state management, leaving it inside the context window is a mistake.

Tan’s Startup School example makes this concrete. YC wants to seat 800 people at a time from a pool of around 6,000 so that each attendee sits next to highly relevant people. The LLM should help with the human part: understanding who should meet whom. But the actual representation of 800 seats in a multidimensional arrangement should not live in the model’s context window. It belongs in deterministic data structures, with the model collaborating where judgment matters.

The Company Brain Is the Library Plus the Librarian

Human working memory is famously small: seven things, plus or minus two. Tan uses the “seven digits” idea to explain why companies invented checklists, org charts, filing cabinets, and processes. Institutions are prosthetics for human memory limits.

An AI agent with a million-token context window can hold around a thousand pages in its head. Tan explains this to his 10-year-old as “three Harry Potter books” open at once. That is magical compared with seven digits, but tiny compared with a company. A company is not three books. It is a library: emails, meetings, decisions, customer conversations, postmortems, prior reasoning, and institutional scar tissue.

The decisive question is who chooses which three books are open on the agent’s desk. That is context engineering. A company brain is not merely storage. It is the library plus the librarian.

Tan expects the obvious objection: “This is just RAG.” His answer is that retrieval is only the primitive, the way Postgres is “just B-trees.” The hard product surface is everything around retrieval: what gets written down, how it gets enriched and linked, what is promoted to hot memory versus cold reference, who arbitrates contradictions, and how stale facts are pruned.

“Retrieval is easy. Being worth retrieving from is the product.”

GBrain and the Difference Between Assistant and Colleague

Tan describes his own open-source project, GBrain, as a retrieval layer for agents: effectively Postgres for agents, designed to decide which “three books” should be loaded into an agent’s head for a task. His personal brain has grown into roughly 220,000 pages from email, meetings, 20 years of notes, and lived experience—much of it written by agents.

The practical difference is speed and continuity. When a founder emails him about a crisis, Tan says his agent can pull prior conversations with that founder, three portfolio companies that hit the same wall, and what worked for those people before he has even finished reading. The agent does work knowing what he already knows. That is the difference between an assistant and a colleague.

But Tan is careful about failure modes. A brain nobody curates becomes a garbage dump with great search. Retrieval can surface a stale fact with total confidence. A bad skill file can encode a bad process forever. The primitive is not memory alone; it is memory plus hygiene: provenance, contradiction checks, pruning, and a human-plus-agent librarian responsible for maintaining the system as production infrastructure.

Never Do One-Off Work

The discipline Tan wants founders to adopt is simple: never do one-off work. Use an agent to complete a task. Iterate until the output is good. Then skillify it. Turn the successful pattern into a reusable skill file so the organization can perform it again without rediscovery.

This is the compounding loop. The organization that captures what it learns gets smarter every day. The organization that does not wakes up with amnesia, no matter how good the model is. Tan’s line is a useful strategic distinction: model quality is rented; your brain is owned.

What to Build Now

Tan’s answer to “What do we build now?” is direct: build the AI-native company, not a company that merely uses AI. Start with a thin team, skill files for everything, the founder still in the code, and a company brain that compounds from week one.

He also names the greenfield opportunity he would pursue if he were 25: every company is about to need a brain. The memory layer, the personal context system, and the librarian that chooses what context to load remain wide open territory. GBrain may be open source and free, but the market for company brains and personal AI that actually knows the user is still being defined.

Tan closes with abundance rather than fear. A friend with a son who has a rare form of epilepsy built a repo of 80,000 markdown files—a company brain for one small boy—and pushed himself to the edge of what humanity knows about that exact condition. No lab, no grant, no permission: a father, a laptop, a library, and a librarian.

That example is not a sentimental aside. It is the architecture applied to something deeply human: the right three books open at the right moment, pointed at the thing that matters most.

Key Lessons

Why This Matters for Diffie

For Anand and Diffie, Tan’s talk is almost uncomfortably on the nose. Diffie is not just building a browser testing tool; it is building infrastructure for teams whose frontend quality process cannot keep up with the speed and surface area of AI-assisted product development.

The sharpest product implication is that Diffie should think like a company brain for frontend behavior. A normal test runner knows whether a test passed. A useful AI-native QA system knows the product history, prior failures, accepted visual changes, flaky selectors, customer-critical flows, design intent, release context, and what the engineering team already learned last time. That is the difference between an assistant that reports red and a colleague that says, “This failed for the same reason checkout failed two releases ago, and here is the likely fix.”

Tan’s latent-versus-deterministic split is also a clean architecture principle for Diffie. Use deterministic systems for browser execution, screenshots, DOM diffs, network traces, replay, state management, and assertions. Use latent space for intent matching, visual judgment, failure explanation, change classification, and deciding which historical examples should be loaded into context. The product will be stronger if it is explicit about which side owns which computation.

For GTM, the message is equally direct: sell to teams trying to become AI-native, not merely teams with too many tests. Their pain is organizational memory. They are shipping faster, generating more code, and accumulating more frontend behavior than humans can manually inspect. Diffie can position itself as the librarian for browser quality: the layer that chooses the right three books—past failures, product intent, visual baselines, customer flows—when an agent is trying to understand whether the UI is still correct.

The practical move is to skillify Diffie’s own workflows. Every repeated QA investigation, onboarding pattern, demo setup, outbound objection, and customer failure analysis should become a reusable skill or memory-backed process. If Tan is right, the winning company is not the one with the best prompts. It is the one whose learning compounds fastest.