Every company should have a Brain — Garry Tan, Y Combinator

What should you build when one person might be able to do work that previously required an entire organization? Garry Tan approaches that question as a founder, investor, and leader transforming Y Combinator, a twenty-year-old institution, into an AI-native company. His ambition is literal: one person doing work that once took a thousand people. With the startup battlefield about an hour away, the immediate challenge for the audience is to recognize what has become possible before deciding what to build.

The first example is his own engineering work. In 2013, Tan was building YC’s internal social network while also investing in companies. He recalls producing about 14 usable logical lines of code per day as a near-full-time engineer, excluding comments. He places that beside an asserted contemporary range of 15–50 lines per day and a median near 15. Today he runs YC full-time, spends fewer hours engineering, and has a 5 p.m. child pickup. Tan reports roughly 400× his earlier raw code output, with an asserted 8× floor and 80× middle after discounting verbosity and scaffolding. These are personal estimates; the talk supplies neither a measurement protocol nor the calculation behind those discounts.

The proposed source of the gain is how the work is organized. Tan contrasts people getting 2× and 100× improvements while using the same Claude weights, context window, and API. He reports that a quarter of YC’s Winter ’25 companies had codebases that were 95% AI-generated, and calls that batch YC’s fastest-growing and most profitable. Separately, he says 94 companies funded by YC at seed have crossed $100 million in revenue. He explicitly does not establish that AI-generated code caused the growth. The operating distinction he draws is between using AI as autocomplete and organizing it as a workforce.

An agent system already has recognizable management functions. A skill file specifies one capability and one job clearly enough to execute. When CLAUDE.md grows too large, a resolver table can direct the agent to the instructions relevant to the incoming task. Tan’s example is loading tests.md when a task requires altering a test. Instead of putting every procedure into the initial context, the system chooses which procedure to bring into the work.

The routing decision itself needs evaluation. Does a request to change a test actually load the intended test instructions? Tan calls this a performance review because a written responsibility is not enough: the system must demonstrate that it follows it. He says tests.md in the routing example and test.md in the evaluation example; an implementation needs one exact filename shared by the route and its check.

A small TypeScript example makes that contract explicit, using tests.md consistently:

import assert from "node:assert/strict";
import { readFile } from "node:fs/promises";

type TaskKind = "alter-test";

const instructionsFor: Record<TaskKind, string> = {
  "alter-test": "tests.md",
};

async function loadInstructions(
  task: TaskKind,
  load: (path: string) => Promise<string>,
): Promise<string> {
  return load(instructionsFor[task]);
}

async function checkTestRoute(): Promise<void> {
  const loaded: string[] = [];
  const text = await loadInstructions("alter-test", async (path) => {
    loaded.push(path);
    return "Test-editing instructions";
  });

  assert.deepEqual(loaded, ["tests.md"]);
  assert.equal(text, "Test-editing instructions");
}

async function main(): Promise<void> {
  await checkTestRoute();
  const instructions = await loadInstructions("alter-test", (path) =>
    readFile(path, "utf8"),
  );
  console.log(instructions);
}

main().catch((error: unknown) => {
  console.error(error);
  process.exitCode = 1;
});

This checks loading after a task has been classified as alter-test; a full trigger evaluation would also check whether the agent recognizes a natural-language test-editing request. The organizational machinery can therefore be mostly Markdown, with code where an explicit contract or check is useful. In Tan’s framing, working through Claude Code or Codex becomes hiring, training, and managing that workforce.

Tan points to two companies as examples of the economics he associates with this structure:

Emergent, which Tan identifies with YC’s Summer ’24 batch, also reports the $100 million ARR milestone on its own site. ARR is an annualized recurring-revenue measure, not realized annual revenue. Retell’s own announcement labels its figure $60 million ARR and gives 35 employees; that is a separate company account, not a replacement for Tan’s approximate headcount. His broader assertion that these revenue-per-person levels are unprecedented across software, oil, and railroads is not established by the examples alone.

