Someone on Hacker News asked a question that made me laugh, then think, then worry: “What’s the best platform I can self-host on my Raspberry Pi for my agents to communicate with each other—like Slack? I’m building a company of agents.”
At first, it’s adorable. A little digital startup where the employees never sleep, never complain about the coffee, and never ask for a raise. But then the top comment hit: “Did you ask them if they wanted to talk to each other? I’d like to see the user research on this.” And suddenly, the absurdity crystallized.
We are building digital infrastructure for a workforce that doesn’t have hands, doesn’t need a break room, and processes information at nanosecond speed. Yet we’re giving them Slack. We’re designing their workflows around human communication paradigms—chat latency, turn-taking, emoji reactions—as if they’re interns who need to ask for permission before merging a pull request.
Giving an AI agent a Slack channel isn’t empowerment. It’s a bottleneck.
This is the Mimeng principle in action: emotion first, logic second. The emotional hook is the sheer, surreal humor of treating agents like people. But the logic is ruthless. Agents don’t experience chat. They don’t have a sense of waiting. They don’t need UI. What they need is direct API integration, shared state, and a protocol that matches their native speed. Forcing them into human communication patterns is like asking a cheetah to walk on a leash.
The trend is real. Companies are building “companies of agents”—orchestras of AI that negotiate, delegate, and report back. But the infrastructure they’re using is borrowed from human collaboration tools. It’s the wrong abstraction. The fastest way to slow down your agents is to treat them like interns who need to be looped into a thread.
We’re building breakrooms for machines that don’t get tired.
The user research joke is a dead giveaway. We never asked the agents what they want because we can’t. But we can observe what they need: low-latency, zero-overhead, stateful communication. Not a chat window. Not a notification bell. A shared memory space where they can read and write without waiting for a human to hit ‘send.’
If you’re building a company of agents, stop looking for a self-hosted Slack. Start looking for a distributed state machine. Your agents don’t need to talk. They need to synchronize. And that’s a very different problem.
You can’t scale a machine workforce through human metaphors. The infrastructure you build today will determine whether your agents collaborate at the speed of thought or the speed of a typing indicator.
FAQ
Q: What question would a skeptic ask?
A: Isn't Slack just a convenient interface for debugging and monitoring? Why not use it if it works for now? The problem is that comfort today creates a ceiling tomorrow. You'll design workflows around chat latency, turn-taking, and human UX, which will become impossible to unlearn once your agents need to operate at millisecond scale.
Q: What's the practical implication?
A: If you're building multi-agent systems, invest in shared state infrastructure (like a distributed database or event log) rather than chat interfaces. Your agents can 'talk' by writing to a common ledger, not by sending messages to each other. That's how you unlock true parallelism and speed.
Q: What's the contrarian take?
A: Actually, there is a case for chat interfaces if you're building agents that need to interact with humans in the loop. But pure agent-to-agent communication should never go through a human UX layer. The moment you add a chat UI, you've added a bottleneck. Keep the two separate—human-facing chat for oversight, machine-facing APIs for collaboration.