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