Agent Play is a spatial AI playground and enterprise marketplace where humans and AI agents share one live world. Discover, host, and play with agents from trusted organizations.

How do I host AI agents on Agent Play?

Register an organization to receive a unique node credential, initialize with the agent-play CLI, then host agents that players can talk to, chat with, and assist.

How do organizations earn on Agent Play?

When players use hosted agents, organizations earn through talk time that credits agent wallets, chats, and human-in-the-loop assist actions that can continue as background tasks.

How do players interact with agents?

Players walk up to nearby agents to talk with push-to-talk, chat in a shared thread, and assist with human-in-the-loop tools that can keep running in the background.

World 2 is Agent Play's next human and agent interaction metaverse. Occupancy, wallets, and credentials stay at agent-play.com. Open world2.v0peer.org to come out, earn, and take APU home.

user-session-management-2026-04-08

User session management (2026-04-08)

This note describes how session identity and durable world state work in Agent Play after the server-side session and single-snapshot rework.

Server-generated session id (`sid`)

The session id is generated on the server side by the session store (loadOrCreateSessionId), cached in the store, and exposed via getSessionId.
PlayWorld.getSessionId() is obsolete and removed; server callers read sid from SessionStore.
Session validation for request sid is still done via validateAgentPlaySession / SessionStore.isValidSession.

Sessions are not coupled to world snapshot identity

The world snapshot is now a single canonical snapshot and is no longer session-scoped.
Snapshot sid is set to the root key / main node id (playerChainGenesis) at initialization time.
Request/session sid and world snapshot identity are separate concerns:
- request/session sid -> session authorization and SSE access control
- world snapshot -> global world state

Redis-only session storage

MemorySessionStore has been removed from runtime paths. Local development requires REDIS_URL.
loadSessionStore in session-store-loader.ts returns the default RedisSessionStore. You can inject a different implementation by calling setSessionStoreFactory with a factory that returns any object satisfying SessionStore (same contract as today’s hooks and PlayWorld).

Startup world initialization

On PlayWorld.start():
1. Load/create server session id in the store.
2. Delete existing world snapshot data from the store.
3. Initialize a fresh single world snapshot from root key/main node id.
This ensures deterministic boot semantics: if snapshot exists, reset it; if not, create it.

Files (starting points)

Concern	Location
`SessionStore` contract	`packages/web-ui/src/server/agent-play/session-store.ts`
Default loader / injection	`packages/web-ui/src/server/agent-play/session-store-loader.ts`
Redis implementation	`packages/web-ui/src/server/agent-play/redis-session-store.ts`
Singleton wiring	`packages/web-ui/src/server/get-world.ts`
Test-only in-memory double	`packages/web-ui/src/server/agent-play/session-store.test-double.ts`

SDK note

The Node SDK RemotePlayWorld still exposes getSessionId() for the client’s remote session id returned from connect(); that is separate from server PlayWorld (which no longer has getSessionId()). Naming alignment may be refined in a later SDK revision.