Rivet: A New Paradigm for Scaling and Orchestrating AI Agents on S3

Why AI Agents Need New Infrastructure

Current AI agent deployments face a fundamental contradiction: agents require persistent state, high-concurrency processing, and flexible orchestration, yet traditional cloud infrastructure was never designed for this. Rivet (YC W23), in its Launch HN project posted on Hacker News, proposes a radical but sensible approach—building agent scaling and orchestration directly on top of S3.

As object storage, S3 naturally offers high durability and near-limitless scalability, but it's typically not the first choice for running stateful agents. Rivet's angle is this: the core need of an agent isn't low-latency compute—it's reliable state management and event-driven workflows. By mapping the agent's runtime state, message queues, and task orchestration layer onto S3 objects, Rivet attempts to bypass complex infrastructure management and let developers focus on agent logic itself.

The appeal of this approach lies in its minimalist operational model. Developers don't need to provision databases or message middleware; each state change of an agent is written to S3 as an object, and orchestration is triggered via polling or event notifications. For startup teams and prototyping scenarios, this "serverless-style" agent hosting significantly lowers the barrier to entry.

S3 (Simple Storage Service) is an object storage service launched by AWS in 2006 that stores data as "objects" in a flat namespace, where each object contains the data body, metadata, and a unique key. Its core characteristics include: 11 nines of data durability, throughput that scales automatically with request volume, and eventual consistency (upgraded to strong consistency for new object PUTs and overwrites after 2020). Unlike block storage or file systems, S3 does not support in-place modification or partial appends—every update is a full object replacement, with historical versions retained via version IDs. S3's API model is simple (PUT/GET/LIST) and is billed by storage volume and request count. These traits make it the default choice for backups, data lakes, and static asset hosting, but its high latency (typically tens of milliseconds) and the scaling bottleneck of LIST operations mean it's rarely used for low-latency transactional scenarios.

S3-Native Design for Agent Orchestration

Rivet's core design revolves around three abstractions: agent definition, state storage, and scheduler. The agent definition describes workflow steps as code or configuration; state storage uses S3 objects to save each agent instance's context and intermediate results; and the scheduler is responsible for detecting state changes and triggering the next step.

A direct benefit of this design is elasticity. S3's write and read capacity scales automatically with request volume, so growth in the number of agents doesn't introduce new operational burden. Another benefit is auditability—the complete state history of each agent is an object version on S3, naturally supporting replay and debugging.

However, S3's latency characteristics also introduce challenges. For interactive agents requiring millisecond-level responses, polling S3 may introduce unacceptable delays. Rivet's strategy is to buffer high-frequency operations in memory and only periodically persist to S3, which partially sacrifices state consistency. Some developers in Hacker News comments question whether this trade-off is suitable for production environments, especially race conditions in multi-agent collaboration scenarios.

Race condition refers to when multiple execution units concurrently read and write shared state, and the final result depends on uncontrollable execution timing, leading to unexpected behavior. In agent orchestration, a typical scenario is: two agent instances read the same S3 object as context almost simultaneously, each updates it, and writes it back—the later writer silently overwrites the earlier writer's changes. Since S3 object writes are "whole-object replacement" rather than atomic field updates, and there's no built-in optimistic locking (such as version-number compare-and-swap), native S3 APIs alone cannot directly prevent this kind of lost update. Common mitigations include: implementing compare-and-swap on object metadata or a separate lock object, introducing an external coordination service (such as DynamoDB conditional writes), or having a single scheduler serialize all state changes for the same agent instance. This is also the technical root of the reliability concerns raised in Hacker News comments about multi-agent collaboration scenarios.

Controversy and Consensus Across Multiple Perspectives

According to the Launch post and comment discussions on Hacker News, Rivet gained recognition from early followers but also faced sharp criticism. The consensus: S3 as an agent state backend has clear advantages in cost and large-scale scalability, especially suited for batch-processing and long-running agent tasks.

The disagreement centers on latency and consistency. Some commenters believe using S3 for the orchestration layer is "the wrong tool for the job," because S3's strong consistency model behaves in complex ways across regions, and object storage's list operations can become a bottleneck at scale. Others counter that for many agent workflows, second-level latency is sufficient, and the developer productivity gains from S3's simplicity far outweigh the latency loss.

A unique insight comes from a single-source comment: Rivet's real value may not lie in S3 itself, but in the fact that it provides a standard interface for agent state management, allowing the underlying storage to be swapped out in the future without affecting upper-layer logic. If this abstraction holds, Rivet's long-term positioning will be the "control plane" of agent infrastructure rather than an S3 wrapper.

Strong consistency and cross-region replication are key background for understanding the comment disagreements. In December 2020, AWS announced that S3 provides strong consistency for PUT and LIST operations on new objects, meaning any subsequent read after a successful write will see the latest version. But this guarantee only holds within a single region; S3's Cross-Region Replication is inherently asynchronous, and replica regions may lag by seconds to minutes, with no ordering guarantees. For agent orchestration deployed across regions, if state is written in region A and then read by a scheduler in region B, stale data may be observed, undermining the assumption that "state is truth." Additionally, S3's LIST operation returns at most 1000 keys per request with pagination when the bucket contains a very large number of objects, and high-frequency polling significantly increases request costs and latency—this is precisely the concrete source of the concern that "object storage list operations may become a bottleneck."

Practical Implications for Developers

For teams building AI agents, Rivet offers a path worth evaluating: if your agent workflows are primarily asynchronous tasks with high requirements for state durability but low sensitivity to latency, then S3-based orchestration can greatly simplify your architecture. Conversely, real-time conversational agents still need to consider traditional databases or in-memory queue solutions.

Rivet's launch also reflects a broader trend—AI agent infrastructure is differentiating from general-purpose cloud computing toward domain-specific solutions. S3 is just a starting point; more storage and orchestration primitives optimized for the agent lifecycle may emerge. Developers should pay attention to the abstract design behind such projects rather than merely comparing the pros and cons of underlying storage.