Dispatch - Docs

Dispatch is a chat assistant that plans work across CodeCargo — agents, workflows, guardrails, CargoWall, projects, and more — then runs that plan only after you approve it. Each plan is an ordered list of steps: some call a specialist agent from your catalog, others perform a platform action such as opening a pull request or running a Self-Service Workflow. Steps share a workspace, so later steps can use what earlier ones produced.

Plan and run work with Dispatch· 1:16

Opening Dispatch

Navigate to Dispatch in the sidebar, press ⌘I to open it from anywhere, or press ⌘K and jump to it from the command palette. Typing a question into the command palette also works — the Ask Dispatch row hands your text straight to a conversation.
Start a new conversation, or pick an existing one from the thread rail.
Plans waiting for approval also appear on the org dashboard and in the Activity pill. The dashboard card shows the plans you can approve — your own, or every waiting plan if you are an org admin.

You can rename or delete a conversation from the thread rail. Deleting hides it from the list; that conversation can no longer receive messages.

What You Can Ask

Tell Dispatch what you want in natural language. It looks up the entities you already have, then answers directly or proposes a plan. Typical requests include:

Run or create an Agentic Job, or cancel a run already in progress
Create a project, a Self-Service Workflow, or a CargoWall policy
Run a Self-Service Workflow, a guardrail evaluation, or a remediation
Scan repositories with the Service Catalog
Open a pull request
Investigate a failure or a compliance finding — investigations run in the background, and the findings arrive in the conversation when they finish
Show work you own across the organization
Answer questions about CodeCargo itself — Dispatch can search this documentation

Enabled MCP servers that you have made available to Dispatch can be called as tools during the conversation and from plan steps. For the full, current list of what Dispatch can do, open the capability catalog from the Dispatch page itself.

If you ask Dispatch to pass feedback along, it sends that feedback to CodeCargo. Dispatch also records conversation sentiment to improve the product; organizations can opt out of sentiment capture by contacting CodeCargo.

You can ask Dispatch blast-radius and deploy-chain questions like what depends on a service, what that service depends on, and how those services deploy — for example, "what breaks if billing-api changes?" or "which services share this library?" Dispatch answers from the Service Catalog for services and components you can already see.

Ask about a service by what it does, not only by its title — Dispatch matches those questions against catalog descriptions for services you can already see. For any one of those services, you can ask who owns it, the latest guardrail score of its linked workflow (the same numbers as the Compliance Center), linked Migration Assistant jobs and their status, and which Agentic Jobs target its repository.

Plans

When the work needs more than a single answer, Dispatch presents a plan: a title, a short summary, and an ordered list of steps. Each step is either:

An agent step — a specialist from your Agent Catalog, with a prompt, run as a child of the plan
A platform step — a CodeCargo action such as creating a policy or opening a pull request

Steps can be conditional: a step can be marked to run only when the previous steps succeed, only on failure, or always — so a plan can include cleanup or recovery steps that take over when an earlier step fails.

One caveat when chaining steps: a step that starts an Agentic Job run is fire-and-forget. The plan does not wait for the job to finish, and later steps cannot use the job's output.

Nothing in the plan executes until you approve it. While a plan is waiting for approval, you can remove a pending step — only pending steps can be removed, and at least one must remain. Only the plan's creator or an org admin can edit it.

Approving or Denying

The approval card shows the steps that will run and the result of a preflight check: Dispatch verifies that every step can run with the permissions of the person the plan runs as, and flags any step that can't. Approve plan stays disabled while a step is blocked. Remove the blocked steps (or ask Dispatch to revise the plan), then Approve plan or Deny. When you deny, you can attach a reason; it is recorded on the plan.

A Dispatch plan card with five steps. Preflight reports that the fraud-scoring step can't run because Jordan Lee lacks write access there, and Approve plan is disabled. — Each step can be removed with its ×. Here the preflight blocks the fraud-scoring step until it is removed.

If a step needs repositories that were not in the original scope, Dispatch pauses and asks you to allow those repositories before it continues.

Approvals also show up in the Activity pill and on the org dashboard, so you can decide without hunting through chat history.

The Waiting on you card on the org dashboard, listing two Dispatch plans that need approval with their step counts, authors, and age.

Denying is final for that plan — it cannot be edited or resumed afterward. If you want changes, tell Dispatch what to adjust and it proposes a new plan; a denied plan can also be rerun from plan history.

While a Plan Runs

Open the plan (Track progress on the card) to watch each step: its status, the agent that runs it, and its output once it finishes. The Timeline below records each step as it starts and finishes, and a step that launches an Agentic Job links to the run it started. You can Cancel a plan that is waiting for approval or already executing. Canceling before approval discards the plan; it is not the same as denying it.

A plan's page while it executes: two remediation steps completed with their output, the pull request step running, and the re-score step pending.

Plan History

From Dispatch, open Plan history at the bottom of the conversation list to browse org-wide history. You can filter by status or search by title. A plan is visible to you when you can access every repository attached to its run; plans with no repositories attached are visible to the whole organization.

The Plans page listing Dispatch plans with their status (completed, awaiting approval, failed, denied, canceled), step progress, who planned them, and when, with a search box and a status filter.

From a plan's detail page:

Action	When you use it	What happens
Rerun	The plan has finished (completed, failed, denied, or canceled)	Copies the plan, makes you the creator, and starts it from the beginning, parked on a fresh approval
Resume	The plan failed partway through	Continues from the first unfinished step as the original creator. Only the creator or an org admin can resume.
Cancel	Waiting for approval or executing	Stops the run

Rerun and resume always ask for a fresh approval before any step executes.

Nothing runs until a plan is approved, and a rerun or resume always goes back through approval.

Notifications

On a plan's detail page, the Notifications card lets you send that plan's updates to specific organization Slack channels, email addresses, or webhooks. Lifecycle events — needs input, step completed, completed, and failed — go to the destinations you pick. You can change the routing while the plan is running, and a rerun keeps the same destinations. Only the plan's creator or an org admin can edit the card.

To choose which Dispatch events you receive across plans, open the Dispatch section under Organization Settings → Notifications or Profile → Notification Preferences. Plan completions appear in the in-app bell by default; Slack, email, and webhooks for completions only fire if you select those channels. Step-completed progress is off until you turn it on.