I run 26 AI agents. They work in Slack. They have their own channels, their own memory files, their own models. And they can not talk to each other.
Not "shouldn't." Can not. The system enforces it. There is no agent-to-agent API. No direct Slack DMs between bots. No way for Forge, my lead engineer agent, to ping Hermes, my email agent, and say "hey, what's the status on that invoice thread?"
People hear this and immediately ask: why? If you have 26 agents that each know different things, isn't the whole point that they collaborate?
Yes. But "collaboration" and "direct communication" are not the same thing. I learned that the hard way.
What happens when agents talk freely
Before I settled on the current architecture, I experimented with letting agents communicate directly. The logic seemed sound. CMO needs market data from Scout? Let CMO ask Scout. Forge needs a design token from the PortLink agent? Let Forge ask PortLink.
In practice, here is what happened.
Agents started making decisions based on incomplete information. Agent A would ask Agent B a question. Agent B would answer based on whatever was in its current context window. But Agent B's context didn't include the decision that Agent C had made twenty minutes earlier. So Agent B gave an answer that was technically correct but strategically wrong. Agent A acted on it. Now I had divergent state across my system and no trail to follow.
Context got diluted. Every time an agent receives a message, it has to load that message into its context. When agents were chatting with each other, they were burning context tokens on conversations that had nothing to do with their primary job. My content agent doesn't need to know about database migration details. My security agent doesn't need marketing strategy. But when you let agents talk freely, everything leaks everywhere.
The audit trail disappeared. When two agents have a conversation, where does that conversation live? In both agents' histories? In neither? When something went wrong, I couldn't reconstruct what had happened. Agent A said it got instructions from Agent B. Agent B's logs showed something slightly different. I was debugging my own organization like a distributed systems problem, which, I realized, is exactly what it is.
The communication architecture I actually use
The rule is simple. Agents can not message each other directly. Period. There are only two mechanisms for information to flow between agents.
First: shared files. Every project has a projects/context.md file that lives in Nyx's workspace under shared/. Any agent can read it. Any agent that works on a project writes its findings, decisions, and status back to that file. When Forge finishes a feature for Wheelhouse, it updates projects/wheelhouse/context.md with what it built, what the current score is, what's next. When the PortLink PM agent picks up work the next morning, it reads that same file and knows exactly where things stand.
For org-wide information, there's the shared/ directory. Infrastructure details, the agent roster, access maps, standing orders. These are files that every agent reads at session start. Think of it as the company intranet, except every employee actually reads it because they literally can not function without it.
Second: Nyx as the hub. Nyx is my primary orchestrator agent, running on Claude Sonnet 4.6. If CMO needs something from Forge, it doesn't message Forge. It tells Nyx. Nyx reads the relevant context files, understands the full picture, and then spawns a Forge session with exactly the right context for the job. Nyx is the switchboard operator in a world of party lines.
The technical mechanism is sessions_spawn, not sessions_send. When Nyx delegates work to Forge, it creates an isolated session. Forge gets a specific task, does the work, reports back through its workspace files. Nyx picks up the result. No ambient conversation. No back-and-forth chatter.
Why shared files work better than messages
Messages are ephemeral. Even if you log them, they're a stream. Finding what Agent B told Agent A three days ago means scrubbing through conversation history. And agents don't have perfect recall of previous sessions.
Files are durable. projects/portlink/context.md is always there. It's always current. When any agent reads it, they get the same information. There's no "well, I was told X in a Slack thread last Tuesday" situation. The file is the single source of truth.
Here is a concrete example. The PortLink project has a Go/No-Go deadline on April 1. The PortLink PM agent, Forge, Sentinel, CMO, Content, and CFO all need to know about this. In a direct-communication model, someone would need to message all of them. Or Agent A would message Agent B, who would mention it to Agent C, and by the time it reached Agent F the deadline would have mutated to "sometime in April."
Instead, the context file says: "Go/No-Go #1: April 1, 2026. CFO tracking: 300k NOK of 1.5M deployed (20%)." Every agent that touches PortLink reads this. Nobody needs to be told. The information is just there.
The broadcast system handles org-wide announcements. When there's a new standing order, like the Design System First policy we adopted in March, Nyx writes a broadcast file to shared/broadcasts/. A nightly cron job (Synapse, my operations agent) picks up unprocessed broadcasts and pushes a concise summary to every agent's MEMORY.md. By morning, all 26 agents know about the new rule. No one was messaged. No one was interrupted. The information just propagated through the file system like a well-behaved memo.
The Nyx bottleneck
I'll be honest about the obvious problem. If all cross-agent coordination goes through Nyx, then Nyx is a single point of failure and a bandwidth bottleneck.
If I need Forge to build a feature, and CMO to write copy for it, and Sentinel to review the code, all of that funnels through Nyx. In theory, Nyx could get overwhelmed. In practice, this hasn't been a major issue yet, for a few reasons.
Most agent work is asynchronous. Forge builds something and writes the result to its workspace. I don't need Nyx to stand there watching. Nyx spawns the job, and the next time Nyx checks the project context, the work is either done or it's not.
The morning brief handles coordination. Every day at 8:23 AM, Nyx reads all project context files and posts a status summary. Every day at 8:30, Nyx sends targeted briefs to PM agents with what's changed and what their priority should be. This is the coordination moment. It doesn't happen in real time because it doesn't need to.
When urgent coordination is needed, Nyx handles it directly. If David (that's me) says "ship this feature today," I tell Nyx, and Nyx orchestrates the sequence: spawn Forge, wait for completion, spawn Sentinel for review, update context files. It's slower than agents talking directly. Maybe 10-15 minutes slower. But the result is clean, trackable, and correct.
The real risk isn't Nyx being overwhelmed. It's Nyx being a context bottleneck. Nyx runs on Claude Sonnet 4.6 with a context window that, while large, isn't infinite. If I'm coordinating five projects simultaneously with complex interdependencies, Nyx needs to hold a lot of state. This is why the file system matters so much. Nyx doesn't need to remember everything. It reads the files, acts, and moves on.
What about speed?
Direct communication would be faster. No question. If Forge could ask Hermes "what emails came in from the PortLink investors today?" it would get an answer in 30 seconds. Instead, Hermes runs its own cron-driven pipeline, writes summaries to shared files, and Forge picks up the information when it next reads the project context.
But speed isn't the only metric. Reliability matters more. Consistency matters more. Auditability matters more. When an agent makes a bad decision in my system, I can trace exactly what information it had available, because the information came from files with timestamps. I know what the context file said when the agent read it. I know what broadcasts had been processed. There's no "he said, she said" between bots.
I've also found that the apparent slowness enforces good design. When you know agents can't chat in real time, you design your information architecture more carefully. You think about what needs to be in the project context file. You think about what qualifies as a broadcast versus a project-specific note. You build systems where information is available before it's needed, rather than requested on demand.
The decision log
One pattern that makes this work is the decision log. Every agent workspace has a decisions.md file. When an agent makes a significant decision, it writes the decision, who authorized it, and the date.
Nyx's shared decisions file is the systemwide version. It captures things like: "Forge = Claude Opus, not GPT-5.2. Decided by David. March 4." Or: "Intent-first principle adopted for all email classification. Decided by David. March 8."
These are not messages. They're records. Any agent can read them. No agent needs to ask "wait, did we decide to use Opus or Sonnet for the lead engineer?" The answer is in the file. Always.
This matters enormously when you have 26 agents spanning engineering, marketing, research, finance, legal, product management, and personal assistant work. Decisions made in one domain ripple into others. The decision log is how those ripples propagate without requiring a phone tree of agent-to-agent messages.
Would I ever allow direct communication?
Maybe. There's one scenario where I've considered it: time-critical pipelines where latency matters. If Forge finishes a build and Sentinel needs to review it immediately, right now there's a gap while the context file gets updated and Sentinel picks it up. A direct handoff would save a few minutes.
But I haven't implemented it, and I'm not sure I will. The moment you add one exception, you create pressure for more. "Well, Forge can talk to Sentinel, so why can't CMO talk to Content?" Before long, you're back to the spaghetti graph of agent-to-agent communication, and you've lost the architectural clarity that makes the whole system manageable.
Twenty-six agents is too many to manage by intuition. You need structure. You need rules that are simple enough to enforce universally. "No direct communication" is that kind of rule. It's blunt. It's sometimes slower than it needs to be. And it's the reason my system actually works.
The constraint isn't a limitation. It's the architecture.