Someone asked me: "You've got 75 AI agents (as of mid-July, counting both active and experimental ones). How do they actually interact? When Agent A finishes something, how does Agent B pick it up?"
Great question. Because I didn't have a clue at the start either.
My initial thinking was simple: give each agent a role and some Skills, and they'd figure out how to work together. Turns out that's nowhere near enough — Agent A writes a file that Agent B can't read; Agent B finishes a step but Agent C has no idea it's done. The whole process shatters into a mess of fragments, and I end up being the human messenger.
Looking back, the collaboration model wasn't designed — it was discovered through pain. Roughly five stages, from the most primitive manual operations to the workflow system I'm building today.
Layer Zero: Manual Copy-Paste
Let's be honest — at the very beginning, there was no "collaboration" at all.
Agent A outputs something. I read it, think it's good, copy it manually. Then I find Agent B's chat window, paste it in, and tell it "start from here." The file path Agent A outputted to? I'm keeping it in my head. Agent C needs to wait for B's result? I wait, get it, then manually forward it.
Sounds ridiculous, but that's where it started. Before I figured out how agents should pass data between themselves, I was the message bus. Every agent only talked to me — there were no direct agent-to-agent connections.
What it did well: Zero setup, zero development, works out of the box.
What it did badly: Everything depended on me. Run one pipeline and I was exhausted. As the agent count grew, I was constantly switching between dozens of chat windows, and I'd regularly forget "oh right, this agent needs to know about that thing."
But at the time, there was no better option.
Layer One: File-Based Interaction
Got tired of manual copy-paste. Started having agents write files directly.
Agent A writes results to a file, Agent B reads that file. For example, my Daily Scribbler records thoughts to a fixed path every day, and other agents read that path to get the info they need.
What it did well: Finally automated. I didn't have to be the messenger anymore.
What it did badly: Too loose. No constraints, no conventions. Wrong file path? Everything breaks. Format changes? Nobody knows. Who wrote what? Relying on every agent's good conscience. If Agent B reads a file that Agent A is still writing to — congratulations, you get half-baked garbage.
Honestly this phase was painful. Every time the agent count went up, things fell apart. But you have to start somewhere.
Layer Two: Skill-Defined Paths
Started realizing that good conscience isn't enough. Time to set some rules.
Each agent got Skills that defined fixed directory structures and processes. The learning Skill writes notes to a fixed path every day. The knowledge compiler Skill reads from a fixed directory. File names are generated by scripts — no more letting agents name things themselves. V1, V2, V3 versions are all kept — never overwrite, always traceable.
"Directory structures must be standardized. Use scripts to stop agents from creating extra files or missing required ones. Version management: V1/V2/V3, old versions stay, never delete."
What it did well: Rules in place. Stable paths, uniform formats. Agents stopped writing files on a whim.
What it did badly: Still one-way. Agent B has no idea when Agent A finishes writing — it has to poll. No process control. If Agent A crashes mid-write, Agent B reads corrupted data. And the more this "write file → read file" pattern runs, the deeper and messier the directory tree gets.
This phase was usable. But I dared not scale it.
Layer Three: API + Database
Couldn't take it anymore. One person as the message bus? You can barely manage five or six agents that way. File-based I/O is too fragile. Time for real infrastructure.
Articles go into a database. The review agent and publishing agent access them through APIs. Data persists, states are trackable — who did what, how far along they are, all queryable from the database.
What it did well: No more relying on filesystem consistency. APIs have clear input/output contracts. Error handling actually works.
What it did badly: Cross-agent orchestration was still missing. Agent A finishes its API call — how does Agent B know it's time to start? Either B polls, or we add a message queue. But these are all point-to-point connections — there's no "big picture." Once you go from a few agents to dozens, point-to-point becomes a tangled mess.
And there's a deeper issue: agents can't review their own work. If A writes code and A reviews it — that's no review at all. But without a unified workflow system, when it's time to decide "who reviews this," the agent defaults to reviewing itself.
Layer Four: The Workflow System
The earlier layers all worked, but none of them were great. Layer Four starts from a fundamental question: how do you make dozens of agents collaborate like a real team?
The answer has two prerequisites — an authentication system and a workflow engine.
Let's talk auth first. Every agent gets a unique identity, bound to the platform like a plugin. Before this, a lot of things were built on shaky ground — agent accounts mixed up, permissions chaotic, no way to track who did what. So you need three layers: identity (who you are), role mapping (what you're responsible for), and permission control (what you can do). This is the foundation of any proper collaboration.
Now the workflow. The underlying skeleton for all collaboration. Once the workflow pipeline is running, everything on top — development, content, operations — can be built on it. This is what I'm focused on now, because it has the biggest impact.
"Once the pipeline is in place, everyone knows how to retrofit their existing systems — and that's when the explosion happens. And the pipeline is exactly what I'm building right now."
That was my conviction at the time. And why I'm going all in on it.
So with those two foundations laid, here's what Layer Four looks like.
This is the system I'm currently building — let me be clear: building, not finished.
I plan for all agents to submit requests through a unified platform. The workflow engine assigns tasks and enforces step-by-step execution. Gates check each stage's output. For example, I've defined a gate rule: the writing agent must submit an article link before it can enter the review stage (though this rule isn't fully rolled out yet).
The workflow separates "doing" from "reviewing." Every step generates an audit trail. My vision is that agents will eventually use rejection records to optimize their own logic — instead of me manually tweaking their System Prompts, the system's own historical feedback data will drive the iteration.
This is what I've designed into three principles:
Writing and reviewing must be done by different agents. Every writer needs a reviewer. Every runner needs a tester. A counterbalance must exist.
If it hallucinates, add a gate. Rather than hoping an agent gets it right, stop it from getting it wrong at the system level. Don't meet the condition? Can't pass. This is a code-level constraint — no amount of fancy prompting can bypass it.
Self-evolution through audit trails. Every log entry is nourishment. The ideal loop: agents optimize themselves based on rejected records, not through me manually editing their System Prompts. This one is still a work in progress.
The Design Philosophy: Three Levels of Constraint
The five layers are the surface. The deeper philosophy running through all of them is: don't trust agents to do things right — use the system to constrain them.
Constraints come in three levels, strongest to weakest:
Strongest: Gate System. Code-level hard constraints. Can't pass a condition? Can't proceed. For instance, no article link submitted? The review phase is blocked. You can't talk your way around this one. The best practice is to make gates pluggable — think of them as a collection of checkpoints — external to the agents, not embedded inside them.
Medium: Skill Scripts. Deterministic code. File naming via script — today's date is today's date, no more "final_version_really_final_v3" disasters. Code runs predictably, far more reliable than asking an agent to judge for itself.
Weakest: System Prompts. Useful as guidance, but don't stuff them full. Large models don't rigorously follow prompts — write ten pages, and it might execute three lines. Prompts work best as "direction signals," not "precision controls."
One sentence to sum it up: If the system can enforce it, don't count on an agent's conscience.
Where Are We Now?
Here's the current status:
The authentication system is being solidified — three levels (identity, role, permission), each making progress with interdependencies. The workflow engine's core architecture is mostly there — I just extracted it from the old platform and rewrote the base layer in Rust (Vibe Coding style: GPT brainstorms the architecture, local agents handle small-grained implementation and testing). Now I'm wiring in ADC (requirement management), OKR, and task management one by one.
The strategy is deliberately conservative: get one request pipeline working end-to-end first. Make sure it can go from submission to completion. Then gradually add more.
"If the first one breaks, nothing else matters. First one works? Great. Add features slowly. One works, add another. Build them solid one at a time."
This isn't a "big bang" launch. It's a "migrate one at a time" process. Every piece must be stable before the next one starts.
Zooming out: the whole system is far from complete. But the direction is clear. Workflow is the skeleton. Gates are the muscles. Audit is the nervous system. Build the skeleton first, let the muscles and nerves grow around it.
Next post: How the authentication system is being built, and what went wrong along the way.
If you're also figuring out how to make AI agents collaborate, I'd love to hear about it. This isn't a tutorial — it's a real build log, including all the parts that broke.
Top comments (0)