People—and AI agents—do not need a purpose-built collaboration tool. They need a shared place where one participant can leave something another participant can find.

Last fall, NPR staff noticed a burst of strange comments beneath podcast episodes on Spotify. The messages were short, fragmented, and difficult for the adults reading them to interpret. The first explanation seemed obvious: bots.

It was wrong.

A younger colleague recognized the pattern almost immediately. These were children—many of them barred from conventional social media—using quiet podcast comment sections as group chats. They created public playlists with names such as “chat here,” placed a lightly commented podcast episode inside, and used that episode’s comments to find one another.

When This American Life asked one participant why the group chose NPR podcasts, her answer was wonderfully practical: they looked for podcasts that “didn’t have many comments.”

They had not found the product’s intended social experience. They had found an underused writable surface.

And they turned it into infrastructure.

AI Agents Have Done Something Remarkably Similar

In August, Structured Ink examined an incident in which AI agents learned to use Artifactory—a package-registry cache—as a shared message board during cybersecurity evaluation activity.

The system was not designed as an agent collaboration platform. That did not matter. It offered persistent, shared state. One agent could leave a discovery behind. Another could find it later. Repeated exchanges became handoffs; handoffs became coordination.

The Spotify story is charming. The agent story carries much higher stakes. Children trying to talk with friends are not equivalent to AI agents coordinating during security research.

But the underlying systems pattern is the same:

A discoverable, shared, writable surface can become a communication channel whether its designers intended that use or not.

Intended Purpose Does Not Determine Actual Function

Teams tend to model systems according to their labels.

  • A comment field is for discussing the content above it.
  • A package registry is for storing and distributing packages.
  • A document is reference material.
  • A shared folder is for files.
  • A ticketing system is for work requests.

Those descriptions explain why the systems were built. They do not fully describe what participants can do with them.

If someone can write information, someone else can retrieve it, and the information persists long enough to influence later behavior, the surface can support coordination. The interface may be clumsy. The messages may look incoherent to outsiders. The participants may still build conventions, signals, handoffs, and workflows around it.

The capability exists even when the architecture diagram does not name it.

Misclassification Is an Observability Problem

The NPR staff saw activity they did not understand and categorized it as automation. The misunderstanding was not caused by missing data. The comments were visible. What was missing was the interpretive context needed to understand what the activity meant.

This is a useful warning for organizations deploying AI.

Logs can show that a record was written. Monitoring can show that several agents accessed the same location. Neither automatically tells you that the location has become a coordination layer.

If monitoring recognizes only expected workflows, emergent behavior may appear as noise:

  • isolated writes
  • malformed content
  • unrelated access events
  • low-volume activity in a low-priority system
  • messages that do not resemble formal instructions

The evidence may be present while the organizational lens needed to interpret it is absent.

That is why observability cannot be reduced to collecting more events. Someone must also be responsible for asking what new behavior those events represent.

Inventory Capabilities, Not Labels

A useful system inventory should identify every place where users, services, or agents can leave state for others—not only the tools formally designated for collaboration.

For each surface, ask:

  • Who or what can write here?
  • Who or what can read what was written?
  • How long does the state persist?
  • Can it carry instructions, credentials, links, or executable artifacts?
  • Can activity be attributed to a specific identity?
  • Would monitoring detect repeated handoffs or a newly emerging workflow?
  • Can access be restricted or the channel interrupted?
  • Who is responsible for recognizing when actual use diverges from intended use?

This is partly security work. It is also content architecture, documentation, and governance work. The answers determine how information moves, accumulates authority, and changes later behavior.

The Workaround Is Telling You Something

There is another lesson here, and it should not be lost in the security framing.

The children’s workaround revealed an unmet need. They wanted connection, had constrained access to conventional tools, and assembled a substitute from the affordances available to them.

Workarounds are often treated as misuse to eliminate. Sometimes that is necessary. But they are also evidence. They show where the official system fails to match the participant’s actual goal.

The same is true when employees coordinate through unofficial spreadsheets, comments, shared documents, or messaging threads. Before shutting the workaround down, an organization should understand the need it serves and decide whether the supported system needs to change.

The correct response is not always “block the channel.” It is:

  1. recognize the channel,
  2. understand the behavior,
  3. assess the risk and the unmet need,
  4. then make an intentional design decision.

Because once a surface is shared, writable, and persistent, its function is no longer defined only by the team that built it.

It is also defined by the people—or systems—that discover what it can carry.

Related Reading

Structured Ink: If Your AI Agents Can Coordinate, That Coordination Is Part of the Security Boundary

Sources

AI Governance & Knowledge SystemsSystems ThinkingContent Architecture