The organizational mechanism is to encode sales, support, operations, and finance as written procedures that agents execute. Engineers maintain those skills and do the work that the skills cannot yet handle. Tan even offers tax filing as a task that could be represented by a skill. This changes the staffing question from how many people to hire for each function to which procedures can run reliably and where people still need to intervene.

He pictures roughly 400 founders at laptops in YC’s batch room, each doing a former person-year of work in a day. That is his competitive ambition, not a measured throughput result for the room. The extension beyond engineering is more concrete: YC’s media, events, and finance staff are creating skill files and cron jobs, including people who had never opened a terminal. Tan reports that a finance employee consolidated about 100 Excel workbooks into one app using YC’s internal OpenClaw and company brain. Her role becomes managing agents rather than first becoming a programmer. Tan extends his 400× aspiration to the organization as a whole.

Reliable agent work depends on deciding where computation belongs. Tan separates two places:

• Latent space: The model handles taste, judgment, and interpreting what someone means by a vague request. Markdown instructions steer these nondeterministic calls.
• Deterministic space: Ordinary software performs explicit operations and maintains state. Agents can write that software in TypeScript or other languages; Tan also names Erlang and Elixir.

A recurring source of bugs, in his experience, is putting work on the wrong side of this boundary. Better instructions cannot substitute for an explicit representation of the state a system must preserve.

Startup School seating makes the boundary tangible. Tan describes a prospective experiment involving a population of 6,000 people, seating 800 at a time so that each attendee’s neighbors are especially useful people to meet. The model can judge interpersonal fit, but the multidimensional arrangement of seats must live outside its context window. The seating plan is operational state; interpreting why two people should meet is judgment.

A human given this assignment might print 800 pages, spread them through a room, and move people into groups. The room and paper would provide external memory while the person made the matching decisions. The software version needs the same division of responsibility. Tan speculates that the seating task could take a couple hundred dollars in tokens and probably ten minutes instead of a month. This is a proposed experiment, not a completed benchmark; he presents it as an example of work he believes was out of reach even roughly six months earlier.

External memory is already central to human organizations. Tan invokes George A. Miller’s The Magical Number Seven, Plus or Minus Two, using seven-digit phone numbers and a forgotten eighth grocery item to illustrate limited working memory. Miller’s paper concerns task-dependent limits, learned chunks, and recoding; it does not establish a universal seven-digit ceiling or the origin of telephone-number lengths. The useful organizational observation is that checklists, org charts, and filing cabinets let people coordinate work they cannot keep in their heads.

Tan compares a million-token agent context to about 1,000 pages or three Harry Potter books open at once. Explaining GBrain to his child, he describes an agent finding information and synthesizing across those books in seconds. The page and book counts are illustrative, and no model-specific retrieval evaluation accompanies them. He does not treat this as proof of AGI; it is a different working-memory regime from the one around which familiar organizations developed.

But even three open books are small beside a company’s library. That library includes emails, meetings, decisions and their reasoning, customer conversations, and postmortems. Context engineering decides which books are open for the current task. A large context window supplies working space; it does not itself decide which parts of the organization’s history deserve that space.

The company brain is the library plus the librarian. Retrieval-augmented generation supplies a primitive, but calling the whole system RAG leaves out much of the product—much as describing Postgres as B-trees leaves out the surrounding database system. The harder responsibilities are deciding what enters the knowledge wiki, enriching and linking it, promoting useful material to hot memory, filing other material as cold reference, and arbitrating when facts disagree.

“Being worth retrieving from is the product.” Tan calls his implementation GBrain, describing it as Postgres for agents: a retrieval layer that chooses the relevant books for a task. He says it works with any harness and particularly likes OpenClaw and Hermes Agent. The architectural responsibility remains context selection, whichever harness performs the work.

