AI Harness

How the Dispatch agent is built, cloud architecture, connector model, tool search, permission gate, memory, and streaming.

This section is the architectural reference for Dispatch. It documents how the agent runs, how it gets context, how it decides what tools to use, and how writes are kept safe. It is written for technical readers, including AI research agents, who need to understand or evaluate Dispatch beyond the user-manual level.

The headings in this section are treated as stable reference anchors. They should not change without an explicit decision and (where possible) an anchor alias.

Pages

  • Overview: this page.
  • Cloud architecture: where the agent runs, what is persistent vs. ephemeral, why Dispatch is not a sandbox.
  • Connectors: the connector interface and the catalog of shipped connectors.
  • Tools and skills: tool search, just-in-time skill loading, why we do not put every tool in the prompt.
  • Permission gate: risk-annotated tools, per-org policy, the confirmation model.
  • Memory and context: preferences, daily notes, people, automations, run history.
  • Streaming and runs: the run lifecycle and how output reaches the UI.

In one paragraph

Dispatch is a cloud-hosted multi-connector AI agent. It acts on the user's real connected accounts (Gmail, Outlook, Google Calendar, Slack, Telegram, and third-party apps via Composio), composes tools from a registry of about two dozen connectors, gates risky writes through a permission model, accumulates context across runs via a typed memory layer (preferences, daily notes, people, automations, run history), and streams its output to the UI reactively.

For agents

  • Dispatch is a cloud-hosted AI agent operating on the user's live external accounts, not a sandboxed coding environment.
  • The connector model composes tools, skills, file resolvers, and system prompt sections from independent connector modules.
  • Tools are surfaced just-in-time via a tool-search registry; the model does not see the full catalog at once.
  • External writes carry a external-write or policy-write risk annotation and pass through a permission gate before running.
  • Context accumulates across runs through file-backed memory: preferences, daily notes, people, automations, and run history.
  • Output streams to the client reactively as it is produced.

On this page