How to Build Superintelligence Inside Your Company

In Brief

In a new episode of the Lightcone podcast, Y Combinator talks with Pete Koomen about how YC built its own AI infrastructure from the ground up. The conversation isn't about which AI tools to buy. It's about something more fundamental:

How do you turn AI into the operating system your company actually runs on?

The old idea is that AI is an assistant alongside the work. You add a chatbot here, a writing helper there, maybe a Copilot in the dev environment. Useful, but not transformative.

The new idea is that AI is a working layer beneath the whole organization. The agent reads company data, uses company tools, learns from company decisions, and improves over time. AI becomes more like electricity or the internet: infrastructure everything else runs through.

From copilot to operating system

Most companies use AI in a fairly shallow way today. A summary here, a chatbot there, maybe some email automation. It's not wrong, but it doesn't use what the models can actually do.

YC describes a different approach. AI isn't an add-on. It's a working layer. The agent has access to the company's context, can use internal tools, and learns from past work. A new hire can ask the agent how things work at this particular company, and the agent answers from real knowledge of the history, routines, and customers.

The difference is large:

This isn't just efficiency. It's a new organizational shape. Pete Koomen calls it "the personal computer moment for AI." We've gone from AI controlled centrally by a few players to every company being able to build its own agent platform.

It started with a finance problem

YC didn't begin with an abstract strategy about superintelligence. They began with a concrete problem: finance work required a lot of back-and-forth between domain experts and developers.

The old process looked roughly like this:

1. Finance explains a process to developers.
2. Developers try to understand the process.
3. Developers build custom software.
4. Finance tests it. Something is missing.
5. The process repeats.

Pete Koomen describes this as inefficient. The idea became: what if finance could describe their workflows in English, and the agents could use internal tools to do the work? The goal was to remove developers from this heavy translation loop and let finance "code workflows as English with prompts."

Before, domain experts had to translate their knowledge to developers, who translated it to code. Now part of that translation can go via the AI agent directly. It doesn't mean code disappears. It means code becomes more like a set of safe, reusable tools the agent can call.

SQL access was the first breakthrough

The first big breakthrough came when the agents were allowed to run read-only SQL queries against the database. Read-only means the agent can read data but not change it.

This sounds almost too simple. But that's the whole point.

If the agent can read the database and understand the structure, it can answer questions that previously required hours of manual SQL work. An example from the conversation: "Show me all investors who invested in a space-related company in the last four batches."

Because everything important at YC lived in one Postgres database, the agent could answer arbitrary questions about the business. A non-technical but smart person in finance could ask real questions of the data without an engineering background.

The important takeaway is simple:

Gather important context and make it readable to the agent.

Don't give the agent dangerous write access on day one. Start read-only. Let it read. Let it explain. Let it help employees ask better questions.

One database to rule them all

YC had an underrated advantage: nearly everything important lived in one database. Companies, founders, financial transactions, notes, and internal CRM data were all in one place. Many other companies have this scattered across Slack, Notion, Salesforce, HubSpot, Excel, Google Drive, Jira, and email.

This is an insight many people miss:

The AI agent isn't only limited by how smart the model is. It's limited by how messy the organization's knowledge is.

Think of the agent as a new hire. If everything is in different binders, private folders, and old emails, the new hire spends months figuring out how things connect. If everything is in a tidy library with a map and an index, learning goes much faster.

What matters most isn't necessarily one physical database, but one coherent context layer, a layer that gathers relevant knowledge so AI can use it. It can be a large shared data source (data lake), a connected knowledge network (knowledge graph), an internal wiki, or a search system built for AI. The point is that the agent can reach the truth in one place.

Companies that want to become AI-native should ask:

• Which systems contain the truth?
• Which data is duplicated?
• Which data is locked inside SaaS tools?
• Which data can safely be exposed read-only?
• Which concepts need to be standardized?

AI transformation often doesn't start with the model. It starts with the information architecture.

When questions get cheaper, people ask more of them

A key point in the conversation is economic. The agents didn't just make it easier to answer questions. They made people ask more, and more complex, questions.

Previously, a question to the data team might take hours or days. So you only asked when it really mattered. When the agent can help immediately, you ask much more.

This is Jevons paradox applied to knowledge work. Jevons paradox is an economic principle: when something becomes more efficient to use, total use can rise instead of fall.

• When analysis gets cheaper, you get more analysis.
• When programming gets cheaper, you get more software.
• When internal knowledge gets easier to retrieve, more decisions actually rely on internal knowledge.

AI lowers the transaction cost of information work. That can change organizational culture. A high-friction organization makes fewer data-driven decisions. A low-friction one dares to test more hypotheses.

But it requires maturity. More questions don't automatically mean better decisions. The agent has to show sources, explain uncertainty, and make it easy to check answers.

Tool registry: the toolbox the agent needs

An AI agent without tools is like a smart colleague without an access card, calendar, database, or keyboard. It can talk, but not do much.

