diff --git a/docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md b/docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md
new file mode 100644
index 0000000..57698ff
--- /dev/null
+++ b/docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md
@@ -0,0 +1,27 @@
+# MCP Filesystems Research Note Implementation Plan
+
+> **For agentic workers:** Execute this plan inline with validation checkpoints.
+
+**Goal:** Add and publish a sourced research note on the MCP Filesystems Working Group and bidirectional Resources.
+
+**Architecture:** Describe the proposed wire-level resource operations and concurrency/cache semantics, then distinguish them from local filesystem mounting and authorization. Map the proposal to CF-hosted agent workspaces, object storage, service bindings, and platform audit.
+
+**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI.
+
+---
+
+### Task 1: Write `research/mcp-filesystems.md`
+
+- [ ] Add frontmatter with title `MCP Filesystems: Bidirectional Resources for Agent Workflows`, author `Ruben Koster (@rkoster)`, date `2026-09-17`, tags `[orchestration, durable-execution, inter-agent-comms, ecosystem-survey]`, `cf_areas: [capi, diego]`, `status: draft`, provisional ratings, and official charter/spec/SEP sources.
+- [ ] Explain the working group's mission to make MCP Resources bidirectional and its early-stage/ideating status.
+- [ ] Cover proposed `create`, `update`, `delete`, and `stat` operations, create-if-absent semantics, optimistic concurrency, and metadata such as existence, size, and last-modified.
+- [ ] Cover change notifications, `ttlMs`, `cacheScope`, `lastModified`, and the relationship to existing resource update notifications and caching.
+- [ ] Distinguish remote resource protocol semantics from host-side filesystem materialization, local disk/sandbox behavior, and authorization policy.
+- [ ] Assess CF relevance for agent workspaces, blob/object stores, volumes, bindings, concurrent writers, cache invalidation, audit, and policy enforcement.
+- [ ] Add open questions about URI namespaces, version tokens, conflicts, atomicity, tenant isolation, offline clients, and write authorization.
+
+### Task 2: Validate and publish
+
+- [ ] Run `devbox run validate`, `devbox run test`, and `git diff --check`.
+- [ ] Stage only the note and approved spec/plan, commit `docs: add MCP Filesystems research note`, push `research/mcp-filesystems`, and open a checklist-complete PR targeting `main`.
+- [ ] Verify PR metadata and CI with `gh pr view`.
diff --git a/docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md b/docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md
new file mode 100644
index 0000000..9d50b56
--- /dev/null
+++ b/docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md
@@ -0,0 +1,30 @@
+# MCP Filesystems Research Note Design
+
+## Goal
+
+Add a sourced research note on the MCP Filesystems Working Group's proposal to make Resources
+bidirectional for agent workflows.
+
+## Scope
+
+The note will cover the group's mission, proposed create/update/delete/stat operations,
+optimistic concurrency control, change notifications, cache metadata, and its relationship to
+existing MCP Resources and filesystem-like URIs. It will distinguish remote MCP resource
+semantics from host-side filesystem materialization and authorization, which the charter leaves
+out of scope.
+
+The Cloud Foundry analysis will consider agent workspaces, object/blob-backed resources,
+service bindings, concurrent writers, cache invalidation, audit, and authorization boundaries.
+It will identify the work as early-stage: the charter lists the main SEP as ideating.
+
+## Structure and evidence
+
+Create `research/mcp-filesystems.md` with the required four sections and frontmatter. Use the
+official MCP Filesystems charter, MCP Resources specification, relevant SEP links listed by the
+charter, and the reference filesystem server where useful. Label CF conclusions as analysis or
+open questions.
+
+## Validation
+
+Run Devbox validation and tests, inspect whitespace/staged files, commit the note and plan on
+`research/mcp-filesystems`, push, and open a PR targeting `main` without unrelated artifacts.
diff --git a/generated/research-map.html b/generated/research-map.html
index fe1645a..0aacdfd 100644
--- a/generated/research-map.html
+++ b/generated/research-map.html
@@ -23,9 +23,6 @@
Focus use cases
Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.