Agents can turn one human request into a burst of searches, API calls, and compute-heavy work that older systems were not designed to absorb.
2
Request-based API gateway pricing becomes difficult to plan when traffic depends on unpredictable agent behavior rather than repeatable user or machine patterns.
3
Agent Substrate tries to run many mostly idle agent sessions on a smaller pool of workers, but the project is still at an early stage and many users may never need it directly.
Summary
Erika and Demetrios discuss how agents change the traffic patterns behind software. A person asking an agent to research something can trigger many searches, website visits, or API calls in quick succession. Financial analysis systems are one example, since an agent can test portfolio assumptions much faster than a human. The same pattern affects API gateways, whose request-based pricing was easier to estimate when traffic followed known usage patterns. They compare agent sessions with microservices and SaaS tenants. Each agent can have its own identity, connectors, projects, and growing context, which makes the workload different from running multiple copies of one service. They then examine Agent Substrate, a Google project built above Kubernetes that maps many actors onto reusable workers and supports suspend-and-resume operations. Erika is open about its early state. The conversation ends by questioning how many agents really need cloud-scale infrastructure, since much of the complexity may remain inside products that users already consume.
One agent request can create a burst of work across many services
Erika says an agent can fire off tens of searches to assemble an answer, and computer-use systems can interact with websites faster than a person. That means one human request can load databases, APIs, websites, and the middleware between them. She gives financial services as an example. An agent optimizing a portfolio can test many capital-market assumptions quickly, while a human would move through those tests slowly. The issue is not limited to financial systems. Any service that agents discover and call can receive more traffic without gaining more human users.
Agent traffic is harder to predict than older machine traffic
Older machine users were fast, but their behavior was usually repeatable. Teams could plan for Black Friday or for end-of-month and end-of-quarter reporting because the timing and request patterns were known. Erika describes agents as improvising software that decides what to do next and changes its route while running. Their bursts are limited mainly by how many agents people deploy. She says this creates a different scale of unpredictability from ordinary human behavior, even when the agent activity begins with a normal user request.
Request-based gateway pricing becomes difficult when agents multiply calls
Erika explains that API gateway vendors often charge by the number of requests passing through the gateway. Customers used to estimate future call volumes from earlier traffic and sign multi-year contracts around those estimates. Agents disrupt that model. A product may be picked up by agents as one small part of a much larger workflow, causing many requests without a comparable increase in people who intentionally use the product. Erika has disliked request-based pricing for a long time, and says the problem is sharper now because customers cannot reliably predict the number of calls they will generate.
Agent sessions differ from microservices because their state and context are personal
Demetrios and Erika compare agent workloads with the microservices model that Kubernetes was built to manage. Microservices usually run multiple instances of the same service. Agent sessions can differ from one another because each person has different context, connectors, authentication, authorization, and projects. Erika compares this with SaaS tenancy, where systems moved from isolated tenant stacks toward shared services that carry tenant identity in requests. Agent context can also grow large, which creates a separate problem when an old session needs to be restored quickly.
Preloading can hide latency when a session needs to return
Erika connects agent context restoration with older techniques that load data before the user asks for it. She recalls financial systems caching analysis data in memory. She also describes Gmail beginning to fetch a user's messages while the person is still typing a password, using the time created by slow human input. Humans give systems time to prepare. An agent returning to a project after a month may not provide that delay, so restoring its context and state quickly becomes part of the infrastructure problem.
Agent Substrate places many actors on reusable workers
Erika describes Agent Substrate as an agent workload orchestration platform that uses Kubernetes underneath a purpose-built management layer. Its model maps a larger set of actors, such as agents, onto a smaller set of ready workers. Instead of creating a dedicated worker for every actor, the system assigns actors to available workers as needed. The design relies on agents tending to sit idle for much of the time. It also packages an agent with policies describing what it can do and supports different sandbox technologies, including micro VMs and gVisor.
Suspend and resume are intended to preserve an agent without keeping its worker running
The discussion focuses on returning to an agent after a period of inactivity. Agent Substrate describes sub-second suspend and resume operations, persistent working memory, and state that survives hibernation cycles. In the example, someone returns to a Lovable project after a month and wants the code and context available without waiting for a full cold start. Erika says the project is very early. She does not see a clear upgrade path between releases and is unsure how much of the memory-loading problem has been solved.
Most agent users may never need to manage this infrastructure
Demetrios questions whether most agents need to run as cloud agents at all. Someone using Gemini on a phone may simply open a chat and enter a prompt, rather than deploy an agent that runs continuously or serves other people. Erika agrees that people in the coding-agent bubble may overestimate how many use cases need this level of scale. The infrastructure may still matter to companies operating very large agent services, while ordinary users encounter it only as an invisible part of products from companies such as Google, Anthropic, OpenAI, or Lovable.
Agent infrastructure may become an implementation detail instead of a tool most engineers install
Erika and Demetrios ask whether Agent Substrate will spread beyond companies with unusually large agent workloads. Its value depends partly on whether setup is simple enough to add without creating another major operational burden. Demetrios suggests that cloud providers may wrap this kind of technology inside services that engineering teams consume without managing directly. The same question applies to sandboxes. They may be useful for agent safety and isolation, yet still remain mostly inside products rather than becoming something ordinary users or most engineers configure themselves.
"If you are selling these pieces of middleware, and your customer, which uses the API gateway, if they are in a situation where they can't even predict, because they have all of these unpredictable actors in this space now that is at a different scale of unpredictability."Erika12:13
Who should watch
You are building an agent product and need to understand why ordinary API and gateway assumptions may fail when one prompt creates many downstream calls.
Your team is comparing Kubernetes, serverless services, and purpose-built agent orchestration for sessions with personal context and long idle periods.
You want a grounded discussion of whether your workload really needs cloud-scale agents, persistent sandboxes, or infrastructure that may eventually stay hidden inside a platform.
