An AI assistant waiting overnight for approval should not need to keep a computer process occupied. Infinity, an open-source research release announced by AWS on October 23, makes that idea central to its design. The project comes from Hydro, a collaboration involving AWS and the University of California, Berkeley.
The practical opportunity is to make unfinished work cheaper to keep available. The harder question arrives the next morning: can the assistant recover the right task, recognize what has changed and act only once?
TENS analysis: Infinity should be evaluated as a system for returning to interrupted work. The useful unit of progress is a correctly resumed task, with its permissions and results intact. A large population of waiting agents establishes a different capability. Separating those measures helps explain both the release’s promise and the evidence still needed before routine deployment.
The morning-after test
Consider an illustrative office assistant preparing a document for release. It requests approval, then waits. Before the answer arrives, a colleague replaces the document, another colleague withdraws permission, and a delayed notification reports that the older version is ready. This is a proposed test scenario, not an incident reported by Infinity’s developers.
The assistant’s stored conversation could be perfectly preserved and still describe a world that has changed. TENS proposes giving every resumption a short decision record: the version awaiting action, the approval that applies to it, the latest cancellation or replacement, and the result already produced. That record would make the difference between recovering history and recovering authority visible to a reviewer.
Infinity’s architecture documentation describes restoring conversation history and processed-message identifiers from storage. It also describes saving a completed tool-call turn before dispatch and filtering out previously handled messages. These are concrete mechanisms for preserving a conversation across separate executions.
Our scenario asks a further application question. If an approval references yesterday’s document, should it authorize today’s replacement? The answer belongs in the workflow’s rules. A model’s fluent explanation of the old conversation is insufficient evidence that the current action is permitted. Teams could test that boundary with harmless documents before connecting the same pattern to consequential work.
Count completed work alongside waiting agents
AWS reports a benchmark involving 80,000 agents and 3.2 million simulated completions on a single AMD EPYC processor thread, with in-memory storage. It measured roughly 100 kilobytes per idle agent and estimated that about 75,000 would fit in 8 gigabytes. The Raspberry Pi comparison describes memory capacity; the reported test was not a demonstration of that many real models doing useful work on a Pi.
TENS proposes pairing that capacity measure with a resumption measure: of the tasks deliberately interrupted, how many eventually produce the intended result without repetition, lost changes or an invalid approval? Report the elapsed time and resource use for those successful tasks, including storage, tool execution and model calls.
This changes how two prototypes might be compared. One could retain more unfinished conversations while recovering fewer correctly after a disruption. Another could use more storage but make recovery easier to inspect. Neither tradeoff appears in an idle-memory figure alone. No such comparison has been run by TENS; it is an evaluation framework prompted by the release.
A repeated message must not become repeated work
AWS’s Lambda documentation supplies an important operational constraint: queue events can be delivered more than once. It tells developers to design processing so a repeated message does not create unintended additional effects. Infinity’s documentation addresses this environment through stable identifiers and tracking of messages already processed, while preserving order within each conversation thread.
That creates a useful distinction for buyers and builders. Recognizing a repeated input is one checkpoint. Confirming what happened in the external application is another. A document service might finish an operation just before its acknowledgment is lost. A recovery test should inspect the document service’s actual result as well as the agent’s conversation.
TENS proposes testing three interruption points: before an external action begins, after it completes but before acknowledgment, and after the acknowledgment reaches the agent. For each, an operator should be able to explain whether the next step resumes, safely repeats or stops for review. These are proposed tests, not findings that Infinity fails them.
The same discipline applies to cancellation. A waiting task can remain cheap to store long after it has stopped being useful. A clear closed state and an explanation for rejecting a late result would make that lifecycle understandable to the person who originally requested the work.
Infinity’s release makes efficient waiting a tangible research direction. Its broader value will depend on what happens after the wait: whether applications preserve the current intent, prevent repeated effects and expose enough evidence to settle uncertainty. Those are outcomes an organization can test directly, even when the underlying model remains unpredictable.
Sources: AWS Open Source Blog’s October 23 Infinity announcement; Hydro’s Infinity architecture documentation and public repository; AWS Lambda documentation on Amazon SQS event processing.
Featured image: Software code on a computer monitor, used illustratively; not Infinity’s source code. Photo: Markus Spiske via Wikimedia Commons. CC0 1.0 Universal Public Domain Dedication. Center-cropped from 5,760 × 3,840 pixels to 16:9 and resized to 2,400 × 1,350 pixels; no generative or content-altering edits.