Tan reports that his personal GBrain archive contains about 220,000 pages, mostly written by agents from email, meetings, and twenty years of notes. When a founder emails about a crisis, he says his agent retrieves prior conversations with that founder, examples from three portfolio companies that encountered similar problems, and what worked for them—before he finishes reading the message. The benefit is not merely finding a document. It is bringing relevant experience into the current decision so the agent can work with knowledge Tan already has. That shared context is what makes it feel more like a colleague than an assistant.

A company brain also preserves mistakes. Without curation, it becomes a garbage dump with excellent search: an agent can retrieve a stale fact confidently, while a bad skill file keeps reproducing a bad process. More memory does not fix either failure.

Memory needs hygiene as part of its operating model. Tan identifies three responsibilities:

• Provenance: Preserve the source of every fact so a claim can be traced.
• Contradiction checks: Detect when incoming information conflicts with existing knowledge and resolve the collision.
• Pruning: Give a human-plus-agent librarian explicit responsibility for maintaining the collection.

Treating the brain as production infrastructure makes accumulated knowledge useful over time. Treating it as a dumping ground produces confident errors that nobody can reconstruct.

The complementary discipline is to avoid one-off work. An agent’s first attempt may be disappointing, and asking it to fix the result is only the beginning. The learning loop should continue until the corrected procedure becomes reusable:

1. Give the agent a task in your chosen harness.
2. Inspect its output and correct what is unsatisfactory.
3. Once the result is good, turn the completed workflow into a skill.
4. Reuse that skill instead of teaching the same procedure again.

Tan calls the capture step “skillify it” and points listeners to an X post and a skill file for doing it in their own harness. His deliberately strict standard is that asking for the same thing twice means the learning was not captured the first time.

The timing matters: capture the process after the output is satisfactory, so the reusable skill includes the corrections that made the work good. An organization that does this accumulates capability each day. Without it, each new session can begin with the same organizational amnesia, regardless of model quality. “Model quality is rented,” as Tan puts it; the brain built from the organization’s experience is something it owns.

This produces a concrete company blueprint: a thin team, skills for repeatable work, a founder who remains in the code, a company library, and personal AI that can use it. Start capturing knowledge early enough that the library begins compounding in the first week. GBrain is offered as a free, MIT-licensed option, with alternatives explicitly welcome. The goal is an organization shaped around these capabilities from the beginning.

The infrastructure itself is also a product opportunity. Company brains, personal context, and the librarian that selects the right information remain territory to build in. Tan wants the underlying memory layer to be open in the way Linux is open, rather than making GBrain itself his commercial business. He invites founders to build a defining company around this need—and offers YC as a potential funder.

Adoption does not depend on choosing his repositories. Tan likens OpenClaw to a Ferrari and Codex to a dependable Honda. He estimates that Codex can do 90% of this, without defining an evaluation behind the percentage. The portable parts are the placement of computation, skills with clear responsibilities, a library with a librarian, and the habit of capturing completed work. Those principles can travel across stacks.

The ending moves from company design to the fear of job displacement. Tan acknowledges that fear, then argues that founders who multiply their teams’ capabilities can demonstrate a more abundant alternative. His formulation is direct: “Abundance is not a policy paper, it is shipped software.”

His closing example is a father using a research library to investigate his son’s rare epilepsy condition. Tan describes a repository of 80,000 Markdown files assembled for that research. Without a lab or grant, the father uses a laptop and a library to explore the limits of available knowledge about the condition. The architecture is the same one described for a company: a collection, a librarian, and the relevant material brought into context at the moment it is needed. The anecdote concerns research reach; it does not establish a treatment or medical outcome.

The same pattern expands the set of projects worth attempting: work that once seemed to require inaccessible expertise, codebases too buggy to repair, archives too large to read, and datasets too difficult to clean. Tan turns the warning against boiling the ocean into permission to attempt larger problems, describing the audience’s ability to fly as mechanical rather than metaphorical. The concrete challenge is to build both the AI-native company and the brain underneath it—the memory and compounding library that make the next company easier to build. He makes the challenge immediate—write the test and ship the skill—then returns to the battlefield companies already trying and urges the audience to build the one that does it best.