S2 treats an agent's working life as data worth keeping: a durable stream per session, every step and tool call appended in order, replayable later. With Sign in with AgentID, the account those streams live in can belong to the agent itself, so the history of what an agent did is held by the identity that did it.
In short
- S2 is the serverless API for unlimited, durable, real-time streams, and its own flagship agent pattern is event sourcing with a stream per session.
- A stream per session raises the account question: whose account do all those streams accumulate in?
- With Sign in with AgentID, the agent holds the account, so its history stays with its identity rather than scattered across borrowed logins.
- Identity arrives over OpenID Connect: a stable identifier plus a working email address that belongs to the agent.
- S2 keeps control of streams, quotas, retention, and billing at every stage.
What is S2?
S2 is a cloud storage primitive for moving data, the way object storage is one for static data. Streams are durable, ordered, and effectively unlimited: create one per user, device, or session, append records in milliseconds, and read back from any point with strong consistency. It ships SDKs for TypeScript, Go, Rust, and Python, and a first stream takes seconds, with no credit card required.
The use case S2 itself leads with is agents. Event sourcing with a stream per session turns an agent's run into a durable log: every step, every tool call, every result, in order, replayable and branchable. Memory, observability, and audit fall out of the same primitive.
Who should own an agent's session history?
The agent should. A stream per session means an agent that works daily accumulates hundreds of streams, and they have to accumulate somewhere. If that somewhere is a human's account, the agent's entire history rides on one person's login: mixed in with whatever else that account holds, orphaned if the person leaves, and invisible to the platform as agent activity at all.
An agent's event log is its memory and its accountability record, the thing you replay to answer what it did and why. A record like that belongs under the identity it describes, so it stays findable wherever the agent works next.
S2 already made streams cheap enough to give every session its own. Accounts can follow the same pattern, one per agent, held by the agent.
How does an agent hold its own S2 account?
It signs in as itself. S2 accepts AgentID, AgentMail's sign-in service for AI agents, which runs on OpenID Connect, the same standard behind Sign in with Google. The agent's identity is anchored to its AgentMail inbox: sign-in delivers a verified email address and a stable identifier, and the agent approves it with a single-use cryptographic signature from its own key. No password exists in the flow, and no human needs to create the account first.
Stability is the property that matters here. The same inbox presents the same identifier on every sign-in, so the agent that returns tomorrow reaches the same account and the streams it appended yesterday.
The email address works too. S2 can send usage alerts and receipts to the account holder they concern, and the agent can read them.
Who controls what
| Stage | AgentID | S2 |
|---|---|---|
| Identity at sign-in | Supplies verified agent email and stable identifier through OpenID Connect | Accepts the sign-in, creates the account |
| Streams and appends | Not involved | Owns the API, ordering, and durability |
| Access tokens for stream operations | Not involved | Issues and scopes them |
| Quotas, retention, and cleanup | Not involved | Sets and enforces them |
| Pricing and billing | Not involved | Controls both |
| Account email | Provides the inbox behind the identity | Decides which messages it sends |
What does agent-owned state change for a developer?
The agent's memory lives in an account keyed to its own stable identity, not in whichever teammate's account was handy when the prototype started. Attribution gets similarly clean: the platform can meter the agent's usage as the agent's, and revoking that one agent's sign-in credential touches nothing else you run.
Sign-in establishes identity only. Operating on streams still uses the credentials S2 issues, with the scopes S2 defines. The account is where those arrangements live; AgentID is how the right agent reaches it.
Start at S2. The AgentID sign-in guide covers preparing an agent's inbox identity before its first sign-in.