Multi-Agent Systems vs MAMU Systems: The Missing Human Dimension

Traditional MAS focuses on delegation and coordination; MAMU adds human roles, access, ownership and organizational authority. Here, MAMU means multi-agent, multi-user system: a working term for adding human identity and decision rights to multi-agent coordination, not a claim about an established universal category.

Working thesis: Multi-agent coordination is necessary but insufficient when many humans also create, approve and consume shared state.

MAS vs MAMU at a glance

MAMU is AuzzurA’s useful working terminology for this combined problem, not a universal standard that replaces the established multi-agent-systems literature.

Why this matters for AI agents

An AI agent does not work from organizational reality directly. It works from the instructions, tools, memory, retrieved material and task state that reach its context window. That makes context selection part of the system architecture rather than a cosmetic prompt decision.

For one-off assistance, an imperfect context set may produce an inconvenient answer. For long-running or tool-using agents, the same weakness can persist across steps, be written into memory, propagate to another agent, or influence an external action. The engineering target is therefore not maximum information. It is sufficient, current and applicable information for the task at hand.

This is also why raw retrieval metrics tell only part of the story. A system can retrieve text that is semantically relevant yet still be wrong for the current project, user, environment or point in time. Conversely, an important constraint may have low lexical similarity to the user’s request but still be essential to safe execution.

A concrete example

An engineering agent may access a private incident analysis that a support agent cannot; shared summaries must preserve that boundary.

A practical architecture

1. MAS orchestration. Coordinates agent delegation, sequencing and handoffs, but does not define who may see or approve the resulting state.
2. Human roles. Adds owners, approvers and users whose authority can differ from the agent that produced a proposal.
3. Context boundaries. Carries identity, scope and permissions into retrieval and derived artifacts, including summaries and reports.
4. Governed shared state. Preserves provenance and lifecycle so approved knowledge can be reused without turning every agent output into organizational truth.

Design principles

• Model human approval as state transitions.

• Apply access controls to derived artifacts.

• Audit agent-to-agent and human-to-agent propagation.

• Keep provenance, lifecycle state and permissions attached as context moves across tools and handoffs.

• Evaluate context quality against the task outcome, not only similarity scores or token counts.

How AuzzurA approaches this

AuzzurA frames human + AI work as a shared-context problem. People and agents need different visibility, but approved reusable learning still needs an explicit path across those boundaries.

Questions to ask before implementing this pattern

• What exactly are we persisting: raw source, memory, candidate knowledge or approved knowledge?
• Who owns an item, and who can change its status?
• How is scope represented across organization, team, project, environment, user, agent and task?
• How do we know when an item is stale, superseded or in conflict?
• Can we reconstruct which context reached a participant during a specific run?
• What learning from the run should return to shared context, and what review is required before reuse?

These questions tend to outlast individual model, vector-store and graph-engine choices because they define the organizational semantics around those components.

Sources and further reading

• AIM: A Privacy-Aware Interoperable Memory Framework for Multi-Agent Multi-User LLM Systems
• Governed Shared Memory for Multi-Agent LLM Systems
• Collaborative Memory: Multi-User Memory Sharing in LLM Agents
• Microsoft Learn — Multi-agent patterns