Give agents your team's context, not an empty prompt

Every agent session starts from zero. The agent can read your code, but it cannot read the decision you made in March about why the auth tokens are stored the way they are, or the runbook that says migrations must be backwards compatible for one release.

Without that context, agents make reasonable choices that happen to be wrong for your team. Then you spend review time explaining things that were already written down somewhere.

Put the context where the agent works

Dispatcher's knowledge base holds your team's specs, architecture notes, and runbooks. Attach the relevant documents to a task, and when that task runs, Dispatcher writes them into the worktree under .dispatcher/context/.

From the agent's point of view, the context is just files in the repository it is working in. Any harness can read them, no special integration required, and the task description can point straight at them: "Follow .dispatcher/context/auth-architecture.md."

What belongs in a context document

The documents that help agents most are short and opinionated:

• Architecture notes that explain why things are the way they are, not just what they are.
• Conventions that a linter cannot enforce: naming, where new modules go, which patterns are deprecated.
• Runbooks for risky operations: migrations, feature flags, releases.
• Specs for the feature at hand, including what is explicitly out of scope.

A good test: if you have explained it in review more than twice, it should be a document.

Keep repository instructions in the repository

Context documents complement, rather than replace, the instruction files that live in your codebase, such as AGENTS.md. Our rule of thumb:

• Instructions that apply to every task in a repository belong in the repository, reviewed in pull requests like code.
• Knowledge that applies to some tasks, or spans several repositories, belongs in the knowledge base and gets attached where it is relevant.

Context is a budget

More is not always better. Every document an agent reads competes for its attention with the code it is changing. Attach the two documents that matter for this task, not the whole wiki. If a document keeps being attached to everything, it probably belongs in AGENTS.md instead.

The result is less re-explaining in review, and agents whose first attempt looks like it was written by someone who has been on the team for a while.