Personal AGI and the Founder Under Your Own Power

Source: Y Combinator · Garry Tan · Video ID eRrc1pUY5oU · “Personal AGI Is How You Stay Under Your Own Power”

The next startup advantage is not waiting for a god-model to arrive in a data center. It is building a private operating system around your own context: agents, markdown skills, deterministic tools, and a memory you control.

Who Is Garry Tan?

Garry Tan is the president and CEO of Y Combinator, one of the few people with a live view into how hundreds of ambitious startups are actually changing their operating cadence under AI. His claim is not a futurist prediction from the cheap seats. It comes from watching YC founders, YC staff, and his own personal workflow move from autocomplete into agent-managed work.

His frame is unusually political for an AI productivity talk: intelligence should be owned, not rented. The frontier model may be a commodity, but the library, skills, and procedures that make it act like a fast version of you should remain under your control.

AGI Is Not a Sky Event. It Is Infrastructure in the Room.

Tan opens with Baruch Spinoza, the 23-year-old philosopher excommunicated by Amsterdam’s Sephardic Jewish community in 1656 for “evil opinions.” Spinoza was cursed, socially deleted, offered serious money to stay quiet, and, according to the story Tan tells, nearly stabbed for his ideas. He spent his days grinding lenses and his nights writing dangerous philosophy that had to be smuggled out after his death.

The point is not historical ornament. Spinoza’s heresy was that God was not a distant king on a throne but diffused through nature itself. Tan updates that heresy for AI: everyone is waiting for AGI as a singular announcement, a threshold crossed by a lab, a god in a data center. The thing worth noticing is already here, distributed through ordinary infrastructure: “a terminal window, a folder of markdown files, a job that finishes while you sleep.”

“AGI isn’t arriving as an event. It’s arriving diffused as your agent running on your context doing your work.”

That is Tan’s definition of personal AGI: general intelligence for one person. Not a chatbot subscription. Not a slightly better autocomplete. Not an assistant that knows your calendar but forgets everything else when the tab closes. Personal AGI runs on your infrastructure, reads from memory you own, executes procedures you wrote, and compounds every day you use it.

The New Equation: Rented Model, Owned Context, Personal Harness

Tan’s core equation is brutally practical:

The leverage is not mainly in the weights. Plenty of people have access to the same Claude, the same Codex, the same context-window headline number. The gap appears in what context the system receives, whether that context is relevant at the right step, and whether the procedure gets captured so the work compounds instead of evaporating.

Tan gives his own coding output as a receipt. In 2013, while building YC’s internal social network Bookface at night, he estimates he shipped about 14 useful lines of code a day, a figure he calls close to median programmer productivity. Now, while running YC full-time and handling a 5 p.m. kid pickup, he says the raw line count works out to roughly 400x his 2013 output. Even after penalizing for bloated scaffolding and self-flattery, he argues the floor is still around 8x, with much higher practical leverage in the middle of the range.

He is careful not to turn correlation into proof. But the YC portfolio evidence is suggestive: in the Winter 2025 batch, he says a quarter of companies had codebases that were 95% AI-generated, and those founders were not treating AI as autocomplete. They were treating it as a workforce.

Your Life Is a Library, Not a Prompt

The most useful part of Tan’s architecture begins with a cognitive constraint: humans can hold roughly seven things in working memory. Institutions, org charts, checklists, filing cabinets, standups, and status meetings are all prosthetics for that limit. An AI agent with a million-token context can hold around a thousand pages open at once and search across them in seconds. That is already a different operating regime.

But a thousand pages is also tiny compared with a life. Your emails, meetings, decisions, drafts, relationships, obligations, notes, mistakes, and reasons behind old choices are not three books. They are a library. The decisive question is not whether the model is smart. It is who decides which three books are open on the desk at the right moment.

Tan’s answer is the library plus the librarian. His personal system, built around GBrain, contains roughly 220,000 markdown pages: 25 years of diarized life, emails, meetings, notes, photos, drafts, and things he got wrong. The experience he wants is not search. It is a colleague that acts knowing everything he knows. A founder emails about a crisis, and before Tan finishes reading, the agent can pull previous conversations with that founder, similar portfolio-company crises, and the fixes that worked.

