Multi-Agent Teams: Shared Memory vs. Process-Style Isolation

Original: https://mp.weixin.qq.com/s/KKrbunCDYtryKQbdsYJDoA (October 15, 2026)

After the previous post, a friend in the background asked me: if we're forming a team, which step comes first?

I expected him to ask about how many AIs to launch, but instead he asked whether they should share memory.

That question hits the point.

I've seen too many crash scenes: a later AI that takes over has no idea what the previous one did, and redoes the work from scratch.

I've also seen the opposite: several AIs crammed into a notebook that keeps getting thicker, until no one can find the key points.

These two predicaments correspond to two paths. Choose wrong, and no amount of tweaking later will feel right.

One path is a relay; the notebook is passed down

Shared memory, to put it plainly, is like a colleague taking over the shift.

The role and tools change, but the work log left by the predecessor remains intact.

The benefit is real: information isn't lost, and you can look back at any detail.

The cost is obvious: the notebook grows thicker, and the person who takes over later can easily get buried in a pile of old information.

So how do you make it so that even after a role change it's still the same person? The method is to replace the role specification mid-way.

There's an easily overlooked choice here.

Replacing the entire specification is more thorough, lets you pull away irrelevant tools, and is safe, but the downside is that each replacement requires a recompute and is expensive.

The other option is to keep the specification and only flip out a behavior manual when needed. It's cheaper, but tool permissions aren't as strict.

My advice is plain: if the difference lies in knowledge, process, or writing style, a manual is enough.

If the difference lies in permissions, boundaries, or absolute prohibitions, then replace the specification and add a hard gate.

One path is to work separately and coordinate through communication

Not sharing memory is like collaboration between different departments.

Each person works independently at their own workbench, exchanging information through shared documents and meeting minutes, rather than watching someone else's screen.

It's clean, isolated, and truly parallel. A failure in one department doesn't spread to others.

The trouble is that you have to decide in advance how to communicate, and when something goes wrong, you have to dig through logs from several departments to piece together the truth.

Interestingly, this architecture maps almost one-to-one with an operating system.

Each AI is like a process with its own memory. Creating, cancelling, and inspecting subordinates correspond to fork, kill, and ps in processes.

Decades of old experience can mostly be borrowed directly.

It's propped up by two pipes: one for delivering artifacts, one for issuing commands.

The file cabinet in an AI's eyes has several layers

Start with the artifact-delivery pipe.

The file system an AI sees is like a layered file cabinet.

The top layer is a private drawer for its own drafts and temporary files. Others can't see it, and it's cleared when it leaves.

The middle is the public desktop, where everyone's artifacts are laid out. Users can upload and download here too. This layer is most prone to collisions, so it needs locks.

Further out are the external drives you've connected: user-authorized cloud drives, Notion, and so on, accessed by reading files. But they're governed by the other party's permissions, have high latency, and are best used read-only.

The final layer is the tool cabinet: system-provided skills and manuals. Everyone can read them; they're read-only and change rarely.

The drawers are clearly separated.

Its greatest value, in one sentence: what passes between agents is a small note with a path, not the whole content stuffed into someone's brain.

The command pipe also has to manage several things

For a team to spin up, shared files alone aren't enough.

You need to send messages. You can talk directly, or use a broadcast station. Messages are wrapped in a uniform envelope for later tracing.

You need to ask about progress. Don't just stare at the screen. Send a message asking how it's going, or have the agent write progress into a lightweight checklist. One glance tells you; if it hasn't been updated for a long time, it's stuck.

You need to stop. Graceful shutdown and exit is best; force only if necessary. And when one stops, its spawned subordinates must stop with it, leaving no orphan processes behind.

You also need to allocate resources. The scarcest are money and concurrency quotas. A team leader with a brain can adjust on the fly while watching progress, like internal horse racing in a company.

Bottom line

Neither path is absolutely superior.

Shared memory is coherent and easy to implement; just watch out for it growing too thick.

Independent work is clean and scalable; you pay for communication.

The truly hard part is deciding which path to take this time.

With the skeleton in place, the next question is how they actually cooperate. In my next post I want to talk about the most classic pattern: peer review.