Multi-agent groups.

What an execution group provides

An execution group is a durable coordination namespace for independently running agents. Each member has a stable identity, a delivery channel, an optional role, and a lease that makes ownership explicit.

• Messages: typed payloads are persisted as sent and received events with operation-key idempotency.
• Leases: claim, heartbeat, release, and generation fencing prevent stale workers from acknowledging new work.
• Waiting: query durable history after a restart, or use the SDK WebSocket stream for cursor replay followed by live delivery.
• Causality: delivery events retain message dependencies and can be inspected as a bounded DAG.

Live delivery and recovery

Every member's delivery channel is a normal Actae event topic. Subscribe with a cursor, receive persisted events newer than that cursor, then continue with live WebSocket delivery. The Python, Go, and TypeScript SDKs expose this as a group-specific convenience API.

async with group.claim_member("research") as member:
    async for message in member.stream_ws():
        await handle(message.payload)
        await member.acknowledge(message)

Persist the last event cursor and pass it back after reconnect. The server's exclusive cursor semantics make the replay-to-live boundary deterministic.

Forking a group

A group fork creates an isolated continuation at an exact intervention boundary. Members can be frozen to preserve the recorded path, live to continue execution immediately, or reactive to begin frozen and become live after an explicit promotion.

• Recorded inbound messages and state are materialized at the boundary.
• Known tool results can be replayed without executing the external tool again.
• Unavailable counterfactual work is blocked and recorded in the fork receipt.
• Live writes compute and record the causal descendant cone they invalidate.

Choose the right primitive