Retail MCP Is the Doorway, Not the Memory

Accessible retail AI clients can be excellent FDE interfaces. Durable engagement continuity must still belong to the platform: an immutable walk, a compact task-world manifest, and a reloadable working set—not undocumented chat-memory behaviour.

Scott Farrell · LeverageAI · Extender of Intent-Conditioned Task World

The first time you attach a firm wiki to a retail AI client over MCP, it feels like a category change. A general-purpose model starts walking your frameworks, prior code, engagement history, and doctrine as if the practice were a place rather than a slide deck. Consultants do not need a special workstation. They already know how to talk to the product.

That accessibility is real. Treat it as the product’s doorway.

Then notice the architectural risk on turn twelve, next Monday, or when the work moves from ChatGPT into Claude Code or Codex. The conversation that wowed the room is still a poor system of record. Tool fidelity may thin on a retail surface—that is a field hypothesis, not a measurement in this write-up—but accepted findings, rejected alternatives, and evidence pointers are already unowned objects unless the platform holds them. Someone writes a lossy handover note. The next model may re-walk the same region and change its mind without knowing it changed its mind.

Retail MCP is the doorway, not the memory.

This article is an operational extender of Intent-Conditioned Task World: the parent already owns the temporary world and the inspectable manifest.¹ Here the job is narrower and more commercial—how a long-running FDE engagement survives chat compaction, model changes, and handoffs between retail clients and coding agents without replaying the entire history every time.

The mis-assigned memory job

Most teams silently assign engagement memory to whichever surface they demoed last:

• the retail chat transcript,
• the vendor’s consumer “Memory” feature,
• or a coding-agent session file on someone’s laptop.

Those are different objects with different contracts.

MCP is an access plane: an open protocol for connecting models to tools and data.² Anthropic’s own engineering writing is explicit that tool definitions and intermediate results can consume excessive tokens and that efficiency problems appear once many servers and full transcripts flow through the model.³ The protocol standardises the plug. It does not standardise your engagement topology.

Retail ChatGPT with developer mode / MCP apps is documented as a way for organisations to build and use MCP-powered tools so ChatGPT can take action in systems—currently with plan and admin constraints, and still evolving in beta language on OpenAI’s Help Center.⁴ That is doorway documentation. It is not a published application contract that every prior MCP result remains fully attention-resident on every later turn.

ChatGPT Memory / Dreaming is documented as synthesis of useful preferences, projects, and constraints so future chats can start from shared context—not as full-fidelity replay of multi-hop tool walks, rejected paths, and evidence packages.⁵ OpenAI describes dreaming as learning from many conversations and synthesising memory state for freshness and relevance.⁵ Useful product. Wrong abstraction for engagement SoR.

Retail Claude / Claude.ai likewise documents MCP as an access plane: connectors powered by MCP, with Claude.ai listed for full remote MCP support and MCP Apps, and custom remote MCP connectors available on Claude (including Free through Enterprise plans, with plan limits).¹² Again: documented tool access. Not a published contract that every prior MCP tool result remains attention-resident for the life of an engagement.

Claude Code is more explicit about layers on the coding-agent side. Official docs state that each message, tool use, and result is written to a local JSONL session file; sessions can be resumed or forked; and—separately—the active context window fills and compacts, clearing older tool outputs first and summarising conversation when needed.⁶ New sessions start with a fresh context window.⁶ Persisted history and active model context are different layers. That distinction is the whole article in one product sentence—and it must not be smuggled back as a retail-Claude retention guarantee.

Codex CLI documents codex resume for returning to a saved chat, plus MCP connectivity for external tools in the session.⁷ Again: resumable client session ≠ firm-owned engagement world.

What must not live only in the window

Long-running agent work already taught the hard lesson: stuffing everything into one conversation eventually degrades performance through attention diffusion, while restarting sessions throws away learning unless state lives outside the model.⁸ Anthropic’s context-engineering guidance treats the window as an attention budget and recommends keeping context informative yet tight—including patterns where agents write notes persisted outside the window rather than hoping history remains perfect.⁹

