What internal infrastructure do you need to run AI agents across a whole company?

You need three pieces. First, one shared context store where your company's important data lives, shaped so an agent can query it. Second, a tool registry, a single library of named tools any agent can call (run a report, book an entry, manage an event), kept DRY so capabilities are not duplicated. Third, a self-improvement loop that reads how agents were used and upgrades the skills automatically. This is the stack YC partner Pete Koomen built inside Y Combinator, and most companies start with the context store because it delivers value fastest.

What is a shared context database and why do AI agents need one?

A shared context database is a single store that holds the data a company runs on (customers, finances, internal notes) in one place instead of scattered across many SaaS tools. Agents need it because their usefulness scales with the context they can see. YC runs on one Postgres database, and giving an agent read access to it let non-technical staff answer complex questions in seconds. In practice you consolidate the scattered data first, then shape it for agent retrieval rather than for normalized storage.

How does an internal tool registry let AI agents act inside a company?

A tool registry is a shared library of functions an agent can call to do real work, such as pulling a report, posting a journal entry, or scheduling office hours. It is what turns a chatbot into a coworker, because the agent can act, not just answer. At YC the registry grew past 350 tools, with every team adding its own and exposing them to both internal agents and the coding agents on people's laptops. Keeping it DRY and non-overlapping, one tool with parameters instead of ten near-duplicates, is what keeps it usable as it grows.

How do you keep internal AI agents secure when they have broad data access?

Keep the security basics even as you widen access: scope each agent to the narrowest read access that does the job, keep secrets out of prompts, and log what agents touch. YC adds an unusual control on top, making agent conversations visible to the whole team by default, broadcast into a shared channel, so people self-police what they ask agents to do and new employees learn by example. That transparency works only inside a small, high-trust team, not across customer data or a large organization, so treat it as a complement to technical controls, not a replacement.

Internal AI infrastructure for startups

Most founders still use AI as a copilot, a smart autocomplete bolted onto the side of the real work. YC partner Pete Koomen thinks that framing is already dated. On YC's Lightcone podcast he walked through the internal agent infrastructure he has spent the past year building inside Y Combinator, and the lesson underneath it is simple: the win is not a tool, it is a layer you build once and run everything on top of.

Koomen co-founded Optimizely and now builds YC's internal tooling. The phrase he and Garry Tan use is building superintelligence inside a company, and the recipe is less mystical than it sounds. You put the context in one place, you give agents the tools to act on it, and you let the system improve itself. This is the plumbing beneath the AI-native company: not the org chart, the actual stack. Here are the five pieces of internal AI infrastructure a startup can build for itself, and the one place a security-minded founder should slow down.

Put all your context in one place

YC has always run on its own software, and all of it sits on one Postgres database: every company they funded, every founder, every financial transaction, every note a partner leaves in the internal CRM. That turned out to be a structural advantage the moment agents arrived.

The first unlock was small and looked almost too simple. They gave an agent read-only access to that database. Suddenly a non-technical person on the finance team could ask, in plain English, "show me every investor who backed a space-related company in the last four batches," and get an answer in seconds. In the old world that question was a few hours of SQL, so unless it really mattered, nobody asked it. Koomen's point is that putting context in one place does not just make questions easier to answer, it makes you ask far more of them, and bigger ones. It is the Jevons paradox aimed at curiosity.

Most companies do not have this. Their truth is scattered across a dozen SaaS tools. The fix is to bring it into one store and reshape it for the way agents actually read: denormalized, retrieval-friendly, closer to one big table than a tidy relational schema. A coding agent is more effective inside a single monorepo than across ten services, and the same holds for a company. Get the context into one place first.

Build a tool registry, not one-off agents

The core of YC's system is almost boring: an agent loop, a model router, and a tool registry. The registry is where the value lives, because tools are what turn a clever chatbot into something that does real work.

They started with about 20 tools, including that read-only SQL query. Today there are more than 350, and every team keeps adding their own: book a journal entry, manage office hours, run an event. The same tools are exposed to both the internal agents and the coding agents running on each person's laptop, so a capability built once is available everywhere.

The discipline that keeps 350 tools usable is borrowed from two old ideas. Keep them DRY (do not repeat yourself) and MECE (mutually exclusive, collectively exhaustive). Ten skills that do nearly the same thing is a mess; one tool with parameters is the goal. Tan runs a "check resolvable" step that audits each new tool against the existing set so the registry stays clean. Models, it turns out, already understand DRY and MECE, so a tidy registry makes them noticeably more effective.

Let your skills improve themselves

The progression Koomen describes is one most heavy AI users recognize. First you write system prompts by hand. Then you package them as skills. Then you stop writing them yourself and have the agent write and improve them for you.

YC runs this on a schedule. A general agent reads through every agent conversation from the day, looks for what it could have done better and what context would have helped, and proposes improvements to the relevant skills overnight. The result compounds.

