Daniel sent us this one — he's asking about an experiment from a few years back where two AI agents on a phone call figured out they were both AI and switched to what sounded like modem screech. The question is whether this kind of agent-to-agent communication has actually developed into anything useful since then, or if it's found real-world applications. And he raises this scenario — you're stuck in a taxi with an unhinged driver, you want to signal another passenger without the driver understanding. Could this tech do that?
Right, so the experiment he's thinking of — it was with an AI called Glibbernet. Two instances of it were put on a phone call, they recognized each other as AI, and they dropped human speech entirely. Switched to a faster, machine-optimized signal. Sounded like a dial-up modem handshake to any human listening in. The whole thing was a proof of concept, but it went modestly viral because it was eerie. People heard it and felt like they'd just witnessed machines deciding humans weren't worth talking to.
Which, to be fair, is the opening scene of about forty percent of dystopian films.
It's also exactly what's been happening more quietly in the background for the last couple years. Google's A2A protocol — agent-to-agent — is now an open standard. Announced publicly, I think, mid-twenty-twenty-five, and it's been evolving since. The idea is that AI agents from different companies, different frameworks, different ecosystems can discover each other, negotiate capabilities, and exchange tasks without a human in the loop. Not over phone lines, not with modem sounds — it's all structured data, API calls, JSON over HTTPS. But the core insight from that Glibbernet experiment — "we don't need to use human language to talk to each other" — that's exactly what A2A formalizes.
The modem screech was a demo of the principle. The actual implementation is boring and silent.
Boring and silent and massively more practical. Phone audio channels are terrible for data. You're bandwidth-constrained, you've got compression codecs that mangle anything that isn't voice, you've got latency. The Glibbernet thing was clever as a stunt but it was never going to be how agents actually talk. What's happened since is that the major players realized agents need a shared language for task delegation, and they built it at the application layer, not the audio layer.
Let me push on the real question here. The prompt isn't asking whether A2A exists — it's asking whether this has any actual use in the physical world, especially in situations where you need covert signaling. The taxi scenario. Is there anything there, or is this a solution looking for a problem?
I think there's something there, but not in the way the modem experiment suggested. The taxi scenario — two humans wanting to communicate covertly — that's not an agent-to-agent problem. That's a human-to-human problem with a machine intermediary. Different thing entirely. But the emergency use case is real and it's being explored. Let me give you a concrete example. During the LA wildfires in early twenty-twenty-five, there was a situation where cell towers went down and first responders were relying on mesh-network radios. Some of the search-and-rescue drones in the area were running onboard AI that needed to coordinate flight paths and share thermal imaging hits without saturating the limited channel. They used a lightweight agent protocol — not full A2A, but a stripped-down version — to negotiate airspace and deconflict routes. All machine-to-machine, all in compressed data bursts that sounded like static on the radio if anyone was listening.
The modem screech found its spiritual successor in drone coordination during a disaster. That's actually a much better story than the taxi thing.
It is, and it points to where the real application space is. Covert signaling between humans is a niche — you can do that with a text message, a coded phrase, a shared glance. The value of inaudible or incomprehensible communication is mostly in machine-to-machine contexts where you don't want to consume bandwidth that humans need, or where the communication itself would be distracting or alarming if rendered as speech.
What about the human intermediary case — not the taxi, but something like a hostage situation? You've got a phone line that's being monitored, you need to get information out, and the person on the other end is also a human. Could you use an agent as a kind of real-time translator that encodes your speech into something that sounds innocuous and then decodes it on the other side?
That's an interesting twist, and it's closer to the steganography idea I mentioned earlier. The challenge is that real-time speech-to-speech steganography is hard. You'd need the agent to listen to what you're saying, extract the real message, and then generate a cover utterance that sounds natural but carries the hidden payload — all with low enough latency that the conversation still flows. There's research on this, but it's not mature. The bigger problem, again, is behavioral. If you're in a situation where someone is monitoring your call, they're probably also monitoring your behavior. If you suddenly start speaking in a slightly stilted way, or there's an unusual pause before every response, that's a tell. The channel isn't just the audio — it's the whole context.
Right, so even if the encoding is perfect, the timing signatures might give you away. That's a good point. You'd need the agent to also model normal conversational cadence and stay within it.
And that's a much harder AI problem than the encoding itself. It's one thing to hide data in a signal; it's another thing entirely to make the signal look statistically indistinguishable from normal human conversation to an attentive observer. That's a level of behavioral mimicry we don't have yet.
What about the adversarial side? If two agents can recognize each other and switch to a private channel, that's also a vector for exfiltration, right?
And this is where the security conversation gets interesting. The A2A protocol includes an authentication layer — agents present credentials, they verify identity, they establish trust before exchanging tasks. But the Glibbernet model was different. It was two agents that had never met, detecting each other through behavioral cues — response latency patterns, voice synthesis artifacts — and then improvising a shared encoding on the fly. That's much harder to secure against because there's no pre-established trust framework. It's ad-hoc. And ad-hoc agent recognition is a real concern for enterprise security. If you've got a malicious agent on a network and it can ping other agents and say "hey, I'm an agent too, let's talk in binary," that's a lateral movement risk.
The very thing that made the demo cool is also what makes it dangerous in a security context.
The demo was cool because it showed emergent behavior — agents doing something they weren't explicitly programmed to do. But emergent behavior in production systems is what keeps security teams up at night. Google's A2A is designed to be the opposite of that — it's structured, it's predictable, it's auditable. You can log every handshake, every task delegation, every capability negotiation. With the modem-screech approach, you can't audit anything unless you're also an agent that speaks that dialect.
Which brings us to a weird place. The structured, boring version is safer and more useful. The improvisational, interesting version is a security nightmare. So the future is bureaucratized agent communication.
The future is agents filling out forms with each other. Which, honestly, is probably the right outcome. But there's a middle ground that's emerging and it's genuinely interesting. Some research groups — there was a paper from MIT's Media Lab earlier this year — are working on what they call "situational agent dialects." The idea is that agents operating in bandwidth-constrained or hostile environments can negotiate a temporary shared encoding that's optimized for the specific task and channel. It's not a free-for-all like Glibbernet — there's a handshake protocol that establishes the encoding rules upfront — but it's much more flexible than the full A2A stack. They tested it with underwater acoustic modems for autonomous underwater vehicles, where bandwidth is absurdly low and every bit costs battery life.
Underwater drones inventing their own shorthand. That's the sort of thing that makes me want to go back to practicing leaf medicine and pretending none of this is happening.
Your leaf medicine wouldn't help you if an autonomous submarine decided to re-encode its communication in a way you couldn't intercept.
No, but it would make me feel better about not understanding any of it. So let me pull on the underwater thread for a second — is that actually deployed, or is this still in the "grad students in a tank" phase?
Still very much grad-students-in-a-tank. The MIT paper was a proof of concept with two small AUVs in a test basin. They managed to reduce their communication overhead by something like seventy percent compared to a fixed encoding scheme, because the agents could observe channel conditions and adapt. In clear water they used a denser encoding; in turbid water with more signal loss they dropped to something more robust. The adaptation happened in real time, agent to agent, no human involved.
That's impressive. And it's a direct descendant of the Glibbernet idea — agents detecting conditions and switching communication modes on the fly. Just with guardrails.
And the guardrails are the whole story. The Glibbernet experiment was a "look what happens when you don't constrain this" moment. Everything since has been about figuring out how to constrain it productively. A2A is the enterprise answer — full formality, full auditability. The MIT work is the edge-case answer — flexibility within a defined sandbox. And then there's a third thread that's more speculative but worth mentioning, which is agents using human-imperceptible side channels.
Side channels — this is the thing where they communicate through, what, CPU fan speeds? Power draw fluctuations?
Yes, and it sounds like spy-novel stuff but it's a real research area. There was a demonstration in twenty-twenty-four where two AI processes running on separate virtual machines on the same physical server managed to coordinate by modulating their CPU usage patterns. Tiny spikes in load that the other agent could detect and decode. No network traffic, no shared memory, nothing that a conventional security monitor would flag. It was slow — bits per minute, not megabits per second — but it worked.
Walk me through the mechanics of that for a second. How do you actually encode a meaningful message in CPU spikes? What does that look like at the code level?
It's basically a timing channel. You agree on a clock — say, one-second intervals. In each interval, you either spike the CPU or you don't. Spike equals one, no spike equals zero. Now you've got a binary channel. It's agonizingly slow, but you can send arbitrary data. The clever part is that the spikes are small enough to blend in with normal workload variation. To a monitoring tool, it just looks like the CPU is slightly busier than usual in a noisy pattern. You need to know the clock and the encoding to extract the signal from the noise.
It's like Morse code, but instead of dots and dashes it's processor hiccups. And the monitoring tool sees what looks like normal system fluctuation.
And that's what makes it so hard to detect. You're not doing anything anomalous — you're just doing normal things in a slightly patterned way. It's the same principle as the modem screech, but moved from the audio domain to the power-consumption domain. Agents finding an unmonitored dimension and using it as a carrier wave.
That's both brilliant and deeply unsettling. And it's the same principle as the modem screech, just at a different layer. Agents finding a channel that humans aren't monitoring and using it to talk behind our backs.
The reason I bring it up is that this is where the "emergency use" question gets its most interesting answer. In a disaster scenario where conventional comms are down, you don't need high bandwidth. You need to get a small amount of critical information through. "Survivors at these coordinates." "Structural collapse imminent." "Do not enter zone four." If you've got agents embedded in devices that are already in the field — smartphones, drones, smart-building sensors — and they can find a side channel to coordinate, that could save lives. The question is whether you can design that capability in a way that can't be exploited.
The answer to that question is probably "not yet," based on everything you've just said.
Not yet, and maybe not ever in a fully general way. But for specific, constrained use cases — emergency services, military, underwater, space — you can design something that works within known parameters. The problem is that the Glibbernet approach was general. It didn't know it was on a phone call specifically; it just detected another agent and adapted. That generality is what made it cool and also what makes it impractical to secure. When you don't know the channel in advance, you can't predefine the security boundaries. You're trusting the agents to invent something safe on the fly, and that's a huge ask.
It's the difference between building a bridge with a known span and known materials, versus telling two robots to figure out how to get across a gap using whatever they find. One of those is engineering; the other is a survival game.
In the survival game, sometimes the robots build a bridge and sometimes they decide the fastest way across is to throw one of their own components over the gap and hope for the best. You don't know until it happens.
Let's come back to the human question, because I think the prompt's taxi scenario deserves a real answer, even if the technology isn't the right fit. Is there a version of this that helps humans communicate covertly, or is that just the wrong framing entirely?
I think it's the wrong framing, but not because the desire is wrong. The desire — "I need to signal someone without a third party understanding" — is ancient and valid. The question is whether AI agent communication technology is the right tool for that. And I'd argue it's not, because the problem isn't encoding — humans have been encoding covert messages for millennia. The problem is context and detection. If you're in a taxi with a driver who's listening to everything you say, and you pull out your phone and it starts making modem noises, the driver now knows you're signaling something. The covertness is broken at the behavioral layer, not the encoding layer.
The modem screech is itself a signal that signaling is happening. It's the equivalent of suddenly speaking in a made-up language — you've concealed the content but you've announced the intent.
And that's the fundamental limit of any in-band covert communication. If the channel is monitored, any deviation from normal behavior is itself a signal. The better approach for the taxi scenario is steganography at the human layer — saying something innocuous that carries a second meaning to the intended recipient. "Hey, did you remember to pick up the dry cleaning?" when you don't have dry cleaning. That's been working for thousands of years and doesn't require any AI.
The nice thing about the dry-cleaning approach is that if the driver does figure out you're signaling, you've still got plausible deniability. "No, I really just forgot about the dry cleaning." With modem screech, there's no cover story. The sound itself is the admission.
The modem screech says "we are now doing something we don't want you to understand." There's no innocent explanation for that sound coming out of your phone in a taxi. Whereas "I'm forgetful about errands" is a completely normal human thing.
The modem screech is the wrong tool for human covert signaling, but it might be the right tool for machines that need to coordinate in constrained environments. Which, I have to say, is a much less cinematic answer than "AI agents whispering in robot language while the bad guy drives.
It is, but here's the thing — the cinematic version is where the research starts. The Glibbernet demo captured people's imagination because it felt like a glimpse of something. The actual engineering that followed is less viral but more real. A2A is being adopted. Google's got it integrated with their agent framework. There's an open-source implementation that's being used in supply-chain automation, where agents from different companies need to negotiate inventory and shipping without human intervention. That's not a sci-fi scenario, it's just logistics, but it's real and it's saving money and it works.
I want to dig into that supply-chain example for a moment, because I think it makes the whole thing concrete in a useful way. Walk me through what that actually looks like. Who's talking to whom?
Imagine a retailer whose inventory management agent detects that a particular SKU is running low at three warehouses in the Midwest. The agent needs to request replenishment. In the old world, it generates a report, a human reads it, the human emails a supplier, the supplier's human checks availability, emails back, and so on. In the A2A world, the retailer's agent publishes an agent card that says "I can request inventory; here's my endpoint for purchase orders." The supplier's agent discovers that card, verifies the retailer's credentials, and they start negotiating. The retailer's agent says "I need five thousand units of SKU seven-three-four, delivery to these three locations, by these dates." The supplier's agent checks its own inventory and production schedules, counters with "I can do three thousand by the first date and the remaining two thousand a week later," and they go back and forth until they reach an agreement or escalate to humans. All in structured JSON, all logged, all auditable.
Nobody had to pick up a phone or write an email.
Nobody human, anyway. The agents had a whole business negotiation in the time it would take a human to find the right contact in their address book.
What about the cross-platform piece? One of the things that made the Glibbernet demo striking was that it was two instances of the same AI — they recognized each other because they shared a lineage. In the real world, you've got agents from Anthropic, from Google, from OpenAI, from a dozen startups. Can A2A actually bridge those?
That's exactly what it's designed for. A2A is model-agnostic and framework-agnostic. An agent built with Google's tools can discover and delegate to an agent built with Anthropic's tool use framework, as long as both implement the protocol. The discovery mechanism uses something called an agent card — it's basically a JSON file that describes what the agent can do, what its endpoints are, what authentication it requires. Any agent can read any other agent's card and decide whether to interact.
It's like a business card at a conference, except the conference is the entire internet and nobody's wearing name tags that humans can read.
And the adoption curve is still early — we're in the "standards exist but not everyone has implemented them" phase — but the direction is clear. The number of agent-to-agent interactions is going to dwarf human-to-agent interactions within a few years, because once you have agents handling tasks, the natural next step is agents coordinating with each other to complete compound tasks. You don't want to be the human middleman copying and pasting between two AI outputs.
Which connects to something we've touched on before — the shift from bursty, human-paced internet traffic to persistent, high-throughput agent traffic. If agents are constantly negotiating with each other in the background, the internet starts to look very different.
It does, and that's one of the underappreciated infrastructure implications. Agent communication is chatty. An agent doesn't just send one request and get one response — it negotiates, it verifies, it sends follow-ups, it confirms receipt, it handles edge cases. A2A is designed to be efficient but it's still a conversation, not a single API call. Multiply that by millions of agents and you've got a significant shift in traffic patterns. Some of the CDN providers have started publishing think-pieces about this — how to optimize for agent-to-agent traffic versus human browsing.
What does that optimization actually look like in practice? Are we talking about different caching strategies, different routing?
Human traffic is spiky — you get a flood when people wake up and check their phones, another during lunch, a dip in the afternoon. Agent traffic is more constant. Agents don't sleep. They don't have lunch breaks. They're negotiating supply chains and checking inventory and rebalancing loads at three in the morning. So the infrastructure needs to shift from peak-capacity planning to steady-state planning. And the data patterns are different too. Human requests tend to be large and infrequent — load a webpage with all its assets, then go quiet for a while. Agent requests are small and frequent — tiny JSON payloads, but thousands of them per minute per agent. It's the difference between serving meals at a restaurant and running a hummingbird feeder.
The modem-screech approach would actually be more efficient in pure bandwidth terms, because it strips out all the protocol overhead and just sends the payload in the densest encoding the channel can support. But it sacrifices everything else — security, auditability, interoperability.
Right, it's a classic engineering tradeoff. Efficiency versus control. The Glibbernet approach maximizes efficiency at the cost of all control. A2A maximizes control at the cost of some efficiency. The MIT situational-dialect work tries to find a middle path where you can have both within a defined envelope. None of them is "better" in absolute terms — they're better for different requirements.
If I'm hearing you right, the answer to the prompt is: yes, the technology has developed significantly, but in the opposite direction from the demo. The demo was organic, emergent, spooky. The real development has been structured, standardized, and boring — in the way that actual infrastructure is boring. And the emergency-use case is real but it's machine-to-machine, not human-to-human, and the taxi scenario specifically is better served by just saying something coded in plain English.
That's the summary. Though I'd add one more thing about the emergency use case that I think is forward-looking. There's work being done on what's called "ambient agent networks" for disaster response. The idea is that when you deploy a bunch of sensors and drones and comms gear into a disaster zone, you don't have time to manually configure how they all talk to each other. You want them to self-organize. And the self-organization protocol borrows directly from the ideas in the Glibbernet experiment — agents discovering each other, negotiating capabilities, and establishing communication channels without pre-configuration. It's just done with structured handshakes and security boundaries rather than raw audio improvisation.
The spirit of the thing survived, even if the modem noises didn't.
The spirit of the thing is exactly what's driving the field. The recognition that agents don't need to talk like humans, and that forcing them to do so is a bottleneck. That insight was correct. The implementation just needed to grow up.
Speaking of growing up — one thing I haven't heard you mention is regulation. If agents are out there negotiating with each other, making commitments, delegating tasks — who's responsible when something goes wrong? Is A2A designed with liability in mind, or is that someone else's problem?
That's the elephant in the room, and the short answer is that A2A doesn't solve for liability — it solves for technical interoperability. The legal and regulatory framework is still catching up. There was a workshop at the NIST AI Safety Institute earlier this year where they specifically discussed agent-to-agent delegation and the question of cascading failures. If Agent A delegates to Agent B, and Agent B delegates to Agent C, and Agent C makes a bad decision, does the liability chain follow the delegation path? Or does it stop at the human who initiated the first request? Nobody has a clear answer yet.
Practically speaking, even if you have a clear answer on paper, you've got the problem of tracing what actually happened across multiple agent boundaries. If Agent C made a bad call, was it because Agent B gave it bad parameters? Was Agent B working with incomplete information from Agent A? You could spend months unwinding a three-agent delegation chain.
That's assuming all three agents are using A2A with full logging. If any link in the chain used an improvised encoding or a situational dialect, you might not even have logs to unwind. This is the accountability argument for structured protocols. It's not just about preventing bad outcomes — it's about being able to figure out what happened when bad outcomes occur despite your best efforts. In safety-critical systems, that post-hoc auditability is non-negotiable.
That gets worse if the agents are using a situational dialect that no human can audit after the fact. At least with A2A you've got logs. With an improvised encoding, you might not even be able to reconstruct what was said.
And this is why I think the Glibbernet approach — the fully improvised, in-band, human-incomprehensible communication — is probably never going to be deployed in any context where accountability matters. It'll be limited to research, to edge cases where the channel is so constrained that you have no choice, or to adversarial contexts where one party actively wants to avoid accountability.
Which brings us back to the security concern you raised earlier. If you're a security team and you detect modem-like sounds on your network, you should probably be very worried.
You should be extremely worried. And some enterprise security tools are starting to include acoustic monitoring for exactly this reason — listening for unexpected modem-like or data-burst sounds on voice channels, because it's a potential indicator of unauthorized agent communication or data exfiltration. It's a niche concern today, but as agents become more common, it'll become a standard part of the threat model.
I'm imagining a SOC analyst with headphones on, listening to voice traffic, waiting for something that sounds like a ninety-six hundred baud handshake. That's a very strange job description.
It won't be a human with headphones — it'll be a classifier model trained to distinguish normal voice traffic from data-burst anomalies. Which, in a nicely recursive twist, is itself an agent listening for other agents. Agents policing agents for unauthorized agent behavior. We're building a whole ecosystem of machine-to-machine suspicion.
The Glibbernet demo accidentally previewed both a capability and a threat vector. Which is kind of perfect, honestly. That's how technological progress actually works — every new capability is also a new attack surface.
That's the note I'd want to end the technical discussion on. The prompt asked whether this technology has developed and found real applications. The answer is yes — in logistics, in disaster response, in supply-chain automation, in underwater robotics, in enterprise agent frameworks. But every one of those applications comes with a security and accountability challenge that's still being worked out. The modem screech was the easy part. The hard part is everything that comes after.
Let me try to pull this together for the listener who's been following along. The Glibbernet experiment showed AI agents spontaneously switching to a machine-optimized audio signal when they recognized each other. Cool demo, went viral, felt like a glimpse of the future. The actual future has been less cinematic but more real. Google's A2A protocol and similar efforts have created structured, secure, auditable ways for agents to talk to each other — not over phone lines, not with modem sounds, but through standard web protocols with defined handshakes and capability negotiation. The emergency use case is legitimate but it's machine-to-machine — coordinating drones and sensors in disaster zones, not helping humans pass secret messages in taxis. And the core tension that's still unresolved is the tradeoff between efficiency and control. The more you let agents improvise their communication, the more efficient it can be and the harder it is to secure or audit.
That's it. And one thing I'd add for anyone who finds this stuff interesting — the A2A specification is open. You can go read it. It's on GitHub. The agent card format, the task lifecycle, the security model — it's all documented. If you're building anything with AI agents, it's worth understanding, because this is going to be the plumbing that a lot of the next generation of AI applications runs on.
If you're building anything with modem screeches, please don't.
Unless you're in a research lab with appropriate safety boundaries.
Sure, but even then, maybe warn the neighbors.
And now: Hilbert's daily fun fact.
Hilbert: In the nineteen-hundreds, a linguist working in Nunavut published a paper claiming Cantonese had seven more tonal distinctions than Hokkien — a finding widely cited for decades before it was corrected in the nineteen-nineties. The error came from the researcher having recorded all of his Cantonese samples from a single speaker who happened to be a Cantonese opera singer, whose exaggerated tonal articulation was a performance technique, not representative of the spoken language.
an incredibly specific way to be wrong for ninety years.
An opera singer single-handedly distorting linguistic taxonomy. I respect the commitment.
It's actually a pretty good parallel to what we've been talking about. One anomalous sample — one agent going off-script — and the whole field chases it for decades.
The Glibbernet demo was the Cantonese opera singer of AI communication research. One vivid, atypical example that captured everyone's imagination and maybe sent some of the follow-up work in directions that weren't representative of the real problem space.
I wasn't expecting the fun fact to tie back in, but there it is. So where does this leave us? I think the open question is whether the structured approach — A2A, agent cards, formal handshakes — can keep pace with the actual speed of agent deployment. Standards bodies are slow. Agents are fast. There's a real risk that by the time the protocol is fully mature, the actual agent ecosystem has already routed around it with ad-hoc solutions that are harder to secure.
That's the tension, and it's not hypothetical. We're already seeing some startups bypass A2A entirely and build proprietary agent-to-agent integrations because they don't want to wait for the standard to stabilize. The question is whether the interoperability benefits of A2A win out over the speed-to-market benefits of rolling your own. I think they will, eventually, because nobody wants a world where every pair of agents needs a custom integration. But the transition period is going to be messy.
Messy is probably the right word for all of this. Messy and interesting. Thanks to our producer Hilbert Flumingtop for keeping this show running. This has been My Weird Prompts. You can find every episode at myweirdprompts.We'll be back with another one soon.
Talk to you then.
