Why a Room of Coding Agents Needs an Operating Model

Munder Difflin is a local-first desktop harness for real terminal-based coding-agent CLIs. The question is not simply whether several agents can produce more work than one, but whether a person can understand, direct, and recover that work once it is spread across independent processes. This series examines the operating model Munder Difflin builds around that problem: the human remains the authority, Michael acts as the coordinating clone, worker agents execute in their own terminals, and a local hive preserves the relationships among them. The useful test is whether parallel work becomes observable, persistent, and governable rather than merely more abundant.

The product is a coordinator, not a new agent

Munder Difflin does not replace the coding CLIs it launches. Its repository describes an Electron application that wraps tools such as Claude Code, Codex, Gemini-related CLIs, Grok, Kimi, Qwen, OpenCode, Crush, Pi, Copilot, Cursor, and custom commands. Each agent remains a real process with its provider's lifecycle, model choices, permissions, and limits. Munder Difflin supplies the surrounding control room: a floor where sessions appear as avatars, a terminal view for direct inspection, a command surface for intervention, and a coordination layer that lets the processes exchange durable work.

That distinction matters because a harness and an agent answer different questions. An agent decides how to interpret a task and what actions to take. A harness decides how that agent is started, observed, connected to other agents, and exposed to its operator. Munder Difflin can make a terminal process easier to supervise, but it cannot turn an unreliable provider bridge into a reliable one or make an ambiguous model response into a verified result. The product's value lies in the surrounding operating conditions.

The central relationship has three levels. The human tells Michael what outcome matters. Michael decomposes the request, routes pieces to suitable workers, tracks the floor, and handles routine clarification. Workers then use their own terminals and working directories to perform the implementation or investigation. The human is still above Michael: destructive operations, spending, scope changes, and conflicts that cannot be resolved inside the hive return to a native permission or human-interaction boundary. Calling Michael a clone is useful as a description of the relationship, not as a claim that the software reproduces a person's judgment.

The number of supported engines is consequently a secondary fact. A long provider list is only useful if the system can tell which engines can receive messages, report lifecycle state, resume a session, or preserve the safety posture the operator expects. The meaningful subject is the coordination product and the relationships it creates among a person, an orchestrator, independent processes, and a shared local substrate.

Why parallel terminals become a systems problem

One terminal is easy to reason about because the input, output, and responsibility are colocated. With several terminals, the operator faces a different problem: work can be progressing without being visible, a worker can need information held by another worker, a completed turn can leave durable knowledge nowhere, and an autonomous process can continue long after its assumptions have become wrong. Opening more windows increases execution capacity without solving any of those coordination problems.

Munder Difflin addresses them as three linked requirements.

Visibility means knowing what the agents are doing without reading every terminal continuously. The office floor uses avatar position, motion, stations, badges, and notifications to expose state at a glance, while a selected-agent panel preserves the raw terminal stream for close inspection. The visual design makes an important qualification: motion is valuable only when it communicates real state faster than a label. A character walking toward a file shelf is meaningful because it corresponds to observed file activity; it is not meant to be an animated substitute for evidence.

Persistence means that a useful decision or request survives a turn, a restart, or a worker's temporary absence. The hive gives agents durable identity and memory, places messages in inboxes and outboxes, and keeps a shared board, task ledger, and event trail. This does not create perfect knowledge. It creates inspectable places where knowledge and responsibility can be recorded, instead of leaving the whole team's state inside transient model context or terminal scrollback.

Governance means that the operator can constrain, redirect, or stop work without fighting several independent input channels. The system has a queue for automatic messages, tool gates, pause and steer controls, a circuit breaker, and native permission prompts. These controls do not guarantee a correct result. They reduce the chance that an active process will silently overwrite a person's draft, spend without limit, or continue a loop that the operator cannot see.

These requirements reinforce one another. Visibility without persistence produces a useful dashboard of amnesia. Persistence without governance can preserve a record of actions that no one could safely interrupt. Governance without visibility becomes a collection of opaque vetoes. Munder Difflin's distinctive ambition is to make the three operate around real local processes rather than to hide those processes behind a new conversational surface.

