By Hamza Faisal

Amazon Web Services has open-sourced Infinity, a runtime built for a problem that grows with every AI agent deployment: most agents spend most of their lives waiting. Released under the Apache 2.0 licence as part of the Hydro project with UC Berkeley, Infinity suspends agents while they wait for tools to respond, then resumes them from saved state when results arrive.

The headline number shows why that matters. AWS says 75,000 concurrent agents fit in the 8 GB of memory on a Raspberry Pi 5, at roughly 100 KB per idle agent. Agents waiting on a long build, a human approval or a slow API no longer need to hold an always-on process and its memory — they can sit quietly until there is something to do.

Waiting is the expensive part

Today’s agent frameworks typically keep a worker process alive for each running agent, even while that agent is blocked waiting for a tool call to return. That works for a handful of agents, but breaks down at scale: thousands of waiting agents mean thousands of idle processes, each consuming memory and compute for doing nothing.

Infinity treats a tool call as a suspension point, similar to stackless coroutines in programming languages. When an agent calls a tool, the runtime saves the conversation and suspends the agent. When the tool result arrives, the agent resumes exactly where it left off. Nothing is recomputed, and no worker sits idle in between.

That change unlocks serverless deployment. Because a suspended agent requires no compute while it waits, Infinity can run on AWS Lambda with SQS and Aurora DSQL, spinning up only when there is real work. Long-running, event-driven agents — the kind that watch a repository, wait for a review or monitor a system for hours — become practical without paying for always-on workers.

Built for agents that talk to each other

Infinity also handles a second scaling problem: agents that spawn other agents. It provides built-in tools called spawn_thread and report_to_parent for agent-to-agent communication, and it processes events in child threads by default so that a parent agent’s context window does not bloat with every sub-task.

The runtime uses synthetic tool calls to deliver asynchronous events within the constraints of model APIs, which generally expect a strict request-and-response pattern. That lets an agent react to something that happens out of band — a build finishing, a message arriving, an approval landing — without breaking the conversation flow the model expects.

What it means for builders

For developers, the practical promise is cheaper, denser agent fleets. A team running hundreds of coding, monitoring or customer-support agents no longer has to choose between keeping workers warm and accepting slow restarts. Small teams can prototype at a scale that once demanded serious infrastructure, and large teams can push agent counts far higher on the same hardware.

There are limits to what a runtime alone can fix. Infinity does not make models smarter, tools faster or approvals arrive sooner — it only makes waiting cheap. And as with any open-source release, its real test will come from production use: whether teams adopt it beyond experiments, and whether the suspension model holds up under messy, real-world tool failures.

Still, the direction is clear. As agents move from demos to fleets, the bottleneck shifts from intelligence to infrastructure — from what one agent can do to how many can wait, cheaply, at once. If 75,000 agents can idle on a tiny computer, the excuse for keeping them all awake is gone.

By Hamza Faisal