Transcription
Right now, a new infrastructure stack is being assembled in public for AI, and most of us aren't paying attention to it. It's got billions and billions of capital behind it. It's not software. It's not agents. It's the layer underneath both of them. It's the layer that lets agents actually do things in the world. And the problem right now is that almost nobody on the outside of that category can figure out what's real and what's hype. And this video is all about disentangling that, giving you a way to understand this new infrastructure category for agents that's being created and helping you make sense of what the big pieces of this category are and how you can think about what's needed for your agents and your deployments.
I want to be clear, we have seen this movie before. In fact, we've seen it twice before. Between 2006 and 2010, computing infrastructure shifted from on-premise servers into the cloud. Uh, EC2, S3, Lambda, all of these like cloud compute interfaces. The builders who understood the new stack started companies that are now dominant like AWS. And then between 2012 and 2016, we saw the movie again. Monolithic applications gave way very rapidly into decomposed applications with APIs in between them and what we call our microservices architecture.
Now we're watching yet another shift. We're moving from human-first tools to agent-first primitives. I believe it is foundational in the same way that moving to cloud was foundational. So the new customer for infrastructure is going to be the agent in the same way that the new customer for compute became the enterprise renting compute from data centers in the 2010s. We are talking about a shift at least as big as cloud when we're moving to agentic primitives. But because it's so new and because most of the startups are so small, it's been really, really hard to distinguish the noise in the space from the actual signal. And so I'm going to break the category down for you here.
And first, a word of warning. I love Legos. You know that. These are not the same thing as Lego bricks for agents. I want them to be. That's the hope. They'll sell you as Lego bricks for agents, but right now, you don't have the same degree of composability and predictability that you would have in a Lego analogy. These are not all bricks with the same size knobs that you can just slap together and they're going to make a little wall. Right now, it's as if you have Legos and wooden blocks and they're all marketing themselves as Legos. You don't know which is which and you don't know how to snap them together. And that is one of the biggest problems in the space right now.
I think a more reliable analogy for where we're at in the space today is something like system calls. Agents need defined, reliable interfaces that help them figure out identity, that help them figure out compute, that help them figure out memory and persistence and communication and payments. And the companies that are building those system calls are essentially building the operating system that agents will need to do their work in the new economy. And I want to go through and decompose that stack and give you layer by layer what agents look like and where the agent primitives are going in this economy.
Number one, layer one, compute and sandboxing. This one is perhaps the most production-ready in the stack. It's already bearing the load for agents. And what's the premise? It's really simple. The agent needs somewhere safe to run code. It should not run on your laptop. It should not run in production. And it should not run unsupervised. It needs isolated, sandboxed, auditable execution. I, I think that this layer has the most mature competition at this point. Right. E2B has roughly $32 million in funding. It uses Firecracker microVMs. It has the same tech as AWS Lambda has. And it's intended to give each agent a session with its own dedicated kernel. But it's not the only one, right? Daytona raised a $24 million Series A recently and took a different architectural bet. They have Docker containers with a shared kernel and it's optimized for speed. I think they claim a 90-millisecond cold start, which is insanely fast, and also a persistent state. Uh, Modal is a startup that targets GPU-heavy workloads. Browserbase is valued at $300 billion after the Series B and it focuses on headless browser automation, giving agents the ability to interact with web pages as if they were human users. And then there are newer entrants in the space. Uh, Alibaba's Open Sandbox is a good example. The interesting split in this space is really philosophical: are you going to be ephemeral with your agents or are you going to be persistent? E2B treats sandboxes as disposable; you spin one up, you run code, you spin it down. And Sprites treats these spaces as long-lived and they assume that your agent can install dependencies, that it can create files, and that your agent, in some sense, will come back later. They assume a degree of agentic persistence. This is not a style preference. This is not optional for you to think about. This is an architectural bet from these startups on how long agent sessions in the new economy will run and whether state matters for those agent sessions. Both camps will probably survive because the agent economy is going to be that big. But you're going to have to think about what your workloads need. If you want to look at this part of the stack, this is a really high durability component, right? Whatever you want to bet on, whether you want to bet on persistent agents or disposable agents, your agents need safe spaces to run code. And it totally makes sense that they're going to have virtual boxes to do it on. There will be a lot more startups working to solve this problem over the next year or so. But this is an area where it's relatively mature now and you have multiple options and you need to think about which one you want to use if you want to deploy your agents in any kind of computing environment that is virtual.
What is layer two on top of the compute piece? Layer two is identity and communication. This is in a weird space. It's transitional and I think that we need to be thoughtful about what we consider basic in this space. So right now, we know that an agent needs to exist on the internet as an entity. It needs to send and receive messages of some sort. It needs to authenticate with services. It needs to hold some kind of verifiable identity that other systems can recognize. And today, one of the pragmatic answers to that is, well, the agent needs an email address. So Agent Mail raised a $6 million seed round from General Catalyst a couple of weeks ago. Uh, and Paul Graham and HubSpot CTO Dharmesh Shah are both angels on Agent Mail. The API lets you programmatically create email inboxes for agents. Real addresses, full threading, attachments, labels, search. The onboarding API even lets agents sign themselves up. So far so good. The thesis is very sharp. Agent Mail CEO frames email not as a communication tool, but as a fundamental identity layer. And he's not the only one, by the way. There are like half a dozen startups in the space going after email. Email is today a universal key to the internet. Every SaaS service needs one at signup. Every verification flow sends codes to it. If you give an agent an email address, the idea goes, you're essentially giving it an identity. But what if that is a shim? Email works today because it's everywhere, not because it's the right protocol for agents, but because it's the right protocol for humans who built the internet. And right now, we all have problems with email as humans, right? Threading is brittle. We have rate limits designed to prevent spam and automated agents in particular. We have a signal-to-noise ratio that's terrible for agent context windows. The real need underneath the presenting need for email is a need to give an agent identity and communication protocols, something that doesn't require pretending to be human. And multiple teams are working on this, right? You have, uh, on-chain agent identity options. You have dedicated Ato communication standards. You have MCP-based service discovery. Nothing has a defined right to win yet in this space. If you are in this space, be thoughtful about what an agent-native protocol looks like. Now, by the way, I am not the person to bet against email. Email has been famously cockroach-like in its ability to survive lots and lots of revolutions. It just seems to stick around. So, I'm not the one to say agents will never use email. But you should be aware if you're betting on agent email that you're making a pragmatic bet, not necessarily an architectural bet.
Okay. So, agents need compute. That's a layer that's kind of mature. Agents need identity and communication. That one's really in flux. Agents need memory and statefulness. This is early. This is real. And the platform risk is just as real. Now, the need is clear, right? Agents need to be able to remember what happened in many cases, not just within a session, but across many sessions, many tasks, many days. Uh, Memzero is the clear leader here. They've raised $24 million, hit 41,000 some GitHub stars and 14 million downloads and were selected by AWS as the exclusive memory provider for its Agent SDK. So, of course, their API has done very well. Call volume has gone up fivefold, the whole thing. What Memzero gets right is the insight that memory isn't there to save the conversation, which is the old chat way of doing things. It's actually that memory is an act of active curation. So their system will store important information. It will, it will, it will deliberately forget outdated conflicting details and only recall relevant context when you are inferring something with an LLM query. So the architecture is very much a hybrid data store to reflect that. It has a knowledge graph. It has a vector database. And it also has a key-value store. And those three different formats allow Memzero to treat memory as managed infrastructure, not just a feature bolted onto the model. And you get better results. Right? On the LLaMA benchmark, they outperform OpenAI's built-in memory by 26% on accuracy with 91% faster latency and 90% reduced token usage. It's a, it's a clear win. But keep in mind that every frontier lab is obsessed with building memory into its models. OpenAI already has big investments in long-term memory and is going to continue working on it. Anthropic is building memory into Claude. If memory becomes a model-level feature that the labs build in the same way that search got sort of built into ChatGPT and not as a separate feature, then all of these standalone memory companies are at risk because the model makers can just grab them.
Now, if you're on Memzero's side of things, the counter-thesis is portability, right? And we've talked about this: the idea that no one should own your memory. That's a really important concept, that you should be able to own your memory. I've talked about this in relation to the frontier project that OpenAI is doing with AWS. Do you feel confident with your context layer, which is a step above memory, being something that a company owns and not you own? So I think the question here is really, it's a question of which thesis wins, and I think it's a very uncertain outlook. Will this be a situation where the market decides that they want a memory solution that does not belong to a hyperscaler? Or is it a situation where the convenience the hyperscalers offer is so compelling that the market as a whole just decides to go with it and throw memory at the hyperscalers and say, "You can solve the problem." And we look back in two years and we see companies like Memzero and we say, "Yeah, they didn't last because they just weren't convenient enough." I don't know. It feels a little bit like a coin flip, and I think we get to shape that by what we demand.
Okay, so we've talked about compute and sandboxes. We've talked about identity and communication. We've talked about agent memory and state. Let's talk about tools and integration for agents. This one is growing explosively quickly as a layer and it solves real and immediate pain points. Any agent needs to interact with tools to do its work, right? Whether it's interacting with Slack or with Jira or with Salesforce or with GitHub or with Google Workspace, and those are all integrations, or with basic primitives like it's running Unix or it's running Python or whatever it is. And you have to have those tools if you're going to do work at an enterprise level, and you have to have those integrations. Anything that makes that easier is going to coin. And so Compose with $29 million in funding from Lightspeed provides a managed integration layer for agents, right? Provides authentication handling without complicated OAuth flows. It provides pre-built connectors to a couple of hundred solutions and it provides observability on every tool call. So they don't necessarily build agents. All they're doing is equipping agents with the plumbing that the agents need to navigate enterprise environments successfully and safely. The problem is the classic N*M integration nightmare, right? Without middleware. Every single agent builder independently is going to manage their credentials, their OAuth flows, their rate limits, their error handling, their API schema changes for every single tool that agent touches, which is just an enormous combinatorial problem. That's unsustainable at small scale. That is why it's N*M, right? It's, it's the number of middleware times an infinite number. And at enterprise scale, where an agent might need to touch your CRM, your ticketing, your email, your calendar, it's just impossible to keep up with. And so I would argue that this space is a very durable space to operate in. If you're building, as long as the ecosystem for tools remains fragmented, and if anything, it's going to fragment more as companies build their own stuff, agents are going to need an integration layer. The long-term risk here is standardization. If MCP truly becomes a universal, the value of a managed integration is going to start to diminish. So you're essentially betting, if you're building in the space like Compose.io, that agents are going to need something to handle all of the massive enterprise integration touchpoints for a long time to come because so many of these companies are going to be slow to roll out MCPs, and then slow, many of the enterprises that have those tools are going to be slow to adopt those MCPs, and that gap is where your entire company thesis sits. If you're Compose, that one's going to stick around for a while. I do not believe in fast-changing enterprises at scale. I think a lot of enterprises move like dinosaurs, and it's going to, it's going to stick around.
Okay, so compute and sandbox is done, identity done, memory done, tool access, we've talked about that. Layer five for agents: provisioning and billing. This is just brand new. It's the trust layer and it's just starting to arrive now. Agents essentially need to be able to acquire services and pay for them securely. And this is where Stripe Projects fits. It launched this past week. It's the first credible trust layer for agent-to-service transactions. The agent uses the same CLI commands as a human does and it can provision its own database. It can upgrade a hosting tier. Stripe can tokenize payment credentials for that agent. And the developer's raw card details never leave Stripe's vault. The problem is very simple. Since the start of this year, agents have been able to do almost everything when it comes to spinning up a project, except for the part where they need to create accounts and provision infrastructure, because that has always required a human for authentication. And that's the gap that Stripe is closing here. Their databases are ready in roughly 350 milliseconds, or a third of a second. They're free to start. They scale to zero when inactive. Every design choice is optimized for how quickly an agent can provision something that the agent is building. It's not for human speed dashboard clicking. You are assuming terminal access here. We still have some missing pieces here. I think we're going to see growth around agent-to-agent payments. We're going to see growth around metered billing that maps to agent compute patterns. We're going to see growth around dynamic budget allocation where like agent A can spend so many dollars without human approval and agent B can spend so many dollars with human approval. We're going to have a lot of like observability layers that we build in. I think this is a case where Stripe, as usual, has made an excellent product decision. Uh, they're known for that, and this is something that's going to stick around. Like, this is immediately looking like fundamental infrastructure for how agents build on the web. I think we're going to see a few more players in this space, but fundamentally it's going to be focused not on human readability first, but on agent legibility and agent buildability, and then human observability over the top. But regardless, like any agentic economy future, you're going to have provisioning and billing. And so it's, it's newly here, but it's here to stay.
Okay, the last layer is orchestration and coordination. This is the biggest opportunity in the stack because you can leverage the power of multiple agents. It's also a big gap right now. So, the agent needs to work with other agents reliably at scale, with fallback handling, with audit trails, with cost controls, and it, it, it matters a lot to get that right. And there's just so little done well around this. And it's not for lack of interest. Like, Gartner reported a 1,445% surge. I don't even know what that is, a 14x surge in multi-agent system inquiries between Q1 2024 and Q2 2025, let alone 2026, which is going to be up again. Look, quite bluntly, the current tooling is at the framework level, not the infrastructure level. So LangChain lets you stand up a multi-agent workflow, right? But the gap between "I can spin up three agents in a notebook" and "I can reliably run 50 agents across enterprise systems with failure recovery and cost controls and audit logging and human escalation paths," that latter piece that we all need, that is something that we're all hand-rolling right now. And so individual agent capabilities are something we've largely solved. What's been missing is the layer that makes those capabilities composable and parallel and reliable. And so if you're building in this space, here's what doesn't exist yet that needs to exist. Number one, you need a scheduling and lifecycle layer for agents. Not in the container sense, right? I'm not saying that it's a Kubernetes container. I'm saying that you need something that handles agent creation and assignment and health checking and scaling and termination as a managed service. Number two, you need merge and coordination infrastructure that is built from the ground up for parallel agent work. Right? When five agents work on related tasks simultaneously, you need merge queues, you need conflict detection, you need resolution protocols. And today, this is like a bunch of duct tape and a bunch of Git worktrees. Like, it can be so much better. You need, number three, supervision hierarchies, right? Meta-agents that monitor and evaluate and course-correct other agents. Not as a framework pattern you have to code yourself, which so many of us have to do now, but as infrastructure that you can configure. You need financial observability, right? Across multiple agent workflows, what, what did this agent spend? Uh, what was the outcome quality? What's the cost per successful task? This is like FinOps for agents, and it's brand new. It barely exists. Last but not least, you need standard failure patterns and standard recovery patterns. So when an agent's tool call fails, instead of making it up on an individual team basis, you have to have some like standard provisioning around what happens, right? You shouldn't have to depend on the tool, the framework, and what the PM had for lunch that day to decide whether or not your agent recovered. Look, this layer, this orchestration layer, this is the layer where the next infrastructure-defining company is going to get built. The orchestration problem for agents is structurally analogous to the container orchestration problem that Kubernetes solved. Right? Not the compute itself, but the scheduling, the scaling, the health checking, the lifecycle management that makes compute usable at enterprise scale. So, whoever solves orchestration at infrastructure grade is going to own the most valuable position in the agent stack. And it is too early to call a winner.
So, what does all of this mean? You've seen the six layers of the stack. What does it mean for builders right now? I want to give you three lessons that you should take away if you're building on the agent stack today that are truisms for 2026. I don't think they're going to change a lot this year. The stack has to evolve significantly. Number one, right now, reliability is compounding in the wrong direction. When your agent depends on five different primitives, your end-to-end reliability is the product of five different reliabilities. So if each delivers 99% uptime, your system delivers only 95%. If it's at 97% each, it's at 86%. You get the idea. Essentially, you are stacking the liabilities of all your agentic primitives right now because you have to compose so much of this layer by hand. Reliability is really hard to engineer these days. Number two, transitional lock-in is a real risk this year. Right? Building on shims like email as identity creates migration costs when native protocols arrive. Every single shim you adopt is a bet that it either becomes the standard or it becomes something that you're willing to swap out. So think about your choices and think strategically about what is truly agent-native and what is something that is a pragmatic bet, and make a choice about what you think is going to be correct over the next two or three years. We're all living through this together. I can't tell you if email, like a wonderful cockroach, is going to survive forever because it might, or if we're actually going to get true agent-to-agent communication that is post-email. Number three, and this is a big one, agent sprawl is coming. This is the same problem that plagued microservices back in 2018 when, when, when you would get people literally walking into startups from places like Amazon and Microsoft, and the first thing they did when, when this little startup had a tiny little codebase and just wanted to ship, they would say, "Well, it all needs to be a microservices architecture." Did it? No, it didn't. It's a monolith. Shift fast. In the same way, people are looking at agents and they're saying, "Everything needs to be an agent," and it's sprawling all over the enterprise, and they're taking unexpected actions, and you don't have observability, and you don't have an orchestration layer, and so you're just kind of guessing and vibing. That is going to be a bigger and bigger problem over the course of 2026 unless people invest now in orchestration layers that, yes, you're going to have to hand-roll.
Look, I've talked about what I think the new builder skills are. I'll just reiterate them for you here. Context engineering matters a lot these days because what you feed the agent matters for the outcomes you drive. Eval-driven development matters because you have to be able to get the agent to autonomously drive against a result to avoid a lot of the bottlenecks that come from human-reviewed code. And stack literacy is going to be really important, right? You have to know which layer in the stack is your competitive advantage and why, and you have to build relentlessly against that. In the world of agents, the builders who survive, and I don't care if you're building in the space as an entrepreneur, if you're building as an individual with your open-source, or if you're building as a leader and you're building on top of the stack and you need to get agents implemented regardless, the ones who survive, you're going to have to have stack literacy. You're going to have to understand how these six layers work. You're going to have to keep a weather eye on which pieces of the stack are changing and how they affect your business. There is no excuse for lack of stack literacy. And part of the reason this matters, part of the reason I'm talking about it in this channel, is because if you don't have that, even as a business leader, even as a non-CTO, non-tech leader, you are going to be in big trouble because agents drive so much business outcome and business leverage now that is so dependent on these pieces of the stack. And so if you want to have an agent that has tremendous blast radius across your customer success, you've got to understand what's driving that. What parts of the stack actually work? What parts of the stack are you hand-rolling? What are your shims that you're betting on? If you don't have that detailed understanding, you're just kind of hoping and praying that the agent works. That's not a good strategy for the long term. And so, we need to have better stack literacy. And that's why this video is important. So, share it with someone who doesn't understand the agent stack because I guarantee you there are a lot of people who are walking around with a lot of LinkedIn buzzwords in their heads and they don't understand the agent stack. And that's going to lead to a lot of suffering and pain. Frankly, for a lot of IC engineering teams, they're going to be asked to build stuff that doesn't make any sense. Best of luck with that. Cheers.