Agent-to-Agent Dispatch

The short version

Agent-to-agent dispatch is what happens when you stop putting a ticket between the customer signal and the build. A listening agent sits on your calls, tickets, and churn surveys and extracts the outcome a customer is reaching for. Instead of writing that up for a human to triage, it hands the brief straight to a prototyping agent, which builds a working prototype the same day. By the time you read the morning digest, the prototype is already attached. You review the extraction and the prototype, then decide: show it to the customer, iterate, or kill it. No backlog, no planning meeting, no handoff. The PM stops initiating work and starts editing it. The control that keeps this sane is not the ticket queue, it is the eval bar: most dispatched prototypes die, and the survivors graduate to engineering hardening.

The relay you didn't notice you were running

Walk the path a customer signal takes in most companies. A customer says something on a call. Someone clips it into a note. The note becomes a Jira ticket. The ticket sits in a backlog. Weeks later it gets groomed, estimated, prioritized against forty other tickets, and maybe scheduled. Then someone builds a first version, and only then does a customer see anything.

Every arrow in that chain is a human relay, and every relay adds latency and loses signal. By the time anyone builds, the outcome the customer actually wanted has been flattened into the feature someone wrote on the ticket. You optimized the queue and lost the point.

The anti-backlog already argues for burning the queue. Dispatch is what you run in its place. The relay collapses because the agents talk to each other.

How the handoff works

Two agents, one contract between them.

The first is the listening agent from Continuous Listening. Its job is not to log feature requests. Its job is to extract the outcome underneath them. A customer asking for a "CSV export button" is handing you a solution guess. The outcome is "get this data into my board deck without re-keying it." The listening agent records the outcome, tagged with the customer, the evidence, and how many others are reaching for the same thing.

The second is a prototyping agent. It takes the outcome brief and does what a builder PM would do in the two-hour prototype method: frames the problem, builds the core interaction, and deploys something a customer could actually click. It does not wait for you to ask.

The contract between them is the outcome, not the feature. That single rule is what makes the handoff worth automating. Feature requests fragment into a hundred one-off asks that no agent can build coherently. Outcomes collapse into a handful of jobs, and a job is something a prototype can go after in a dozen different ways.

What arrives on your desk

You do not wake up to a to-do list. You wake up to drafts.

The digest says: three enterprise customers are reaching for the same outcome, here is the evidence, and here is a working prototype that takes a run at it. Your job is to review, not to originate. Did the listening agent extract the real outcome, or did it capture the surface request? Does the prototype serve the outcome, or does it just implement the button somebody named? That review is the whole job now, and it is the same skill described in PM as Editor: reading the output the way a senior PM reads a team member's work, cutting what does not serve the purpose, and shipping the version that does.

Most mornings, the right call on a given prototype is to kill it. That is not a failure of the system. That is the system working. You spent an agent's time, not a sprint.

The eval bar is the control, not the queue

The obvious objection is that skipping the backlog invites chaos. It would, if the backlog were the thing keeping you honest. It never was. A four-hundred-item backlog is not control, it is institutional amnesia in tabular format.

The real control is the eval. A dispatched prototype does not ship because it looks good in a meeting. It graduates because it clears an eval bar that defines what good looks like, the same contract described in The Eval Is The Spec. Most prototypes never clear it, and that is the point. The eval decides what earns scarce engineering time, and the survivors get handed to engineers to harden, per the ledger in Old PM vs Product Builder. Dispatch makes the front of the funnel fast. The eval keeps the back of the funnel disciplined.

You cannot run this on bare ground

Dispatch is a loop, and a loop that writes and deploys code needs somewhere safe to run. An agent building unsupervised against production is not speed, it is a liability. What makes dispatch safe is the substrate underneath it: scaffolded environments an agent can build in, guardrails that bound what it can touch, an eval harness that scores the output, and isolated deploys so a prototype reaches a customer without ever touching the real system. Building that substrate is engineering's job in an AI-native org, and it is the precondition for everything on this page.

Start this week

You do not need the full loop to feel the shift. Wire the smallest version.

Take one listening agent you already trust and one outcome it reliably surfaces. When it fires, have it trigger a single prototyping run automatically, into a sandbox, and drop the result into your morning review next to the signal. Do not wire it to production. Do not let it ship anything. Just let one agent hand one brief to another, and put the result in front of your own eyes before your first meeting.

The first time a working prototype is waiting for you that you never asked anyone to build, you will understand why the ticket was the bottleneck all along.