This is the shift from an inbox to a briefing. The agent does not merely sort email; it processes it with context. Before meetings, it prepares who he is meeting, what they discussed last time, what changed since, and what to ask next. Overnight research becomes a morning artifact. News is cross-referenced against stated interests before coffee.

Markdown Is Code, Skills Are Employees

The most democratizing claim in Tan’s talk is that markdown is code. If a smart intern could follow a page of English instructions, an agent can run it. A skill file is one capability, written down clearly enough for a language model to execute. The compiler is the model.

He gives a concrete skill example: when a meeting recording lands from Circleback, transcribe it with speaker labels; extract commitments, owners, and deadlines; cross-check every named person against the library; link their pages; file the summary and transcript in the right places; and flag contradictions without overwriting existing beliefs. That is a page of English, not a traditional program. But it is executable cognition.

At YC, Tan says media staff, event staff, finance team members, and people who do not live in terminals are building skill files and scheduled jobs. One finance person compiled roughly a hundred Excel workbooks into a single internal app with an agent. Her job was not to become a conventional programmer. It was to become a manager of agents.

This turns one founder into a small organization before incorporation. A skill file is an employee. A resolver is an org chart. A recurring job is an operating cadence. A founder with a folder of skills and a harness is not “using AI”; they are managing a workforce made of markdown.

Latent Space for Judgment, Deterministic Space for Reality

Tan’s clearest technical principle is the separation between latent computation and deterministic computation. Taste, judgment, interpretation, and reading what a human actually wants from a vague request belong in the model. Arithmetic, SQL, scheduling, reconciliation, and state tracking belong in deterministic code.

Confusing the two causes agent failures. Seating five people around a table can live in latent space. Producing custom schedules for 6,000 people at a YC event cannot. That requires markdown files calling databases and scripts. The model should compute the way humans compute: use judgment where judgment belongs, and use tools where exactness matters.

This is why the best personal AGI systems are not just prompt collections. They are hybrid operating systems: markdown skills, a browser or tools for acting on the world, databases for structured state, scripts for exact computation, and a memory layer that makes retrieval worth retrieving from.

The Five-Step Setup: One Shelf Before the Warehouse

Tan’s practical path is deliberately small. Nobody starts with 220,000 pages. First, build one shelf.

1. Pick a harness and run an agent on your own machine. Use the tool that fits: Hermes Agent, GBrain, Codex, Claude Code, OpenCode, or another agentic workflow. The concepts matter more than the brand.
2. Start your library this weekend. Create a folder of markdown files. Export notes and email if you can. Write one page for each project and each important person: what you are building together, what they care about, what you owe them, and what they said last time.
3. Write your first skill file. Pick a weekly task you hate: expense reports, meeting notes, status updates, competitor research. Explain the process in plain English, run it, correct the mistakes, and encode the exceptions.
4. Make it recurring. Schedule the job. The first time you wake up to work that completed while you slept, your unit of work changes from “what I can do today” to “what I can set in motion.”
5. Never do one-off work twice. If you ask for something twice, capture it. Skillify the process so each completed task makes the system smarter.

The expected curve is compounding, not instant magic. Week one feels like a toy. Week four, the flywheel starts to catch. By week twelve, Tan predicts a library that answers with your context, a dozen skill files handling dreaded workflows, and one or two tools other people start asking to borrow. In a startup context, that last phrase matters: tools built for an audience of one often reveal markets.

Own Your Skills or Your Job Becomes a Skill File

The political edge of Tan’s argument arrives with ownership. A skill file is not just a productivity document. It is judgment extracted from your head, written down, versioned, and made executable. That can be liberating or extractive depending on who controls the repo.

His fictional support engineer, Maya, spends two years teaching agents 40 skills: how to triage a P0 at 2 a.m., de-escalate a customer about to churn, and write postmortems that prevent repeats. If those files live in Maya’s repo, she carries compounded judgment to the next company or turns it into a startup. If they live only in the company’s repo under company policy, she leaves with nothing while the company continues running her cognition forever.

