diff --git a/docs/dev/ADR-012-multi-instance-federation.md b/docs/dev/ADR-012-multi-instance-federation.md
index 3cdaa4829..fc768de45 100644
--- a/docs/dev/ADR-012-multi-instance-federation.md
+++ b/docs/dev/ADR-012-multi-instance-federation.md
@@ -19,7 +19,7 @@ This ADR maps the federation surfaces, takes a position on each, and sequences t
 
 ### Surface 1 — Knowledge (anti-patterns, learnings, contracts)
 
-**Status:** designed in `SPEC.md` §16 — Singularity Memory (`sm`) is the explicit cross-instance knowledge layer. HTTP + MCP server holding memories, learnings, anti-patterns. Runs embedded (single-user sf) or remote (shared service on tailnet, reachable from sf, Hermes, OpenClaw, Claude Code, Cursor).
+**Status:** designed in `SPEC.md` §16 — Singularity Memory (`sm`) is the explicit cross-instance knowledge layer. HTTP API holding memories, learnings, anti-patterns. Runs embedded (single-user sf) or remote (shared service on tailnet, reachable from sf, Hermes, OpenClaw, Claude Code, Cursor through their own client integrations).
 
 **Code reality:** not yet wired. `src/resources/extensions/sf/memory-store.ts` and `memory-extractor.ts` write to a local SQLite `memories` table. The spec's "remote-mode" isn't connected.
 
@@ -40,7 +40,7 @@ The pain ceiling is bounded today (per-instance discovery is at worst a few wast
 
 **Status:** not designed. sf has no concept of "milestone in repo A produces an artefact repo B depends on". The unit hierarchy (milestone → slice → task) is project-local.
 
-**Decision:** **out of scope for sf.** Cross-repo orchestration is a different abstraction layer — it belongs in a meta-coordinator that consumes sf's MCP API, not in sf itself. Building it inside sf would conflate "agent that ships one project" with "fleet manager that ships an org's roadmap." Different products.
+**Decision:** **out of scope for sf.** Cross-repo orchestration is a different abstraction layer — it belongs in a meta-coordinator that consumes sf's daemon/RPC or headless interfaces, not in sf itself. Building it inside sf would conflate "agent that ships one project" with "fleet manager that ships an org's roadmap." Different products.
 
 ### Surface 4 — Federated persistent agents
 
diff --git a/docs/dev/ADR-014-singularity-knowledge-and-agent-platform.md b/docs/dev/ADR-014-singularity-knowledge-and-agent-platform.md
index ee2dce7a6..10d773814 100644
--- a/docs/dev/ADR-014-singularity-knowledge-and-agent-platform.md
+++ b/docs/dev/ADR-014-singularity-knowledge-and-agent-platform.md
@@ -26,7 +26,7 @@ The implementation arm of this ADR lives in [`singularity-memory/MIGRATION.md`](
 - **Identity / auth / sync layer: `charmbracelet/charm`-server patterns** — SSH-key identity, JWT issuance, encrypted KV for user-level prefs and config. Adopted as ported library code; not run as a sidecar.
 - **Agent runtime: `charmbracelet/fantasy`** — multi-provider LLM access (Anthropic, OpenAI, Google, Bedrock, OpenRouter, etc. via `catwalk`). Used for embeddings/summarisation today. *(The original plan to grow this into a full central persistent-agent runtime — Phase 4 — is cancelled by [ADR-019](./ADR-019-workspace-vm-convergence.md). `fantasy` is retained for embeddings/summarisation within the knowledge layer only.)*
 - **HTTP API: Go `net/http` + chi or echo router**, serving the *exact* current OpenAPI contract.
-- **MCP server: same wire protocol** as today's Python implementation. Clients (sf, Hermes, OpenClaw, Claude Code, Cursor) keep working unchanged.
+- **HTTP API compatibility:** preserve the current OpenAPI contract. SF remains an HTTP/RPC client of the knowledge layer and does not expose its workflow as an MCP server.
 - **CLI scaffolding: `charmbracelet/fang`.**
 - **Observability: `promwish`-style Prometheus metrics**, scraped from a shared metrics endpoint.
 - **Admin UI (Phase 3): `pony` + `ultraviolet`** for the view layer (reversed from earlier deferral; now adopted as a deliberate foundation bet — admin UI tolerates churn better than user-facing surfaces). Served over SSH via `wish`.