Adopt filesystem abstraction for context engineering in Studio

Context

Paper: "Everything is Context: Agentic File System Abstraction for Context Engineering" (Xu et al.) proposes treating context as a first-class entity with a filesystem-like abstraction — hierarchical organization, versioning, caching, and unified access patterns for agentic systems.

Mesh already has strong foundations here: MeshContext as the central dependency injection interface, org-scoped storage, Virtual MCPs for hierarchical tool composition, SWR caching for MCP tool lists, and the Context MCP Server (git-backed knowledge base). This issue proposes extending these patterns into a unified context filesystem that agents can navigate, compose, and version.

Key Ideas to Leverage

1. Context as a Mountable Virtual Filesystem

Today agents access context through scattered mechanisms — thread history in SQL, tools via MCP, knowledge via the Context MCP Server, org settings via storage adapters. The paper's core insight: unify all context under a single filesystem metaphor.

Concretely, expose a virtual filesystem in Studio where each agent sees:

/org/                          # Organization-level context
  settings.json
  connections/
  members/
/project/                      # Project-scoped context
  goals.md
  agents/
  workflows/
/agent/                        # Agent-specific context
  system-prompt.md
  tools/                       # Mounted MCP tools
  resources/                   # MCP resources
  memory/                      # Persistent agent memory
/thread/                       # Current conversation context
  messages/
  artifacts/
/knowledge/                    # Mounted knowledge bases (Context MCP Server)
  strategy/
  engineering/
  learnings/

This aligns with Virtual MCPs' composition model but extends it to all context types, not just tools.

2. Hierarchical Context Composition (Scoped Mounting)

Just as Virtual MCPs compose child connections into a parent, context should compose hierarchically with inheritance and overrides:

• Org context → inherited by all projects
• Project context → inherited by all agents in that project
• Agent context → specific to one agent, can override project-level defaults
• Thread context → ephemeral, conversation-scoped

This is the org-scoping pattern (requireOrganization, OrgScopedThreadStorage) generalized to all context. Studio's UI could visualize this as a file browser with "mounted" context sources, making it obvious what context each agent has access to.

3. Context Versioning & Snapshots

The Context MCP Server already uses git for versioning knowledge. Extend this to agent context:

• Snapshot agent context before/after workflow runs (for debugging and auditing)
• Diff context states to understand what changed between agent decisions
• Roll back to a previous context state if an agent workflow produces bad results
• Leverage the existing OpenTelemetry tracing to correlate context snapshots with spans

4. Generalized SWR Caching for All Context

Mesh already implements SWR caching for MCP tool lists (fetchWithCache + NATS JetStream KV). The paper argues this pattern should apply to all context retrieval:

• Cache org settings, project configs, agent prompts — not just tool lists
• Background revalidation (already tracked via ctx.pendingRevalidations) for all context
• Invalidation cascades: when an org setting changes, propagate invalidation to all dependent project/agent caches

5. Context Explorer UI in Studio

A new Studio panel — a file-browser-like UI for navigating all context an agent has access to:

• Browse the virtual filesystem hierarchy described above
• See what's mounted, from where (which MCP server, which storage adapter)
• Preview context values (tool schemas, resource contents, prompt templates)
• Edit context inline (update prompts, toggle tools, adjust settings)
• Visualize context inheritance (what's inherited from org vs overridden at project level)

This makes Studio not just a wiring tool for MCP servers but a context debugger — essential as agent workflows grow in complexity.

6. Context-Aware Bindings

Extend the @decocms/bindings system to include context contracts alongside tool contracts. A binding could declare not just "this MCP must expose these tools" but also "this agent requires these context resources to be mounted":

const BLOG_AUTOPILOT_CONTEXT = defineContextBinding({
  required: [
    { path: '/knowledge/learnings', type: 'mcp-resource' },
    { path: '/project/goals.md', type: 'document' },
    { path: '/agent/memory/patterns', type: 'kv-store' },
  ],
  optional: [
    { path: '/knowledge/brand-voice', type: 'document' },
  ],
});

This enables compile-time validation that an agent has everything it needs before execution.

Why This Matters for Deco

Studio's vision is to be the control plane for agentic software. As agent workflows grow in complexity (multi-agent, multi-tool, multi-step), the #1 debugging and reliability challenge becomes: what context did the agent have when it made that decision?

A filesystem abstraction for context makes this:

• Visible — browse what any agent sees at any point
• Composable — mount/unmount context sources like volumes
• Debuggable — diff context snapshots across workflow runs
• Auditable — version and trace every context change

This directly supports the guardrails-strengthening-over-time philosophy: you can't improve what you can't observe.

References

• Paper: https://arxiv.org/abs/2512.05470
• Existing patterns in Mesh: MeshContext, Virtual MCPs, fetchWithCache SWR, Context MCP Server, @decocms/bindings

Start by reading MeshContext, Virtual MCPs, fetchWithCache, the Context MCP Server, and @decocms/bindings to map the existing context mechanisms. The issue names no target files, tests, bounded first milestone, or acceptance criteria; done would require an agreed scope for the filesystem, caching, snapshots, bindings, and Studio explorer.