Your team says “harness.” A vendor says “framework.” Another says “platform.” Your CTO says “infrastructure.” Everyone nods, and nobody agrees on what they mean.
Planning a multi-agent memory architecture? This is where the mix-up starts to cost you. When nobody owns memory, you get three copies of it. Or none. Below, I split the four terms apart and show which layer should own what.
Why the Four Words Blur
Vendors use these words loosely. One product can act as a harness, a framework, and a platform at once. So the labels describe jobs, not products.
When you hear a term, ask one question: which job does this do? Once you know the job, you know who should own memory at that layer.
The Four Layers in Plain Terms
What Is a Harness?
A harness is the runtime wrapper around a single agent. It runs the loop, calls tools, and builds the context the model sees on each step. Think of it as the cockpit for one agent.
Memory role: working memory for one run.
What Is a Framework?
A framework is a code library for building agents. It gives you patterns for prompts, tools, and chains. You write the logic, and the framework adds structure.
Memory role: memory interfaces. You still pick and run the store.
What Is a Platform?
A platform is a managed place where agents run and get managed. It adds deployment, access control, and visibility across agents.
Memory role: shared state that many agents can read and write.
What Is Infrastructure?
Infrastructure is the stuff running under your agents. It moves messages, stores data, handles search, and keeps watch. Your agents barely notice it. But if it breaks, they stop working.
Memory role: moving and storing data between agents.
Here is the short version:
| Layer | Main job | Memory role |
|---|---|---|
| Harness | Runs one agent’s loop | Working memory |
| Framework | Gives you code patterns | Memory interfaces |
| Platform | Manages many agents | Shared state |
| Infrastructure | Moves and stores data | Storage and messaging |
Visual idea: a stacked diagram. Put infrastructure at the bottom, then platform, framework, and harness on top. Draw a memory arrow beside each layer.
Multi-Agent Memory Architecture by Layer
A solid multi-agent memory architecture starts with one idea. Memory comes in three kinds, and each kind belongs to a different layer.
- Working memory: what one agent holds during one step. The harness owns it.
- Run memory: what a task builds up over many steps. The framework or harness manages it.
- Shared memory: what many agents need across tasks and time. The platform and infrastructure own it.
Shared memory is the hard one. Say agent three needs a decision that agent one made yesterday. Agent one is long gone, and its harness is closed. If that decision lived only inside the harness, it’s lost.
That’s why a multi-agent memory architecture needs a shared layer outside any single agent.
Common Ownership Mistakes
Teams repeat the same errors:
- Private memory per agent. Agents drift apart and contradict each other.
- Memory inside the framework process. A restart wipes it.
- Everything stuffed into the prompt. Costs climb and useful details get buried.
- No traceability. You can’t tell why an agent remembered something wrong.
Each mistake has one root. A lower layer is doing a higher layer’s job. A good multi-agent memory architecture keeps every layer in its lane.
DNotifier in Practice
With DNotifier, one SDK and one API handle the platform and infrastructure work. Multi-agent systems, AI orchestration, and real-time pub/sub all sit behind them. So your agents can message each other without extra code from you.
For shared memory, semantic search can help agents find relevant past context. Monitoring and traceability show what each agent knew and when. That makes your multi-agent memory architecture easier to debug.
There’s a trade-off. A shared layer adds one more dependency to your stack. In return, you get one place to look when memory goes wrong.
FAQ
Is a harness the same as a framework?
No. A harness runs one agent’s loop, while a framework gives you code patterns to build agents. Many products bundle both, which causes the confusion.
Do I need a platform for a multi-agent memory architecture?
Not for a single agent. Once several agents share decisions and history, a shared layer saves you from copying state around by hand.
Where should shared memory live?
Outside any single agent. Put it in the platform or infrastructure layer so every agent reads the same record.