YC built an internal tool registry, that is, a catalog of tools the agent can use. They started with about 20 tools. Over time it grew to more than 350, with different teams adding their own tools for finance, office hours, events, and other important processes.

This is the core of agentic work. The difference is like having a consultant who can only give advice, versus a colleague who can actually log into systems, pull numbers, update status, and start processes.

A tool registry describes which functions the agent can use, which parameters they take, which permissions are required, and what they return. For example:

book_journal_entry(amount, account, date, memo)
get_company(company_id)
list_founders(batch)
schedule_office_hours(partner_id, founder_id)
query_readonly_sql(sql)

The agent picks the right tool based on the user's goal and the context. For a company, this is probably more important than buying "the best model." Build a small, safe tool catalog:

• read customer data,
• search internal documents,
• fetch order status,
• create proposals,
• draft reports,
• summarize conversations,
• hand off to human approval.

Start read-only. Add write actions with approval. Build trust gradually.

A key piece of infrastructure here is MCP, the Model Context Protocol. It's an open standard for connecting AI applications to external systems like databases, files, tools, and workflows. Anthropic introduced MCP as a universal connector between AI and data sources, and the official documentation compares it to a USB-C port for AI.

Skills: the organization's best ways of working, made reusable

When someone in the company finds a good way of doing something, that way should become reusable for everyone. YC calls this a skill: a reusable instruction or way of working for an agent.

If an experienced salesperson always writes good follow-up emails after customer meetings, you can create a skill:

"Write a follow-up after a customer meeting with a clear summary, next steps, responsible person, deadline, and a friendly tone."

Over time the agent learns from good examples and improves the skill. One person's experience becomes available to many.