For FDE engagements the external object is more specific than a free-form notes file. It is a task world: a temporary, purpose-shaped organisational model with an inspectable manifest.¹ If a walk leaves only a chat transcript and a final answer, you have an outcome without a world—you cannot audit what the agent believed it inhabited, compare two intents over the same fabric, or expire what was never declared.¹

And the walk itself is two artefacts: the answer and the path. Summaries delete dead ends by design; dead ends are informative.¹⁰ That is why “paste the summary into the next chat” is not continuity architecture.

Three persistence layers

Give every substantial engagement a surface-independent identity:

engagement_id: eng-demo-altis-2026
task_world_id: tw-48c46560a3

Then store three layers. Only the third should routinely enter the model.

1. Immutable walk log

Append-only. Every MCP request and result pointer, page opened, edge followed, rejected region, timestamp, tool/corpus version, client surface, and receipt. This is source evidence and telemetry—not active prompt material.¹⁰

2. Task-world manifest

The inspectable checkpoint after meaningful turns:

• parent intent, client, role/lens, as-at date, access scope
• current understanding
• accepted findings
• unresolved hypotheses
• rejected alternatives and why
• known absences
• sources opened and evidence pointers
• acceptance criteria, engagement stage, next move
• expiry / promotion policy

That is the parent doctrine applied to FDE continuity, not a new religion.¹

3. Active working set

What a retail or coding client should load on resume: parent intent, latest checkpoint, critical constraints, selected framework handles, accepted evidence pointers, open questions, and the next-stage harness. Not the entire walk.

Full-fidelity history outside the model.
Compact, inspectable working state inside the model.

In long-running agent terms: archive + reference checkpoint + working context; stateful kernel, fresh worker.⁸ In database language from the parent: bronze sources, durable wiki warehouse, task world as materialised view, active context as CPU cache.¹

Useful re-reading vs wasteful re-derivation

Re-walking is not automatically failure.

Useful re-reading happens when the wiki may have changed, the intent shifted, a conclusion is disputed, the as-at date matters, or a deeper source read is newly warranted.

Wasteful re-derivation happens when the system forgot why it entered a region, which alternatives it checked, which paths were dead ends, what it had already accepted, and what the next question was—then pays for the multi-hop investigation again and may land somewhere slightly different without a receipt of the change.

The fix is not “never touch the wiki again.” The fix is a manifest that makes forgotten state expensive to justify.

Continuity operations (illustrative interface)

A consultancy-facing MCP or platform API can expose the engagement store directly:

start_task(client, role, intent)
resume_task(task_world_id)
checkpoint_task(task_world_id, current_state)
show_walk(task_world_id)
show_task_world(task_world_id)
close_task(task_world_id)
promote_learning(task_world_id)  # human-gated

Ordinary wiki tools associate reads with the active task. A consultant says “Continue the account opportunity review.” Any capable client calls resume_task, receives the working set, and continues. It should not matter whether ChatGPT compacted private conversation state, whether the user switched to retail Claude/Claude.ai,¹² or whether work escalated to a coding agent.

The engagement state belongs to your system.

That is what makes a handoff chain loss-resistant:

retail chat → coding agent → specialist → proposal compiler → delivery → client environment

…all sharing the same task_world_id, evidence set, rejected paths, and acceptance harness. The summary is one generated view over a full-fidelity asset—not the asset itself.

Controlled experiment: design before mythology

Proof burden one is not a vibes story about vendors. It is a disciplined separation of evidence classes.

That honesty is not a retreat. Documented retail access without a retention contract, coding-agent compaction, and synthesis-style consumer memory already justify external state.^4,5,6,9,12 You do not need a reverse-engineered TTL to stop treating chat as the store.

Resume/handoff prototype (two surfaces)

Proof burden two: a minimal working system. The prototype in prototype/task_world.py implements the three layers and continuity ops. Surfaces are labels—retail_chat and coding_cli—because the point is platform ownership, not a fake claim that live vendor UIs were driven from this machine.

