Architecting a Multi-User Agentic Infrastructure: Implementing Shared Context, Tool Orchestration, and Centralized Vector Memory via MCP

The current state of Large Language Model (LLM) interaction is fundamentally "single-player." While Claude's capabilities are expanding, the surrounding infrastructure—specifically memory frameworks, tool connections, and context windows—is tethered to individual user accounts. This creates a massive fragmentation problem for engineering and product teams: how do you move from an individual agentic workflow to a collaborative, shared intelligence ecosystem?

The challenge is three-fold: Claude’s native memory is account-specific; third-party memory frameworks typically store findings on local machines; and Model Context Protocol (MCP) connections often authenticate via personal credentials. To solve this, we must shift our mental model from treating context as a user-owned asset to treating it as shared infrastructure—complete with permissions, cloud access, and centralized storage.

This post outlines a technical blueprint for an "80% version" of a Claude team system using three distinct layers: Shared Context (Notion), Secure Tool Orcheatration (Composio), and Centralized Vector Memory (Supermemory.ai).

Layer 1: The Shared Context Layer (The Source of Truth)

A collaborative agent requires a shared "Source of Truth" that supports granular permissions. Using local Markdown files or GitHub repositories is viable for technical users but fails to scale for broader business operations due to the friction of synchronization and permission management.

By leveraging Notion as our shared drive, we can utilize its native permissioning engine to control what Claude can "see." The implementation involves connecting Claude Desktop to Notion via an MCP connector.

Implementation Workflow:

1. Authentication: Each team member connects Claude to Notion through their individual credentials using the built-in Notion MCP connector in Claude's settings.
2. Permission Propagation: Because Claude can only read what the authenticated user has access to, we leverage Notion’s native hierarchy (e.g., "Private," "Invite Only," or "Workspace Access"). If a manager restricts a page in Notion, that restriction propagates instantly to the agent's capabilities within Claude.
3. Context Injection: To ensure the agent knows where to look, the specific Notion URL for the team context must be explicitly defined in the user's claude.md or system instructions:
   • Instruction Example: "When accessing team context or files, first check this Notion URL: [URL]."

This setup allows a team to maintain brand DNA, positioning, and visual design elements in a centralized location that is both human-readable and agent-accessible.

Layer overlap: Layer 2: Secure Tool Orchestration (The Composio Gateway)

A major bottleneck in team-based AI workflows is the "API Key Dilemma." Sharing individual API keys for tools like Gmail, Stripe, or QuickBooks is a security nightmare and an operational burden. The solution lies in using Composio as an abstraction layer to provide tool access without credential exposure.

We implement this via two distinct architectural patterns:

Pattern A: Personal Account Delegation

For tools that require individual identity (e.g., scanning a specific user's Gmail inbox), team members install the Composio connector in Claude Desktop by pointing to a remote MCP server URL.

• Mechanism: Each member authenticates via their own Composio account. They add specific apps to their project within Composio and authenticate directly through the toolkit.
• Security Benefit: No API keys ever leave the Composio vault, and every action is performed under the user's existing identity/permissions.

Pattern B: The Scoped MCP Gateway (Shared Tool Access)

For shared company resources—such as a centralized Stripe account or an accounting dashboard in Xero—we utilize the Composio MCP Gateway. This allows us to generate a single URL per team that provides scoped tool access.

• Mechanism: One API call to Composio creates a scoped server containing specific, limited permissions (e. actually just access to Stripe). The returned value is an MCP URL that can be added as a custom connector in Claude Desktop.
• Scalability: This allows even users without direct seats in the underlying software to interact with it via the agentic gateway.

Layer 3: Centralized Vector Memory (Supermemory.ai)

The final, and most difficult, piece is shared memory. While Claude's built-in memory tracks session history, it remains siloed within a single user's account. To break these silos, we use Supermemory.ai to create a centralized "Team OS" container.

By using the Supermemory MCP plugin (supermemory.ai/Claude-supermemory), we can force Claude Desktop to write and read from a specific shared vector database container rather than creating ephemeral, per-session containers.

Technical Configuration:

1. Plugin Installation: Add the repository via the Claude Desktop plugin marketplace.
2. Container Tagging: The critical step is configuring the project config command within Claude to point to a unified repo_container_tag.
   • Command: /project config add [API_KEY] [TEAM_OS_TAG] (e.g., team-os-demo).
3. Vectorized Retrieval: When an agent saves information, the plugin chunks and vectorizes the content into the specified container. Because all team members are configured to point to this same tag, any member can query the shared memory to retrieve decisions made in previous sessions by other colleagues.

The Sandbox Constraint:

To allow Claude's sandbox environment to communicate with the external memory API, you must add api.supermemory.ai to the allow-list within your Claude Desktop capabilities settings.

Critical Limitations and Security Caveats

While this architecture provides a robust framework, two significant technical limitations exist in the current iteration:

1. Context Persistence Leakage: There is a "persistence gap" between Notion and Supermemory. If an agent pulls context from Notion, processes it, and then saves that information into the shared Supermemory container, the data remains accessible via the memory system even if the original permission in Notion is revoked. The vector embedding exists independently of the source document's live state.
2. Lack of Granular Memory Partitioning: Currently, the plugin captures all session information and pushes it to the configured container tag. There is no native "personal vs. shared" split within a single project folder. Users must be highly deliberate about which directories they run these configurations in to avoid leaking sensitive client data into the team-wide vector store.

Conclusion

Building an agentic team requires moving beyond simple prompting and into the realm of infrastructure engineering. By layering Notion for context, Composio for tool orchestration, and Supermemory for centralized retrieval, we can create a unified "Team Brain" that scales across multiple users without compromising security or manual overhead.