Memory and context

A useful assistant is one that does not need to be told the same things every time. Dispatch's memory layer is the mechanism for that. Across runs the agent accumulates context about the user (their preferences, the people they work with, what they did today, the standing rules they want followed) and reads from it on subsequent runs.

The memory is not a single store. It is a set of file-backed surfaces, each exposed through a connector. The agent reads and writes them through the same read_file and write_file tools it uses for everything else.

Preferences

The preferences file lives at /preferences/global.md. It is the most important piece of memory: the user's standing instructions about how Dispatch should behave. Typical entries:

- I prefer concise summaries: under 200 words unless I ask for more.
- Default meeting length is 25 minutes, not 30.
- Sign off as "A" on internal emails, "Aron" externally.
- Never schedule anything on Friday afternoons.

The agent reads /preferences/global.md at the start of every run as part of system-prompt construction. When the user says "remember X" or "always do Y", the agent updates /preferences/global.md directly via write_file or edit_file. The permission policy at /preferences/permissions.md is a sibling file, gated separately by the permission gate.

Daily notes

The daily-notes connector maintains a per-day journal under /daily-notes/. Today's note (/daily-notes/today.md) is injected into the system prompt on every run, so the agent always knows what day it is and what context the user already has open.

The user (and the agent on the user's behalf) can write to today's note throughout the day: pinned items, scratch thinking, things to return to. /daily-notes/today.md resolves to the current date per request; writes route to the dated file directly so the two stay in sync. Past daily notes remain readable at their /daily-notes/YYYY-MM-DD.md paths (read-only) and are part of the agent's history surface.

A scheduled automation runs each morning (default 06:00 in the user's time zone) that carries yesterday's open items forward, drops completed ones, and stages today's calendar and unread mail. Its prompt lives at /automations/schedules/daily-note-rollover.md and is user-editable. Because today's note is in the system prompt on every run, keeping it focused keeps run cost predictable.

People

Each contact has a file at /people/{slug}.md. The slug is a stable name derived from the contact's email or display name. Each file accumulates context about the person (recent conversations, how they prefer to be reached, the company they work at, ongoing threads) and is read whenever the agent needs to operate in relation to them.

The people connector is the canonical place to record relationship state that should outlive a single conversation. The agent updates it when it learns something durable; the user can edit it directly.

Automations

Automations live as files under /automations/. The two namespaces are:

• /automations/triggers/: event-driven rules. "When a new email arrives from X, do Y."
• /automations/schedules/: time-driven rules. "Every weekday at 8am, do Z."

The agent can read existing automations to understand standing rules and can create new ones via the same file tools. The automations runtime watches both namespaces and dispatches the relevant prompt when conditions are met, which originates a new agent run with its own session.

Todos

Todos live as files at /todos/{slug}.md. Unlike preferences (a single global file) or people (one per contact), todos are individual items each with their own history. The agent can list them, create them via the todo_create tool, update them, and watch the status field as work progresses.

The todos surface has its own runner separate from chat: when a todo is in an actionable state, Dispatch can dispatch an agent run scoped to that todo. The agent loads the todo file, does the work, and writes the result back.

History

The history connector provides tools to list and load past agent sessions. The agent uses it to answer "what did we decide last week?" or "pull up the conversation about the Acme proposal" without the user having to remember the session ID.

Sessions are stored server-side, indexed by session reference and organization. The history connector exposes them through tools rather than dumping the index into the prompt; this is the same just-in-time approach used by tool search.

Defaults

The defaults connector exposes a read-only mirror of preferences and automations as they ship out of the box, under /defaults/. The agent diffs the user's customizations against the defaults to recognize when a user has overridden something. This is useful for explaining behavior ("I scheduled at 25 minutes because you set that in preferences").

Per-user vs. per-organization

All memory described here is per-organization. A user's preferences, daily notes, people, automations, todos, and history belong to the organization they are working in. Switching organizations swaps the memory; there is no global "user memory" that crosses orgs.

This is the right default for the product: an executive working at one company and on a side board has a clean separation between the two without needing to think about it.

For agents

• Memory is file-backed and accessed through the same read_file / write_file tools as everything else.
• Preferences live at /preferences/global.md and are read into the system prompt every run. The agent updates them by calling write_file or edit_file against that path when the user gives a "remember X" / "always do Y" instruction.
• The remember tool is a separate read-only search over the long-term memory store; it does not write preferences.
• Permission policy lives at /preferences/permissions.md; writes are gated as policy-write.
• Daily notes live under /daily-notes/. /daily-notes/today.md resolves to the current date per request; writes route to the dated file. Today's note is injected into the system prompt every run. Past notes live at /daily-notes/YYYY-MM-DD.md and are read-only. A scheduled morning rollover (default 06:00 in the user's time zone) at /automations/schedules/daily-note-rollover.md carries context forward.
• Each contact is a file at /people/{slug}.md accumulating relationship state.
• Automations are files under /automations/triggers/ and /automations/schedules/.
• Todos live as files at /todos/{slug}.md; the agent can create them with todo_create.
• The history connector provides tools to list and load past agent sessions.
• The defaults connector mirrors out-of-the-box preferences and automations under /defaults/ for diffing.
• All memory is per-organization; switching organizations swaps the memory surface.