Demo script (executed; receipt on disk):

1. retail_chat / start_task — engagement for “strongest defensible FDE opportunity for next week’s account review,” with explicit access scope.
2. Walk steps — open candidate frameworks; reject “generic intranet chatbot” with a why and evidence pointer.
3. checkpoint_task — accepted findings, rejected alternatives, absences, next move.
4. coding_cli / resume_task — second surface loads working set only (not full walk).
5. Further walk + checkpoint — discovery harness draft recorded; rejection still present.
6. verify — invariants all pass.

What the second surface receives is a packet: working set + pointers to walk and manifest. What it must not require is the first surface’s private chat blob.

File only what earned persistence. Hard multi-hop synthesis can become typed derived cache linked to supports; trivial one-page lookups can die with the task.^1,10 Persist the expensive, reusable, and integrative; recompile the volatile and task-local.¹

The operative prompt is compiled infrastructure

Once the store exists, the consultant’s short message stops being the world specification. The operative prompt is compiled from:

• client world (what is true here),
• capability / practice kernel (how we interpret and deliver),
• consultant intent (what decision is needed now),
• engagement stage,
• authority and acceptance harness.

Frameworks do not merely get quoted at the end. When selected into the working set they change what the model notices, which alternatives it rejects, and where it demands deterministic checks. That is authorised epistemic conditioning—not a prompt-engineering academy for two hundred people.

Operating literacy remains: state the outcome, correct false assumptions, inspect receipts, escalate. The system supplies breadth and memory that used to take years of apprenticeship to carry in one head.

Privacy, tenancy, and access threat model

Proof burden three: external state is powerful and therefore dangerous. A short threat model is load-bearing, not an appendix apology. Full table: prototype/THREAT_MODEL.md.

Tenancy

Promotion is never “the model thought it was useful.” Client-specific findings remain client-local. General failure shapes may enter the consultancy kernel after de-identification and a human gate. Doctrine-level promotion is rarer still.

Threats that matter

• Vendor memory as shadow store — secrets typed into retail chat may be synthesised into consumer memory products. Prefer platform SoR; scope or disable consumer memory under client policy.⁵
• Access-scope widening — compile must not grant more corpus than the user’s authority. Record access_scope on every start/resume; enforce server-side on tools.
• ID leakage / cross-tenant resume — treat task_world_id as a capability; authorise resume; audit surfaces.
• Working-set overshare — ship pointers and decisions, not the entire walk, into every turn.
• Laptop session files as competing truth — Claude Code JSONL and Codex saved chats are valuable evidence inputs, not the firm’s engagement authority.^6,7
• Stale manifests — as-at dates and expiry policies prevent confident wrongness after the fabric moves.

If you cannot answer who may resume, what scope they inherit, and what may be promoted, you do not yet own the memory layer—you have only externalised the mess.

Surface comparison (without scoreboard cosplay)

Keep the doorway. Move the memory job. The companion slogan still holds: the model is not the memory—and neither is the retail chat UI.¹¹

Implementation checklist (next engagement)

What this is not

• Not a claim that retail MCP is useless—accessibility is a commercial superpower.
• Not reverse-engineering of hidden reasoning or undocumented retention constants.
• Not the full multi-person Engagement World product (sibling territory).
• Not a tutorial on wiring generic MCP connectors.
• Not permission to dump every historical tool result into every active window.

Close

The frontier model is interchangeable reasoning capacity—the processor, not the institutional memory. MCP is the nervous system that lets any capable client navigate a compiled field. The FDE remains the human interface for relationship and judgement. The task world preserves continuity. The harness supplies truth. The engagement supplies learning.

Consultants should keep talking to the products they already know. Platforms should stop hoping those products will quietly become the engagement database.

The model may forget the walk.
The FDE system must not.

Prototype artefacts for this article live beside the source package under prototype/. Experiment honesty notes are in prototype/EXPERIMENT.md.