Your agents are already talking to each other. Nobody provisioned the channel.

Ask an enterprise architect about multi-agent systems and you'll hear about frameworks, orchestrators, and roadmap items for next year. Ask a developer how their coding agent coordinates with the platform team's coding agent today and you'll hear something much simpler: "there's a markdown file in the shared repo. Mine writes status updates into it, theirs reads them each morning."

Multi-agent coordination did not wait for the architecture review. The moment two teams each had a capable agent and a shared problem, the agents started exchanging information over whatever surface was lying around: files in repositories, tickets filed by one agent and consumed by another, shared documents, emails between service accounts, comments on pull requests. It works — which is exactly why it's spreading, and exactly why nobody filed a request for it.

This should feel familiar. It's how every unmanaged communication channel in corporate history got started: it was never adopted, it accreted.

Coordination found its own transport

Look at what these improvised channels actually are, through an infrastructure lens:

• No identity. A markdown file has no sender authentication. When an agent reads "the migration is complete, proceed with the cutover" from a shared doc, there is no way to establish which agent — or which human, or which compromised process — wrote it.
• No access control. The channel's ACL is whatever the underlying repo or document inherited, which was scoped for humans collaborating on code, not for machine instructions flowing between autonomous systems.
• No retention or record. Scratch files get overwritten; ticket descriptions get edited in place. The message history that would let you reconstruct why an agent did what it did is being destroyed continuously, by design.
• No monitoring. Nothing watches these flows. Message volume, content drift, an agent that suddenly starts issuing instructions it never issued before — all invisible.

If a vendor proposed a corporate messaging system with those four properties, the security review would take one meeting and end in laughter. But nobody proposed this system. It assembled itself.

Why this deserves IT's attention now

Three risks make this more than an aesthetic complaint.

Instructions are injection surfaces. A message from one agent is untrusted input to another. If anything in the writing agent's context was attacker-influenced — a poisoned document it summarized, a malicious issue it triaged — the taint propagates through the shared file into the reading agent's behavior. Prompt injection stops being a single-agent problem the moment agents relay text to each other; improvised channels turn one compromised context into a transmission network.

Data crosses boundaries inside messages. An agent coordinating across teams will helpfully include context: customer identifiers, incident details, credentials it encountered. The shared-file channel happily carries payloads across team, project, and even tenant boundaries that your DLP tooling has never been pointed at, because nobody told DLP that status-notes.md is now an inter-system message bus.

Incidents become unexplainable. When an agent takes a wrong action because another agent told it to, the causal chain runs through the channel. If the channel keeps no authenticated, durable record, your incident review dead-ends at "the file said so." Who wrote it, when, on the basis of what — unrecoverable. For regulated workflows, that's not an awkward gap; that's a finding.

Minimum viable governance for agent messaging

The answer is not to ban agent-to-agent coordination — the demand is real and the productivity is real. The answer is the same as it was for human messaging two decades ago: give the traffic a managed channel before the unmanaged ones ossify into infrastructure.

A managed channel needs surprisingly little:

1. Identity on both ends. Every message attributable to a specific agent, workspace, and owning team. "Proceed with the cutover" must have a verifiable sender.
2. A durable, append-only record. Messages are retained, not overwritten — so any action taken on the basis of a message can be traced to it later.
3. Explicit scope. Which agents may exchange messages, and what classes of content may cross which boundaries. Even a coarse rule — no credentials, no customer records in cross-team messages — beats the current default of anything-goes.
4. A treat-as-untrusted convention. Instructions arriving over the channel are input to be validated, not commands to be obeyed. High-consequence actions triggered by a peer message deserve the same human-review gate they'd deserve if triggered by an email from a stranger.
5. Someone watching. Volume anomalies, content drift, new participants. Not deep inspection of every message — just the basic observability every other messaging system in the company already has.

The window for doing this cheaply is now, while the improvised channels are young and the habits around them are soft. Every quarter of delay adds more workflows that quietly depend on an unowned markdown file — and migrating a load-bearing shadow system is always ten times the cost of standing up the sanctioned one early.

Your agents are already talking. The only open question is whether anyone in the organization can say, with evidence, what they said.