The conversation explains "skillify" as a meta-skill: when the agent has done something useful, you can turn the approach into a skill. Then you check whether the new skill overlaps with existing ones. The goal is for the skill registry to be DRY (Don't Repeat Yourself, meaning don't create ten nearly identical things) and MECE (Mutually Exclusive, Collectively Exhaustive, meaning categories that don't overlap unnecessarily but cover the whole).

A skill can contain:

• purpose,
• when to use it,
• what input the agent needs,
• step-by-step process,
• examples,
• mistakes to avoid,
• evaluation criteria,
• which tools it can use.

This is a middle layer between a plain prompt and full program code. Companies should start collecting their best ways of working as skills: "This is how we summarize customer meetings," "This is how we evaluate an inbound lead," "This is how we write a project status," "This is how we quality-check a blog post."

This is knowledge management, but with AI as an active user of the knowledge. Skills make tacit knowledge operational. What used to sit only in good people's heads can become a shared working tool.

Dream cycle: the agent that improves itself overnight

The most exciting part of the conversation may be the dream cycle, a periodic process where the agent analyzes past work and updates memory, skills, or context.

YC has a general agent that reads through every employee's agent conversations each night. It looks for things it could have done better and finds context that would have made it more effective next time. The result is that skills gradually improve without anyone sitting and editing them.

Many AI systems start fresh every time. They forget. They don't learn from how the organization actually uses them. The dream cycle tries to make the AI system behave more like an organization that learns over time.

An example from the conversation is YC's "two-sentence description" skill. Partners have long experience helping founders explain what their company does in two sentences. When meetings and feedback are transcribed, the agent can use that material to improve the skill. After one round of such learning, the skill became noticeably better.

A dream cycle can do several things:

1. Read conversation logs.
2. Find unsuccessful or ineffective responses.
3. Extract missing context.
4. Propose improvements to skills.
5. Update internal wiki or knowledge base.
6. Create evaluation tasks.
7. Flag things that require human approval.

This shouldn't be completely uncontrolled. Self-improvement without review can also reinforce mistakes. The best version combines automatic suggestions with human oversight.

A small example with big meaning: the two-sentence pitch

"Two-sentence description" sounds like a small thing, but it shows the mechanism behind superintelligence inside an organization.

YC uses a short explanation of what a company does and why it's interesting. Two sentences, natural language. Pete Koomen describes this as hard because founders often have perfect context in their own heads but can't transfer it to others.

A bad pitch:

We use AI to optimize workflows for modern teams.

A better pitch:

We help accounting firms catch errors in their entries before they reach the client. The system reads entries, emails, and past cases, and suggests what the accountant should check first.

The second is better because the reader understands who it's for, what the problem is, what the product does, and why it might be valuable.

YC has made this a skill. First, a partner wrote a prompt based on their own experience. Later, the agent was given transcripts of meetings where partners coached founders. The agent then learned from real conversations, not just from an instruction.

Every company has its own "two-sentence pitch" tasks:

• How do we explain our product?
• How do we write good customer replies?
• How do we evaluate a candidate?
• How do we explain a technical issue to a customer?
• How do we write a strong board update?

If you can make one such task better and more reusable, you can do the same with a hundred others.

Where the superintelligence actually comes from

We need to be precise here. YC uses the word "superintelligence" broadly. They don't necessarily mean a science fiction machine smarter than every human at everything. They describe an organization where human experience, data, tools, and AI agent work reinforce each other.

The mechanism is a snowball effect:

Over time the organization can reach a shared skill level higher than what individuals would reach in isolation. Superintelligence inside companies isn't one magic button. It's many small learning loops connected together.

This requires an architecture with data access, agent loops, tool registry, skill registry, memory, observability, feedback, access control, evaluation systems, and human review. OpenAI describes an agent loop in Codex as an interplay between the user, the model, and the tools the model uses to do real software development work. The same principle can carry over from code to other work in an organization.

Logging everything: powerful, but risky

YC says you need to start storing artifacts (meetings, conversations, decisions) because they can be used to improve work across the organization.

At YC, agent conversations were visible to all full-time employees by default, partly because people learned from seeing how others used the agents. It also created openness and shared learning.

This is exciting, but not universally transferable.

YC is a relatively small, trust-based organization with high technological maturity. A larger company with sensitive personal data, customer data, regulatory requirements, or unions has to be more careful.

A good system has to distinguish between:

• publicly internal knowledge,
• team knowledge,
• personal knowledge,
• customer-confidential information,
• legally sensitive information,
• security-critical information.

MCP and similar standards make it easier to connect AI to external systems, but they don't automatically solve governance. The company still has to define its own permissions, logging, and policies.

A practical starting model:

1. Start with non-sensitive documents.
2. Give read-only access.
3. Log every agent action.
4. Show sources in answers.
5. Use human approval for actions.
6. Separate personal, team, and organizational memory.
7. Have clear rules for meeting recordings and consent.

Horseless carriages: why many AI products are built wrong

Pete Koomen wrote the essay "AI Horseless Carriages" before this conversation, and it's discussed in the podcast too. The point is that many AI products copy old software logic instead of rethinking around AI.

The first cars looked like carriages without horses. People didn't yet know what a car could really be. In the same way, many AI products look like old apps with a small "write with AI" button glued on top.

Traditional software is form-driven:

Agentic software is more goal-driven:

When you evaluate an AI product, ask:

• Can I give it my own instructions?
• Can it use my data?
• Can it learn my preferences?
• Can it use tools?
• Can it improve over time?
• Can I view and change how it works?

If the answer is no, it might just be a horseless carriage.

Chat is a surprisingly strong interface

Many people thought chat was just a temporary AI interface. In the conversation, YC argues that chat can actually be a very good interface for agent work.

The argument is that chat is close to human language, and language is our best tool for expressing thoughts, goals, nuance, and uncertainty. Traditional interfaces force you into boxes: fields, dropdowns, buttons, fixed dashboards. Chat lets you say:

"Find the three most important customers who are likely unhappy, explain why, and draft a follow-up plan."

It's hard to build a button for every such need.

Future internal tools may become less dashboard-focused and more agent-focused. You don't necessarily ask "which dashboard shows this?". You ask the agent, and the agent generates the right view or analysis. This is often called just-in-time software: views and tools created exactly when you need them.

Centralized or personal AI

Toward the end the conversation turns philosophical. Should AI be controlled by a few large players, or should people and companies own, change, and run their own agents?

Pete Koomen compares today's AI moment to the personal computer revolution. Before the PC, computing power was centralized and controlled by institutions. The PC made computing personal, experimental, and democratic.

He fears an AI future where a few companies control the models, the prompts, the tools, and the user experience. The alternative is a future where people and companies can control their own prompts, their own data sources, and their own agent workflows. Garry Tan has published an open project called gbrain, a self-hosted "brain layer" for agents with Postgres, markdown, skills, and agent memory.

For many organizations this is a strategic question:

• Where does the data live?
• Who controls the prompts?
• Can the system be improved locally?
• Can it be moved if the vendor changes?
• Can it be audited?
• Can the user understand how it works?

The AI revolution can go centralized or personal. The choices made now will shape how future work feels.

How a company can start

Don't build "superintelligence" first. Build one useful learning loop.

A good first project can be:

• support summaries,
• meeting summaries,
• CRM queries,
• internal onboarding,
• customer analysis,
• report drafts,
• pitch improvement,
• code review,
• project status.

The important thing is that the project has to be concrete enough to evaluate. If it works, expand.

In summary

The key thing from this conversation isn't that YC has 350 tools or one big Postgres database. It's the underlying principle:

An organization becomes AI-native when it makes knowledge, tools, and learning available to agents in a safe and systematic way.

That takes more than a chatbot. It takes a unified context, safe data access, a tool registry, skills, logging, feedback loops, a culture of sharing, and clear boundaries for security and privacy.

The simple version is that AI has to be allowed into the company's library, not stand outside the door and guess what's in the books.

The more technical version is that future organizations will build internal agent platforms where models, tools, data, memory, skills, and human feedback are connected into learning systems.

That's where the superintelligence inside a company begins. Not as one big machine, but as a thousand small improvement loops that make everyone a little better, every day.

Glossary

Sources and resources