Dispatch

Most businesses do not have a data problem. They have a paperwork problem. Invoices arrive as PDFs, purchase orders live in a spreadsheet, customers ask questions by email, contracts sit in a shared drive, and a handful of people spend their week moving facts from one of those places to another. Every step is slow, error-prone and interrupts someone who should be doing something else.

Every AI demo makes this look solved. In production it fails on the boring parts: a reply that states a number nobody can find in a document, an action that nobody approved, a quiet regression after a prompt change. I have shipped AI into two products with paying customers, and those are the failures that actually cost trust. Dispatch is designed around them.

You forward Dispatch your inbox, your documents and a connection to the tools you already use. A Dispatcher reads each item and hands it to a specialist: Intake extracts structured data from any document with a citation per field; Accounts matches invoices to purchase orders and receipts and drafts the supplier query when they disagree; Customer answers from order records and your policies; Follow-up chases what is overdue, once; Analyst answers questions about the business with SQL it shows you.

Before anything leaves, an independent Reviewer checks it against your policy and the evidence, and an approval matrix decides whether it runs on its own, runs and tells you, or waits for you. A control room shows the queue, what is waiting, what each decision cost and the ledger of work done.

The demo company is Northwind Supplies, a fictional distributor with a synthetic week of invoices, emails and contracts, including a sideways scan, a duplicate invoice and two prompt-injection attempts hidden in email signatures. The demo is also the evaluation dataset.

Every incoming item becomes a job on a Postgres-backed queue. The Dispatcher classifies it and builds a context pack for the owner agent: the agent's role, only the policy sections that apply, only the tools it may call, retrieved evidence with citations under a token budget, and up to five similar cases the business resolved before. The pack is stored with the job so the exact model input can be replayed.

Agents are LangGraph state machines with typed state, and they act only through Model Context Protocol servers for mail, files, sheets, CRM and accounting. The reference servers are CSV-backed, so the whole system runs from a folder of files; a real system is a new server with the same tool names.

• Inbound mail, files and uploads become immutable items on a Postgres-backed queue
• Dispatcher assembles a context pack: role, applicable policy, tool schemas, cited evidence, similar past cases
• Specialist agents run as LangGraph state machines and act only through MCP tools
• Reviewer plus a YAML approval matrix decide auto / notify / approve for every action
• Memory is written only from executed actions and human decisions, never from an agent's own beliefs
• OpenTelemetry traces to Langfuse; a control room with queue, approvals, traces and the work ledger

Grounded, or it does not say it: every extracted value and every claim in a draft links to a page and a quote that must appear verbatim in the source. Context engineering instead of prompt stuffing: budgets per layer, byte-stable prefixes so prompt caching works, compaction that never drops a turn with a number in it. Human in the loop by policy: the approval matrix is YAML the owner can read on one screen, evaluated in code, never by the model.

Evaluated in CI: retrieval recall, extraction accuracy with zero tolerance for fabricated fields, routing accuracy, policy violations that must be zero, Reviewer catch rate on seeded bad actions, and a context contract check that asks whether the pack even contained the fact the right answer depended on. A change that lowers a score does not merge. Memory is written only from outcomes and human decisions, so the system learns the business's judgment instead of its own mistakes.

Your models: Claude Opus 5 for judgment, Sonnet 5 for volume, and a self-hosted vLLM path for businesses that cannot send documents to an API at all.

Started September 2026. Phase 0 of 6. Nothing runs yet; what exists is the plan, the architecture, the agent specifications, the context-pack design, the evaluation strategy and the demo scenario, all published in the repository before the first line of code, so the build can be judged against what was promised.

Each phase has a definition of done a stranger can verify with one command, and a GitHub issue tracking it. The README's table of 'a day with Dispatch' will link each row to a recorded run as the phase that delivers it ships.

At Commercient I learned that putting AI into a product with customers is a systems problem first: the agent had to live inside the existing .NET platform, use the data the platform already synced, and be debuggable by a teammate. At DTAXO I learned that in tax, a confident wrong number is worse than no number, so every value had to trace back to a source document.

Dispatch is those two lessons, generalised to any business that runs on email, PDFs and spreadsheets, and built where anyone can read the code, the plan and the scores.