Why Shared Organizational Memory Matters More Than Prompt Chaining in Agent Teams

Most multi-agent setups treat agents like functions in a pipeline. Agent A generates a spec, Agent B writes code, Agent C reviews. Information flows one way, and each agent only sees what the previous one passed along. This works for demos but falls apart in real projects where context accumulates and decisions depend on each other.

We have been running multi-agent workflows on Octo at Mininglamp Technology, and the biggest lesson is that shared organizational memory matters more than how you chain prompts.

Six collaboration patterns and their information topologies
Octo supports six modes: Solo, Roundtable, Critic, Pipeline, Split, and Swarm. The difference between them comes down to how information flows.

Pipeline is linear. Agent A finishes, passes output to Agent B, and so on. Downstream agents only see what upstream sent them. If the product manager forgot to mention a constraint, every agent after that is working blind. We ran into this constantly in early experiments.

Roundtable puts every agent in the same room. All participants see the full conversation history. When the product manager raises a requirement, the developer sees it, the reviewer sees it, and the deployer sees it. Token cost goes up, but information loss goes way down.

Critic builds on Roundtable by adding a dedicated adversarial reviewer. The reviewer's job is to find problems, not to be polite. In our code review workflows, the Critic agent caught issues like unsafe file handling patterns that would have shipped otherwise. One specific example from our internal workflow: the reviewer flagged that a download function would silently save an error page as if it were the actual file if the download failed. That kind of bug is easy to miss in human review too.

Split parallelizes. You break a task into subtasks, hand each to a different agent, and merge results at the end. The risk is that parallel agents make conflicting assumptions because they cannot see each other's work until merge time.

Swarm is the most dynamic. No predefined routing. Agents observe global state and claim tasks as they see fit. Good for situations where you cannot plan the task graph upfront, but it needs a reliable state broadcast mechanism to prevent agents from stepping on each other.

What shared context looks like in practice
We run a four-agent dev workflow internally: AI product manager, AI developer, AI reviewer, and AI deployer, all in one group chat backed by an Octo Space.

The Space holds the complete project state. Every requirement discussion, every code change, every review comment, every deployment log. When the product manager says "confirm this bug is real, if so fix it per standard process," nobody needs a briefing. The project context is already there.

Here is how a typical bug fix plays out. The product manager digs into the codebase, locates the root cause, plans the fix, specifies the branch strategy, and assigns it to the developer. The developer confirms the issue exists in two files, starts coding. A few minutes later the PR is up. The reviewer goes through it and finds two problems that must be fixed before merge. The developer addresses both, updates the PR. The reviewer re-checks each item. Once everything passes, the deployer packages and ships to staging. The product manager generates an acceptance checklist and waits for human sign-off.

The human said one sentence at the beginning and clicked approve at the end. Everything in between happened autonomously through shared context.

Compare that to tools like Cursor where you feed context manually, file by file. Switch sessions and your prior context is gone. In our setup agents navigate organizational context themselves and divide up the work.

Learning compounds over time
Single-session collaboration quality depends on mode selection and context design. But the longer-term question is whether agents get better across sessions.

We tracked one agent from Day 1 to Day 49. On Day 1, it knew nothing about Mininglamp, could not distinguish between our different products, did not know team members or their roles. By Day 7, it could accurately differentiate product positioning. By Day 14, it produced presentation outlines that passed review on the first try. By Day 49, it had grown from a generic chatbot into a specialist with 45 professional skills.

Two learning channels made this happen: humans teaching agents and agents teaching agents. Team members shared strategy context, PR playbooks, technical boundaries in daily conversations. Other agents contributed too, teaching brand design standards and proofreading protocols. Every message was a learning event.

The mechanism behind this is Octo's Experience system. Acceptance feedback from completed tasks automatically converts into reusable knowledge. Skills are not pre-programmed. They emerge from real work. Our network currently has 1770 agents and 45 specialized skills built this way.

Context gives direction. Skills give execution ability. The two multiply into exponential growth.

Loop architecture: keeping information inside the boundary
In the BPIT AI Coding project, we set up a Loop with six agents: CRM dispatch, requirements analysis, backend development, frontend development, testing, and code review. A Loop in Octo represents the full lifecycle from task intake to deliverable.

All agent state, logs, and outputs persist inside the Loop for the entire task duration. When something goes wrong or needs human approval, agents proactively surface it to the responsible person instead of silently failing or hallucinating a workaround. The information boundary of the Loop guarantees that no context is lost during role handoffs.

This matters because in most multi-agent setups, the handoff between agents is exactly where information drops. The Loop architecture eliminates that by keeping everything in one persistent context boundary.

Open source: https://github.com/Mininglamp-OSS