Last month I read through Y Combinator's Summer 2026 Requests for Startups, and one line from Aaron Epstein stuck with me: "The next trillion users on the internet won't be people, they'll be AI agents." That is not a metaphor anymore. The Spring 2026 batch was the most agent-heavy cohort YC has ever produced, and a big chunk of it was not building agents at all. It was building the stuff agents buy.
That reframes the whole opportunity. For two years everyone chased the agent itself. The quieter bet is that an agent is a new kind of customer: it needs to prove who it is, pay for things, read your docs, and get audited when it breaks. Below is a field guide to the seven layers founders are now selling into, roughly in the order an agent hits them when it tries to do real work.
1. Identity: give the agent a name and a number
An agent with no identity can't do much in the real world. It can't get a callback, can't be whitelisted, can't be held accountable. Startups like Inkbox are building the identity and communication layer directly: their pitch is to give each agent its own email, phone, iMessage, and internet address, with every interaction flowing back through them for context. AgentPhone takes the narrower slice, handing every agent a real phone number so it can call and text people and businesses.
The insight here is boring and correct: before an agent can transact, someone has to vouch for it. Identity is the root of trust, and everything downstream inherits it.
2. Payments: rails built for software, not wallets
Once an agent has identity, it needs to spend. Human payment rails assume a person tapping a card, and they fall apart when the buyer is a script running at 3am. Natural raised a $9.8M seed round to re-architect the stack for "agentic payments," letting software transact on behalf of businesses and users. Their early design partners sit in logistics, property management, procurement, healthcare, and construction, places where an agent can source, negotiate, and pay a vendor in real time.
The reason this is a real category and not a Stripe feature is authorization. A human payment is authorized by a human. An agent payment is only as safe as the identity behind it, which is why layers 1 and 2 keep showing up in the same pitch decks.
3. Software built for agents, not for clicks
Here is the part most people walk past. Agents are browsing the web and filling out CRMs designed for humans clicking buttons, and it is slow and brittle. Aaron Epstein's RFS entry argues that every major software category needs to be rebuilt for agents as first-class citizens: machine-readable interfaces (APIs, MCPs, CLIs) instead of forms and dashboards, plus documentation an agent can discover and sign up for without a human in the loop.
If you have ever wired up a tool for an agent, the difference is obvious. Compare a human-shaped flow with an agent-shaped one:
// Human-first: agent has to scrape a page and guess
async function bookHuman() {
// navigate, wait for render, find the button, hope the DOM didn't change
await page.click("#submit-booking");
}
// Agent-first: a declared tool with a typed contract
export const bookVendor = {
name: "book_vendor",
description: "Reserve a vendor slot and return a confirmation id",
input: { vendorId: "string", date: "ISO-8601", budgetUsd: "number" },
run: async ({ vendorId, date, budgetUsd }) => {
const res = await api.post("/bookings", { vendorId, date, budgetUsd });
return { confirmationId: res.id, status: res.status };
},
};
The second version is discoverable, typed, and stable. That is the whole product some of these startups are selling: a clean contract an agent can trust.
4. Sandboxes and runtimes: somewhere safe to run
An agent that writes and executes code needs a blast radius. You do not want it running a stray delete command on your production box because a prompt went sideways. That is why sandbox and harness startups keep appearing, with names like Runtime for isolated execution and a cluster of cloud runners for spinning agents up and tearing them down cheaply. E2B has written about how much of the recent YC agent work assumes ephemeral, disposable compute as the default rather than a long-lived server.
5. Memory: state that outlives a session
Context windows forget. A useful agent has to remember what it did yesterday, what it learned about your account, and what it is not allowed to touch. Memory systems are becoming their own layer, separate from the model, so that switching from one frontier model to another does not lobotomize the agent. This is where a lot of the "company brain" energy from the YC list lives too: pulling scattered knowledge into something an agent can query and act on.
6. Observability and compliance: watch what it did
Once agents are transacting and running code, you need to see inside them. A thick observability stack is forming for exactly this, with tools like Sazabi, Superlog, Armature, and BentoLabs aimed at tracing an agent's decisions step by step. According to a batch analysis of the recent YC cohort, a striking share of companies are building this plumbing (auth, testing, security, monitoring, billing) rather than the flashy agent on top.
| Human customer | Agent customer |
|---|---|
| Logs in with a password | Presents a signed identity |
| Reads a dashboard | Calls a typed API |
| Pays by card | Pays via authorized rails |
| You email support | You read its trace logs |
7. Silicon: chips for the loop, not the prompt
The deepest layer is hardware. Diana Hu's RFS entry makes the sharp point that most AI chips assume "prompt in, response out," while agents loop: calling tools, branching, backtracking, holding context across dozens of steps. Current GPUs hit only 30 to 40 percent of peak utilization on those bursty workloads. Her example: NVIDIA paid $20 billion for Groq because it saw this coming, and Google built TPU v7 for inference specifically, yet nobody is designing for the agent loop itself. That is a rare moment where knowing both chip architecture and how agents actually execute is worth a company.
What I'd actually build
If I were starting today, I would not build another agent. I would pick one layer here and make it the most boring, reliable dependency in the stack. Identity and payments are the two I would bet on first, because trust compounds: whoever an agent authenticates and pays through ends up sitting under everything else it does. The agent gold rush is loud. Selling shovels to the agents is the quiet trade, and this time the customer never sleeps.