Architecting a Multi-Tenant Agentic Operating System: Implementing Hierarchical Context Management and Scalable Memory via RLS

The current discourse surrounding "Agentic Operating Systems" (Agentic OS) often focuses on the individual—how a single user can augment their productivity through structured context. However, the engineering challenge shifts significantly when transitioning from a single-user setup to a team-wide deployment. The complexity lies in managing shared memory, enforcing granular access control, and ensuring that non-technical stakeholders can iterate on system instructions without compromising the underlying technical architecture.

This post outlines a blueprint for a multi-tenant Agentic OS designed for team scalability, leveraging a three-tier architecture to manage context, version control, and long-term semantic memory.

The Problem: Context Rot and the Need for an Agentic OS

At its core, an Agentic OS is a structured filesystem of Markdown files and directories designed to manage LLM context injection. Without such a system, LLMs suffer from context rot—the degradation of performance and instruction adherence when massive amounts of information are provided simultaneously, leading to the loss of critical nuances like brand voice or specific client implementation details.

An effective Agentic OS separates the Intelligence (the LLM) from the Memory and Judgment (the OS). The OS determines which specific context fragments (brand rules, client data, process docs) are injected into the prompt at the precise moment they are required.

The Three-Tier Architecture

To build a system that is both usable by non-technical team members and robust enough for technical engineers, we implement a three-tier data management strategy.

Tier 1: The Human-Editable Interface (The Source of Truth)

The primary interface for non-technical users should be an environment they already inhabit, such as Notion, Google Drive, or OneDrive. By using these platforms, team members can edit global rules (e.g., cloud.md) and brand context using familiar Markdown editors. This tier serves as the "Human Source of Truth." The primary constraint here is that this tier is limited to Markdown-compatible content; we avoid storing scripts or complex system files here to prevent parsing errors during the synchronization process.

Tier 2: The Agentic Execution Layer (Cloud Code/Codex)

This tier contains the files that require active manipulation by agents. This includes the Skills directory—process documents that utilize YAML front matter for name and description metadata. While some skills might be viewable in Tier 1, the operational logic and the files requiring agent-driven updates reside here. This layer is accessed via a harness like Cloud Code or Codex, where the agent performs the heavy lifting of updating documentation and managing task-specific context.

Tier 3: The Version Control and Backup Layer (GitHub)

The final tier is the technical backbone. All files from Tier 1 and Tier 2 are synced to GitHub. This provides a complete, immutable backup and enables professional-grade version control. This tier is managed by the technical team, ensuring that even if a non-technical user makes an error in Notion, the system can be rolled back to a known stable state.

Hierarchical Context and Data Inheritance

A scalable Agentic OS must support a hierarchy of information, allowing for global standards to be overridden by local, task-specific instructions.

1. Global Rules: Files like cloud.md (global instructions) and soul.md (agent identity/persona) are inherited by every user in the organization.
2. Shared Context: A context/ directory contains project-specific or client-specific folders. These are shared across relevant team members but isolated from others.
3. Local Overrides: To allow for personalized workflows, the system supports claude.local.md or .local.md files. These files reside on the user's local machine, allowing them to overlay bespoke rules on top of the inherited global context without polluting the shared repository.

Advanced Memory Architectures: Vector Databases and RLS

For true long-term recall, the system must move beyond static files and utilize a vector database for semantic retrieval. There are two primary architectural patterns for implementing this in a team environment:

Pattern A: Isolated Local Indices

Each user maintains a separate memory index built locally from the files they are permitted to sync.

• Pros: Complete isolation; zero risk of unauthorized data leakage.
• Cons: No shared "team brain"; no way for one user to benefit from the learned context of another.

Pattern B: Shared Postgres Memory with Row Level Security (RLS)

This is the preferred scalable approach. By utilizing a shared Postgres instance (e.g., Supabase), we can implement a centralized semantic database. To maintain multi-tenancy and security, we employ Row Level Security (RLS). Every query is tagged with a client or user identifier. The database engine itself enforces that a user belonging to "Client A" can only retrieve embeddings and metadata associated with "Client A" or "Global" scopes. This allows for a unified, scalable "team brain" while strictly enforcing data silos.

Security and Access Control Synchronization

The greatest challenge in a multi-tier system is ensuring that permissions are synchronized across all layers. A leak in GitHub or the memory database could expose sensitive client data even if Notion permissions are restricted.

To prevent this, we implement a mirrored permission strategy:

• Shared Drive Sync: The system uses tokens from the shared drive (Notified/GDrive) to determine which files are pulled into the local Cloud Code environment.
• GitHub Scoping: We implement a one-repo-per-client strategy. The membership of the GitHub repository must mirror the access permissions in the Notion/GDrdive space.
• Database Enforcement: As mentioned, the memory database uses RLS to ensure that even if a user attempts to query the vector store, the database refuses any rows not explicitly permitted by their authenticated identity.

Conclusion: The Principle of Portability

The ultimate goal of this architecture is vendor neutrality. By structuring the entire Agentic OS around Markdown files and standard database protocols, the system remains portable. You are not locked into a specific LLM or a specific proprietary interface. If a superior model or a more efficient orchestration tool emerges, your entire organizational memory, rules, and skills can be migrated with minimal friction.