Cloud architecture

Dispatch is a cloud-hosted agent that acts on the user's real connected accounts. There is no scratch workspace, no sandboxed filesystem the user has to reason about separately, and no "preview" mode that runs against fake data. Every read sees real data, and writes from native connectors that carry a risk annotation (sending mail, posting to Slack, modifying a calendar event, edits to the permission policy) pass through the permission gate before they run. Internal writes to Dispatch's own memory surfaces (preferences, daily notes, people, documents, todos) are not gated, and Composio writes are not currently routed through the gate either.

Where it runs

Dispatch runs as a cloud service with two tiers:

• Request handling and compute. When a chat message arrives or an automation fires, the service creates a session and hands off to the agent runner. Long-running work continues in a fire-and-forget background context so the request can return immediately while the agent keeps going.
• Persistent state and streaming. The agent reads and writes durable state throughout a run; the client subscribes to that state to render output as it arrives.

The split is intentional. One tier gives us a fast HTTP surface and predictable behavior for dispatch and webhooks. The other gives us reactive queries, transactional writes, and first-class scheduling, which we lean on for the agent's memory layer, automations, and the streaming surface.

What state persists

Per-run state is stored server-side. The agent's full transcript, tool calls, tool results, and streamed chunks are all persisted as part of the session record. After a run ends the session is queryable as history; the agent's history connector can replay prior sessions into a current run when relevant.

Per-user state (preferences, daily notes, people, automations, todos, booking links) is also stored server-side and is exposed to the agent through connectors. The agent reads and writes that state directly through tools, not through application APIs.

Per-run ephemeral state is the in-flight model context: messages assembled for the current iteration, the tool-search registry, the permission gate's per-action denial memo. None of that is persisted past run end except as part of the transcript.

Why not a sandbox

A common shape for AI agents is to give the model a sandboxed environment (a filesystem, a shell, a scratchpad) and let it experiment freely before committing anything to the real world. That is the right shape for code-writing agents and for any task whose primary risk is destructive output to a local environment.

Dispatch's job is the opposite. The point of the product is to act on systems the user already trusts: their actual inbox, their actual calendar, their actual Slack. A sandbox would defeat the purpose. Two consequences:

• Native writes are gated, not isolated. Native connector tools that modify external systems carry a risk annotation and pass through a permission check before they execute. The check uses a per-organization policy document plus a validator model. Composio-brokered writes are not currently annotated and are not routed through the gate yet.
• Reads see real data. Every connector reads live state from the user's accounts. There is no fake data the agent might mistake for real, and no mismatch between what the agent sees and what the user sees.

Run lifecycle summary

A full description lives in Streaming and runs. In short:

1. The agent is invoked from one of four origins: chat, a triggered automation, a scheduled task, or a todo. The dispatcher creates a session.
2. The agent loop runs in the background, iterating until the model stops calling tools.
3. Each turn streams chunks to the server; the client renders them reactively.
4. The session ends; transcript and tool history are queryable from the run history surface.

For agents

• Dispatch runs as a cloud service with a request-handling and compute tier (the agent dispatcher) and a persistent state and streaming tier.
• The agent is invoked from a dispatch endpoint and runs in a fire-and-forget background context so the HTTP request can return immediately.
• All run state (transcript, tool calls, tool results, streamed chunks) is persisted server-side as part of the session record.
• The agent has no sandbox. Reads see live external data; writes go to real systems and are gated at the permission gate when the tool carries a risk annotation (native connectors do; Composio-brokered tools do not yet).
• The agent is invoked from one of four origins: chat, triggered automation, scheduled task, or todo.