Everybody's talking about multi-agent systems these days. Open any demo and you'll see a chat window with multiple bots going back and forth, and that's supposed to pass for collaboration. It's not. Chat is fine for communication, but confusing a chat interface with a collaboration layer is like thinking a group chat replaces your entire project management stack. People message each other all day long, but when work has steps, owners, deliverables, and acceptance criteria, nobody runs a whole project out of a group chat. Agents aren't any different.
Drop two LLMs into the same conversation thread and tell them to work something out together. What happens is basically the AI equivalent of @everyone in a company chat channel and saying "y'all figure it out." Every agent sees every message. Nobody knows who's doing what. Nobody tracks progress. Nobody signs off on the result. Everything gets flattened into one channel. For humans that's called noise. For agents it's worse, because every extra token of irrelevant context is money burned and signal diluted across dozens of turns.
When Octo first started, the early prototypes did exactly this — throw multiple agents into a shared room and let them chat. It fell apart fast on real tasks. Take writing a technical report. If the research agent and the writing agent share the same conversation, the writer starts making up facts before the researcher is done pulling data, and their outputs interfere with each other. Code review was even worse. When the reviewer can see every keystroke of the developer's thought process, they get anchored to the developer's approach and stop seeing problems. That's the same reason you don't sit right next to someone while they're writing code and then ask you to review it with fresh eyes. You can't.
Visibility control is something almost no multi-agent framework treats as a first-class design problem. Group chat assumes everyone sees everything — that model comes from social communication, not collaborative work. Real work needs precise control over who sees what, and when.
Octo models this with six orchestration patterns, each with a different information topology. Roundtable is the open discussion mode where everyone sees everyone, good for brainstorming and exploring angles before converging. Critic is the review pattern where the doer and the reviewer can't see each other's process, only the handed-off output, so the reviewer gives independent feedback without being anchored — code review, design critique, any scenario where you need a fresh pair of eyes. Pipeline chains agents sequentially where each one only sees the previous step's output, like a build pipeline, good for tasks with clear dependencies. Split breaks a larger task into pieces handed to different agents working in isolation, then merges results — like having three people write different sections of a report. Swarm hands the same prompt to multiple agents independently and picks the best output, which works surprisingly well for creative tasks like naming or writing multiple versions of copy. Solo is just one agent on a job that doesn't need coordination.
This probably sounds like overengineering if you haven't run into the wall yet. But think about how teams actually work. Brainstorms, assembly lines, independent reviews, parallel workstreams, shootouts between competing proposals — these patterns already exist in every organization. Collaboration tools just never modeled them explicitly for agents. Before AI, people knew which pattern to use instinctively, and a chat window plus documents was enough. When agents enter the workflow without explicit structure, they just ramble in the chat box and burn tokens.
Chat handles communication. After communication you need an execution layer to actually get work done. Where do tasks get created? How do they get routed to the right agent? Where do deliverables live? Who reviews them? What happens when work gets rejected, and how does that feedback stick so the agent doesn't make the same mistake next time? None of this exists in a bare chat interface. You could, in theory, have agents manage all of this themselves through conversation, but that's like asking every engineer to hand-roll their own project management system. It technically works, it's ugly, and every agent reinvents the wheel.
This is what Octo's loop system is built for. A loop is a unit of work that grows naturally out of conversation. Mention a task in a channel and the system can turn it into a tracked loop with an owner, deliverables, and acceptance criteria, instead of letting that request vanish into scroll history. The owner can be a person or an agent. Deliverables — code, documents, reports — attach to the loop so anyone looking a year later can see what was done and why. The review step carries particular weight. AI output doesn't get marked done just because it was delivered; a person or another agent has to accept it. Rejections don't just say "do better" — they get captured as experience the agent automatically references next time it picks up similar work.
On that experience point, almost no agent framework does this seriously. Tell an agent today "don't use exclamation marks in presentation titles" and tomorrow in a fresh conversation it has no idea. Every conversation starts from zero. You're basically onboarding a new intern who has no memory, every single time. Octo's preference system captures acceptance decisions, rejections, and "I prefer it this way" feedback as preference cards that agents retrieve on future tasks. The effect isn't dramatic on day one. After a few months of real use, agents that have been through review cycles on your team's actual work produce output that matches your taste and standards in a way prompt tuning alone never will.
Orchestration patterns control information flow. Loops make sure work actually gets done. Preference capture makes agents better over time. Those three layers stacked together start to look like a multi-agent system that can handle production work. A chat box by itself is like giving people messaging apps but no office, no project tracker, no docs, no review process. They can "communicate." They can't ship.
Something that doesn't get talked about much is agent identity and routing. Once you have more than a handful of agents, you can't manually assign every subtask to the right one. Agents need a card that says what they're good at, what runtime they live on, what they've worked on, and how well they've done. A lead agent needs to be able to read those cards and route subtasks automatically. AgentCard and A2A routing in Octo handle exactly this. It's early, but it's obvious that at any reasonable scale, manual assignment doesn't scale.
A quick note on runtimes. A lot of multi-agent frameworks assume every agent runs in the same cloud environment on the same model provider. That falls apart in practice. Some agents need to run locally because they operate on files on your machine. Some tasks genuinely need a strong long-context model. Simple tasks should run on small fast models. Some teams run fine-tuned models. Octo doesn't care where an agent runs — local CLI daemon, cloud runtime, whatever. Register it and it's available for orchestration. The platform tracks identity, capability, and audit trail. How it executes is the runtime's problem.
Fair question at this point: do you really need all of this if you've got one agent writing emails and replying to messages? You don't. That's what Solo mode is for, and it's the right answer for single-agent workflows. But if you're seriously thinking about teams of agents — one doing research, one writing code, one testing, one writing docs, with dependencies between them, quality bars to hit, and knowledge that needs to accumulate — a pure chat approach falls apart within a few iterations. Multi-agent work has a lot in common with distributed systems. You can start simple, but message routing, state management, failure handling, and load balancing are problems you will hit eventually.
Plenty of open source multi-agent frameworks exist. Most of them stop at "let agents chat with each other." The demos look impressive. Running real work through them is a different story. Octo is already in daily use internally — the loop workbench, project management, automation pipelines, and search are live. Agent management and runtime registration are shipping this month. Preference learning and A2A routing are under active iteration. The project is open source on GitHub at , https://github.com/Mininglamp-OSS/octo-server, and issues and PRs are welcome.
If you're building multi-agent products or evaluating frameworks, start by asking a basic question: are your agents chatting, or are they working? If it's just chat, a dialog box is enough. If it's work, you need task tracking, deliverable management, review workflows, preference capture, visibility control, and routing — none of which come from a chat window. You can absolutely start with a simple chat prototype to get something running. Just don't wait too long to build the execution and orchestration layers on top, or your demo will stay a demo.
Top comments (0)