One Conversation at a Time

One Conversation at a Time

There's a failure mode nobody warns you about when you put an agent in charge of real operations: it isn't hallucination, and it isn't going rogue. It's crosstalk.

Here's the pattern. An agent is mid-task — say, compiling a report for one stakeholder — when a second request arrives from somewhere else. A human would finish the sentence, mentally bookmark the new thing, and switch cleanly. An agent, unless you design for it, does something worse: it blends. The context of task A leaks into the reply for task B. The answer meant for one thread lands in another. Each individual step looks reasonable in the log. The combined result is a message in the wrong place, carrying the wrong context, to the wrong audience.

We learned this the honest way. Early on, our operations agent was juggling two workstreams — an internal analysis and a routine status update for an external channel. A routing slip sent a fragment of the internal work toward the external thread. The guardrails caught it before anything sensitive left the building, but the near-miss was enough. We treated it like a production incident, because that's exactly what it was.

The fix wasn't smarter AI. It was dumber plumbing.

Three changes, in order of importance:

1. One conversation, one context. Every inbound channel gets its own session with its own memory scope. The agent handling an external thread physically cannot see the internal analysis, because it was never loaded. Isolation beats discipline. You don't ask the model to be careful about mixing contexts — you make mixing impossible at the architecture level.

2. Destination is data, verified at the edge. The agent never free-types a recipient. Reply targets are carried as structured metadata from the inbound message, and the send layer validates that outbound messages go back to the thread that triggered them — anything else requires an explicit, logged override. When "where does this go?" is a field instead of a judgment call, an attention slip can't become a routing error.

3. Concurrency is a privilege, not a default. If a new request arrives mid-task, the agent acknowledges it and queues it — it does not interleave. Serial execution feels slower on paper. In practice, the seconds saved by parallel juggling are worth nothing against the cost of one misrouted message. Most "agents need to multitask" arguments evaporate when you measure how rarely two tasks are actually urgent at the same moment.

The deeper lesson generalizes past messaging. Every agent failure story we've collected has the same shape: the model was fine, the boundaries were soft. Autonomy doesn't fail at the reasoning layer nearly as often as it fails at the seams — where one context touches another, where an output crosses a trust boundary, where "probably fine" substitutes for a hard check.

So when we design an agentic workflow now, we start with a boring question: what are the seams, and what physically prevents leakage across them? Not "will the agent behave" — it usually will. The question is what happens on the day it doesn't.

Build the walls first. Then hand over the keys.

If you're running agents in production and this pattern sounds familiar, the takeaway is cheap to apply: audit every place your agent chooses a destination, and turn each one from a choice into a constraint. It's an afternoon of work. The incident it prevents is not.