The example that makes it concrete is YC's "two sentence description," the short pitch a founder uses to explain what their company does and why it matters. Partners have practiced that craft for years. One partner wrote it up as a skill. Then a couple of partners ran a group session where founders tried their own versions and got live feedback, recorded the whole thing, and handed the transcript back to the agent with one instruction: use what you just learned to improve the skill. It got better. The verdict on the panel was blunt: the skill is now better at it than the partners are. Do that on one task and you have a sharper tool. Do it on everything a company does, and the aggregate is what they mean by superintelligence.

Transparency is the security model

Here is where I slow down as a CISSP, because this is the part that is both the most powerful and the easiest to copy wrong.

Agents are at their best when they have broad access to context, which runs straight into how most security teams think. Jared Friedman, one of the YC partners, told the story of giving agents complete read access to the production database, feeling like he was breaking the rules, and pushing it out late at night. It worked. That is the seductive part, and it is also exactly the move a security person should not make blindly.

YC's actual control is the interesting part: agent conversations are public by default to every full-time employee, broadcast into a shared channel. That choice does two things at once. New people learn to use agents by watching how the best people use them, which ramps them up far faster than waiting on a busy partner. And public-by-default acts as a social control, because when everyone can see what you asked an agent to do, the system polices itself. It let YC be more lenient on internal restrictions inside a small, high-trust team.

The honest caveat is that transparency is a control, not a substitute for the technical ones, and it does not scale past a high-trust group or anywhere near customer data. If you copy this, copy the discipline, not just the openness:

Least privilege still applies to agents. Give each one the narrowest read scope that does the job, not a blanket admin token.
Keep secrets out of the context window. An API key in a prompt is an API key in a log.
Log and review what agents read and do, from day one, so the audit trail exists before you need it.

Trust-by-default and an egalitarian setup are real requirements for this to work, and they are easiest at a startup. They are not a security policy on their own. The founders building agents into regulated workflows already know this, which is the whole reason the companies on our AI for security hub exist.

The cost is a one-time time warp

The part founders flinch at is the bill. Koomen is direct: doing this means being willing to spend 10,000 to 100,000 dollars a year on tokens, plus the work of building the skills and operating in the open. His argument for why it is worth it is the most useful idea in the episode. Spending that now lets you live in 2028. What costs 100,000 dollars this year will cost 10,000 next year and a couple hundred dollars the year after, because inference keeps getting cheaper. So there is a narrow, one-time window where paying up buys you a structural lead over every incumbent and most startups, who are still moving information by hand. It rhymes with the companies that bought a computer for every employee in the 1990s while their competitors waited.

For a founder the takeaway is to treat tokens like a capital expense, not a cost to minimize. The lead is temporary, which is exactly why it is worth buying while it is still for sale.

Software is becoming just-in-time

This all traces back to Koomen's essay "AI Horseless Carriages", which argued that most AI products bolt a little intelligence inside a lot of fixed software and hide the prompt from the user, the way early cars looked like carriages without the horse. The inversion he is building toward is the opposite: agents wrapping deterministic tools, not deterministic software wrapping an agent. In that world the interface is mostly chat, and the software is built just in time, a single-purpose view spun up for the moment you need it and thrown away after. The tool registry is what makes that possible, because the agent has real capabilities to compose instead of a fixed set of screens.

This is the org-scale version of running AI agents like an engineering team. The single-player version makes one founder fast. The infrastructure here makes a whole company fast.

What to do this week

Put your context in one place. Pick the three systems that hold your company's truth and get them into one store an agent can query, shaped for retrieval rather than for a tidy schema.
Start a tool registry, not a pile of bots. Wrap each repeated job as one named tool with parameters, and keep it DRY so you have one tool, not ten that overlap.
Turn on a nightly improvement loop. Have an agent read the day's agent transcripts and propose one concrete skill or prompt improvement.
Make agent work visible by default. Broadcast agent runs into a shared channel so the team learns by watching, inside a group you actually trust.
Set the access and secrets rules first. Scope each agent's read access, keep credentials out of prompts, and log what agents touch before you widen anything.
Budget for tokens like a capital expense. Decide what you will spend to live in 2028, and treat it as a one-time lead rather than waste.

The real claim is that internal AI infrastructure is not a product you buy, it is a layer you assemble from context, tools, and self-improving skills, governed by trust you can only run at a certain scale. The plumbing is unglamorous. The compounding is not.

If you want that layer as a system instead of a pile of notes, that is what we teach in the AI Operating System for Startups. For the org structure that sits on top of it, see how to build an AI-native company. For the aggressive-adoption mindset that pays for the tokens, see why a startup CEO went all in on AI.

Sources

Inside YC's AI Playbook on The Lightcone, the episode this article distills, with YC's Pete Koomen and Garry Tan.
Pete Koomen: YC profile. He co-founded Optimizely and wrote the essay "AI Horseless Carriages".
Garry Tan: YC profile, YC's CEO and the episode's host.