How Do You Make Sure a Voice Agent Sends Work to the Correct Destination?

I sell cars for a living. Twenty years in automotive retail, no tech background, no computer science degree.

Last week I wrote about how a voice agent decides which lane a note belongs in. That post was about routing a voiced note to the right person automatically.

This one is the harder half.

Because deciding the right lane and actually delivering to it are two different promises.

You can pick the correct lane every single time and still send the work to the wrong place. The lane was renamed. The list got archived. The address behind it went stale and nobody noticed. The router did its job. The note still landed nowhere.

So here is the real question. Once your agent has decided a note is a parts note, how do you guarantee it reaches the actual parts destination and not a dead channel that used to be parts? That is destination correctness. This is how I made mine reliable, the address book, the bugs, and the fixes.

What does the correct destination actually mean for a voice agent?

It means the note reaches the exact place you meant, and you can prove it got there.

Routing is one promise. It says this note is a parts note. Destination correctness is the second promise. It says the parts note reached the real parts destination, the one that is live today, and it is sitting there right now.

Both promises have to be kept for the work to actually move.

Here is the trap. A router can be perfect and the delivery can still be wrong. The router labels the note a parts note. It hands it to the parts lane. But the address behind the parts lane points at a channel that got renamed three weeks ago, so the note goes into a channel nobody watches anymore. Routing succeeded. Delivery failed. The note is gone and everyone believes it was handled.

The correct destination is not a label. It is a live address that you verified points where you think it points.

That is the whole difference between a note that reaches the parts counter and a note that reaches a channel that used to be the parts counter.

What are the pieces that guarantee correct delivery?

Three pieces sit on top of the router. Each closes one way a note reaches the wrong place.

The address book. Every intent maps to exactly one concrete destination. Not a name a human reads. A real address the machine uses, like a channel id or a list id. The lane parts is a friendly label. The address behind it is the id the note is actually sent to. Keep the two separate, because labels change and ids are what delivery runs on.

The startup check. Before the agent takes a single note, it walks the whole address book and asks each destination if it is real and reachable. A missing address, a stale id, an expired token, all of it fails loudly at startup instead of quietly at delivery. You want to find out an address died when you start the agent, not three days of lost notes later.

The delivery confirmation. After the agent sends a note, it reads that note back out of the destination and matches it on an id it controls. Found means delivered. Not found means undelivered, and the note gets surfaced, not silently dropped. Sending is a request. Confirmation is the receipt.

How do you make destination correctness reliable, step by step?

Here is the order I built mine in. Each step closes one failure before you trust the next.

Step one. Write the address book as data, not code. List every intent and the one concrete destination id it maps to. Keep it in one place you can read at a glance. Parts goes to this channel id. Follow-up goes to this list id. Review goes to this id. When the address book is a plain table you own, a wrong destination is one line you can see, not a value buried in logic.

Step two. Verify every address at startup. Before the agent accepts any note, loop the address book and check each destination resolves to something live. If one does not, the agent refuses to start and tells you which address is dead. A stale destination should stop the agent, not misroute a note. Loud at boot beats silent at delivery.

Step three. Send with an id you control. When the agent delivers a note, attach a reference id you generated, not one the destination hands back. That id is how you will find the note again. Without your own id, confirmation is guessing which record is yours.

Step four. Read the note back before you report success. Right after sending, query the destination for your reference id. If the note is there, delivery is confirmed and you tell the operator it landed. If it is not there, the note is undelivered, and you surface it for a retry or a human. Never report a success you did not verify by reading it back.

Step five. Alert on a changed address instead of guessing around it. When the startup check or a confirmation finds a destination that moved, do not have the agent quietly pick a fallback. Have it stop and tell you the address changed. A voice agent guessing a new destination on its own is exactly how work reaches the wrong place with confidence.

What breaks when you deliver to a destination, and how do you fix it?

Three failures, in the order they hit me. This is the part the demos skip.

One. The renamed channel. I mapped a parts intent to a channel by name, someone renamed the channel, and every parts note after that went into a channel nobody watched. The routing was right. The address was stale. The fix is to map to the destination id, not the human name, and to verify that id resolves at startup. Names drift. Ids are stable, and a startup check catches an id that stopped resolving.

Two. The confident send with no receipt. The agent called the send, got no error back, and reported the note delivered. The delivery had actually failed downstream. No error is not the same as delivered. The fix is the read-back from step four. The agent does not trust the send call. It queries the destination for the reference id it attached and only reports success when the note reads back.

Three. The silent fallback to the wrong place. Early on, when a destination lookup failed, my code fell back to a default lane so nothing would crash. That felt safe. It was the worst one, because now wrong-destination notes piled up in a default nobody expected and never errored. The fix is step five. A missing or changed address stops the agent and alerts you. It does not quietly reroute work to a place you did not choose.

How do you keep this small enough to ship this week?

You harden one destination first. Not every lane you might ever have. One.

Pick the destination that matters most, the one where a lost note actually costs you. Give it a concrete id in your address book. Verify that id at startup. Send to it with a reference id you own. Read the note back before you call it delivered. Alert if the address ever stops resolving.

That is the whole v1 of destination correctness, and it is enough to trust one lane completely.

• Map the intent to a concrete destination id, never a human name.
• Verify the id resolves at startup, and refuse to run if it does not.
• Send with a reference id you generated yourself.
• Read the note back out of the destination and match on your reference id.
• Alert on a changed or missing address instead of falling back silently.

Run that for a week on one lane before you harden a second. A week of real notes tells you whether your confirmation actually catches a failed send, which it will, the first time a token quietly expires.

Only after that week do you harden the second destination. The address book and the confirmation you built first make each new one cheap, because adding a destination is a new id in the book and the same verify-and-confirm you already trust. That is the compounding that lets an operator stack grow. Five rivers, twenty-two agents, all built the same way, one verified destination at a time.

The reason to verify the address and confirm the landing, if you take nothing else from this build log, is that a note reaching the wrong destination is not a small bug. It is work lost while everyone believes it was delivered. The whole point of a voice agent is that a spoken note reaches the place that can act on it. Destination correctness is that promise, kept and proven.

When a note has to travel between tools to reach its destination, the delivery leans on the Model Context Protocol, the open standard for how an AI reaches a tool, and the id you send with and read back rides on that same layer. If you want a channel-id destination worked example, the Slack conversations API reference shows why you map to the stable id and not the display name, because the name can change while the id does not.

The community where operators ship these in public, bugs and all, is the free build log at skool.com/agent-empire-4291. Come make your first delivery land where you meant it. Build log, not a landing page.

While I sell cars for a living.

Michael