“Own your skills because if you don’t, your job becomes a skill file.”

That is why Tan returns to Spinoza’s phrase: under your own power. The same power of acting exists either way. The question is who commands it. Personal AGI is not just a convenience layer; it is a custody model for your cognitive work.

The Objections Worth Taking Seriously

“The models will make this obsolete.”

Tan’s reply is that better models make owned context more valuable, not less. When everyone’s engine is 1,000 horsepower, the race is won by the driver and the map. The weights are everyone’s. The library is yours.

“Isn’t this just RAG?”

His answer: yes, in the same way Postgres is “just B-trees.” Retrieval is a primitive. The product is the system around it: what gets written down, how it is enriched and linked, what becomes hot memory versus cold reference, and how contradictions are handled.

“What happens when your whole life leaks?”

Tan argues that consolidation is not what creates the risk; unmanaged sprawl already exists across clouds whose incentives are not yours. His preferred answer is custody: own the repo, own the keys, own the infrastructure. That does not eliminate the security problem. It makes it accountable to the person whose life is inside the system.

The Real Demo: A Brain for One Small Boy

The most moving example is not a startup. It is a friend whose son has a rare form of epilepsy. No lab, no grant, no permission: just a father, a laptop, and a library. He built a repo of 80,000 markdown files covering specialist visits, papers, seizure logs, and drug interactions, all indexed and cross-linked so that a new doctor’s idea can be checked against everything already tried.

That is personal AGI at its most precise: the right three books open at the right moment, aimed at one problem one person loves enough to pursue past normal limits. Not a benchmark. Not a demo reel. A private intelligence system built because nobody else was coming.

Key Lessons

• Do not wait for AGI as an announcement. Build around the agentic capabilities already available: memory, tools, skills, recurring jobs, and personal context.
• Your context is the moat. Models are rented and increasingly commoditized; your project history, customer understanding, and relationship memory are unique.
• Write procedures as assets. A clear markdown skill is reusable leverage. Repetition without capture is organizational amnesia.
• Use deterministic tools for deterministic work. Agents should call scripts, databases, APIs, and browsers instead of pretending language-model probability is arithmetic.
• Own the repo where your judgment compounds. Skill files are portable cognition only if you control them.

Why This Matters for Diffie

Anand’s challenge with Diffie is not merely building an AI browser testing tool. It is building a repeatable GTM motion around a narrow ICP while the market is still learning what agentic QA should feel like. Tan’s talk maps directly onto that problem because Diffie’s advantage will come from owning the context around frontend engineering pain, not from assuming model access is defensible.

The immediate move is to treat Diffie’s ICP work as a personal AGI system, not a spreadsheet. Every customer conversation, failed outbound angle, GitHub issue pattern, QA workflow, frontend stack detail, objection, demo reaction, and “why now” signal should become part of a Diffie library. The question before each outbound sequence should be: which three books need to be open on the desk for this prospect?

Diffie should also skillify its own GTM. If an email to a React-heavy seed-stage startup gets a useful reply, capture why. If a demo lands better when framed as “browser testing for fast-moving frontend teams” instead of generic QA automation, write that as a skill. If a customer’s flaky Playwright suite reveals a repeated pain pattern, turn the diagnosis into a reusable agent procedure. The goal is not just to run more outbound. It is to make every outbound cycle improve the next one.

There is a product lesson too. Diffie can become more than an AI tester if it remembers the frontend team’s world: the app’s flows, recent PRs, component conventions, flaky areas, design-system rules, release cadence, and prior regressions. A generic browser agent can click around. A Diffie agent with a customer-owned library can behave like a QA teammate who knows what broke last time, what matters this release, and where the team’s risk actually lives.

For an ex-YC technical founder, the warning is equally important: do not let Diffie’s core judgment compound only inside rented tools or ephemeral chats. Keep the ICP notes, testing heuristics, demo playbooks, and customer-specific learnings in repos and databases you control. Personal AGI is not a side project here. It is the operating layer for building Diffie under your own power.