A simple division of labor shows why the combination matters. Imagine Michael sending one worker to inspect a failing build and another to compare a recent change with the test suite. The workers do not become reliable collaborators merely because they run at the same time. Someone has to know which process is still active, where a question should be delivered, whether a result is durable enough for a later decision, and what to do if one worker starts repeating itself. The floor can expose activity, the hive can preserve a request or result, and the control layer can hold delivery or escalate a risk. Each solves a different part of the same operational problem.

This also explains why the human is not reduced to a progress viewer. A person may want Michael to delegate routine investigation, yet still need to approve a destructive change, answer an ambiguity, or reclaim a terminal for direct work. The system's usefulness depends on preserving that change of role. Automation should reduce the number of turns the person must supervise, not erase the points where their authority or context is indispensable. In Munder Difflin, coordination is successful when the operator can step back without losing the thread and step in without having to fight the machinery.

The operating model in one view

flowchart LR H[Human operator] -->|intent, scope, critical approval| M[Michael / GOD orchestrator] M -->|decomposes and routes work| W[Worker agents] W -->|execute in real provider CLIs| P[PTYs and provider bridges] P -->|raw terminal and lifecycle signals| O[Office floor and terminal view] W -->|memory, mail, tasks, board, log| V[Local hive] O -->|status and evidence| H V -->|context and coordination| M M -->|critical action or conflict| H

The diagram is deliberately more modest than the office metaphor. Michael is not the mechanism that moves bytes, commits files, or authenticates every provider; the main process and its bridges do that work. The floor is not the source of truth for a task; it is an observation surface over terminals, hooks, and hive state. The hive is not a shared mind in which every agent can edit everything; its usefulness depends on ownership rules and delivery paths. Keeping those distinctions visible is what prevents a friendly interface from concealing a fragile system.

Local-first is a boundary, not a promise of isolation

The core arrangement is local. Agents run as local processes, the hive is a local Git repository, and the hook server uses a local Unix-domain socket. The Electron renderer does not receive unrestricted Node access: the current application keeps Chromium's renderer sandbox active, enables context isolation, disables Node integration, and sends privileged filesystem and Git requests through a typed preload bridge to the main process. Registered working directories are path-validated on the main side. Those choices reduce the privileges of the UI and keep the coordination record inspectable on the operator's machine.

But “local-first” should not be read as “nothing ever leaves the machine.” Provider CLIs may call their own services. Optional voice, Slack, webhooks, update checks, and integration features introduce their own network paths when configured. Even a local agent can act on a directory the user has granted it. The security boundary therefore narrows the surface; it does not remove the need to choose providers, directories, permissions, and integrations carefully.

The same restraint applies to privacy claims. Official builds document a minimized, anonymous product-analytics contract: for example, a message-sent event records a count and a surface such as terminal or composer, not the message text, its length, a hash, a repository, or a transcript. Opt-out controls exist, and builds from source do not carry the official analytics key. That is meaningful evidence of a deliberate boundary, not an independent audit of every optional provider or network service.

Read the repository as an evolving system

Munder Difflin's repository contains both design history and current implementation evidence. An earlier MVP specification describes attaching to existing tmux panes and explicitly excludes agent-to-agent messaging, remote dashboards, code editing, and app-owned process spawning. The current README, architecture document, release notes, and source code describe a later product with app-spawned PTYs, a local hive, Michael as orchestrator, a built-in IDE, multiple provider bridges, memory, voice, and integrations. Treating the two descriptions as if they described one frozen release would produce a false picture.

The right interpretation is temporal rather than adversarial. The older specification still explains the original separation between raw terminal output and structured events, and it exposes the design questions that shaped the floor. Current code and release material are stronger evidence for what the main branch does now. The changelog also records cases where a bridge was reviewed in source but still awaited live verification with a real key or provider. In an evolving agent harness, “designed,” “selectable,” “hook-integrated,” and “runtime-proven” are different states.

That distinction gives the reader a practical standard for the rest of this series. Munder Difflin is most interesting not because it makes a room of agents look busy, but because it tries to give that room an operating model: a visible execution surface, durable coordination, and controls that leave final authority with a person. The next question is how the application can show both what a CLI actually printed and what it is doing at a meaningful lifecycle boundary. That is where its terminal and event planes meet.

References