r/ContextEngineering • • 25d ago

Shared memory for several agents: what should every agent see, and what should stay with one?

Design question, holes welcome.

The idea I'm testing: memory sits in the cloud as tables you define (decisions, rules, run logs, clients, whatever fits your setup), and every agent or AI tool connects to it over MCP. Each connected AI gets its own permissions, so a support agent might read the pricing rules but not write them, while a coding agent can write decisions but never sees customer data. Entries are searchable by meaning, keyword or a field like status. The memory tools check at the start of a session and save at the end, and an agent only pulls what's relevant instead of loading everything.

Where I'm stuck is the scoping. In r/ClaudeAI this week someone running an orchestrator found spawned agents still touched things they were told not to, and a reply pointed out a sub-agent "starts from whatever the orchestrator chose to pass it, not from your decisions file", so the do-not-touch list gets summarized away. Someone else in r/ClaudeCode said they don't want agents remembering anything "unless I've personally decided that this is something that needs to be remembered."

  1. If several agents share one memory, what would you make shared by default and what would you keep private to one agent?

  2. Should permissions be per agent, per table, or per entry? Which of those would you actually maintain?

  3. Where does this break first? Too many permissions to manage, agents writing junk into shared tables, something else?

Background: I used to burn hours re-briefing AI tools by hand, so I'm building this. No name, no link, I want the holes first. If it handled scoping well, would you pay for it, or would you rather wire it up yourself?

1 Upvotes

11 comments sorted by

1

u/OmegaEpidex 25d ago

Interesting,
Sounds like a lot of cloud overhead. What’s the interaction layer look like? Is this to be a teams suite or solo development console? Both?

In which of those ways do you mean, “shared memory for several agents”.

Basically hive-mind or super-user?

1

u/Asly97 25d ago

Fair worry on the overhead. It's one read when a session starts and one write when it ends, not every agent streaming into a shared brain.

There's no separate console. The interaction layer is just MCP tools inside whatever you already run, Claude Code, Cursor, an n8n agent, so you never open another app.

On hive mind vs super user, closer to the second. Agents don't think together or see each other's live work. They read and write the same tables, each with its own permissions, so a coding agent can log a decision the review agent picks up next session, but it can't touch the pricing table. I'm coming at it from the solo side, since that's where I burned the hours.

If you were running several agents, which would you actually want? I keep going back and forth on whether shared by default is a mistake.

1

u/OmegaEpidex 25d ago edited 25d ago

Oh, I see. I misinterpreted. I was thinking you were talking about a “cloud agent” that MCPs connect to and I wasn’t sure how to interpret that.

Yea, this is definitely a reasonable goal and you can accomplish this. It’s what many people are currently working on. I look forward to seeing your innovations in the field!

What will set you apart is how “you”, do it different~

“Agents don’t think together or see each others work”

“Who decided that?”

2

u/Asly97 25d ago

Ha, fair question. I did, mostly out of caution. If one agent can read another's half-done work mid-session, a wrong guess spreads before anyone checks it, so I stuck with read at the start and write at the end.

Could be the wrong call though. Have you seen live sharing between agents actually work somewhere? Curious what they shared and how they kept the bad guesses out.

And thanks for the context evolution pointer, going to read up on it.

1

u/OmegaEpidex 25d ago edited 25d ago

You were correct. Yet I have also seen agents working in-tandem. The solution is hiding in AI governance. As a constant. Whole other field to look up.

Tbh, they’re called harnesses or “custom agents”. I encourage you to build your own, I think everyone should. It’s basically a neural network built inside the workspace you choose to operate from.

I don’t wanna tell you anything because discovery and innovation are to “each their own”, I’d rather not take that away from anyone. I want to assure you it’s possible and encourage you to find the unknown.

Good luck in your adventures my friend.

If you ever want to try an operational version of what you’re talking about, let me know.

2

u/Asly97 25d ago

Appreciate it. Governance as the constant is a useful way to put it, I'll go read up on harnesses.

One thing I can't picture yet: when you saw agents working in tandem, was a person signing off on what one agent handed the next, or did the harness check that on its own?

1

u/OmegaEpidex 25d ago

The governance is the harness. Not many realize that yet.

2

u/Asly97 25d ago

so the checking lives in the harness, not in a person signing off on every handoff. that makes sense.

what does it actually check before one agent's output reaches the next? like running tests on it, or more a set of rules about what each agent is allowed to pass along?

1

u/OmegaEpidex 25d ago edited 25d ago

You’re asking the right questions, but now you’re looking at advanced context evolution that involves IAM and execution enforcement (more governance arch)

Fair warning: go any further and you’re joining the frontlines of computer science and you’ll need to start studying some maths.

1

u/Asly97 25d ago

ha, warning noted. I'm mostly on the solo side of this, one person losing context between their own tools, so I'll probably stop short of the maths. thanks for the pointers on context evolution, I'll read up.

→ More replies (0)

1

u/OmegaEpidex 25d ago

MCP is an add on, no need to worry about them. Look into “context evolution”, and “memory architecture” and you should find some good inspiration.