Munder Difflin's Agents Never Touch Git. That One Rule Is the Part Worth Stealing

A pixel-art parody of The Office is running real Claude Code sessions as characters on a 2D floor. Underneath the sprites sits a serious file-based coordination design, and one honest admission about where the human control actually lives.

The repo is a joke about a fictional paper company, and its design document cites Hearsay-II.

That is roughly the experience of opening chaitanyagiri/munder-difflin, which sits at about 3.8k stars as of this weekend and spent Friday near the top of Hacker News. On the surface it's an Electron app where your Claude Code sessions become recolored characters from The Office, walking between desks on a Pixi.js floor while envelopes fly desk to desk when they message each other. It is very funny and the pixel art is good.

Then you open HIVE.md and find a table mapping each user-facing behavior to the pattern it implements: MemGPT-style self-managed memory, stigmergy, blackboard architecture citing Hearsay-II, the actor-model mailbox, LangGraph-style supervisor. Followed by a numbered list titled "Locked design decisions," which is not a phrase you usually get from a weekend Office parody.

I care about exactly two of those decisions. Both are about writes, and you can copy them into any multi-agent setup you're running, today, without installing this app.

The problem this design is actually solving

Point five agents at the same repository and you will meet .git/index.lock within the hour. Git takes an exclusive lock on the index for the duration of most operations. Two agents staging changes at the same moment produce one failure, and the failure mode most agents choose is to retry, then delete the lock file, then corrupt something.

Most multi-agent harnesses answer this with orchestration: worktrees, branch-per-agent, a merge queue, a coordinator that hands out turns. Those work and they add machinery. Munder Difflin's answer is smaller and, I think, better. Agents don't get git at all.

Here is the position: in a multi-agent system, the durable design work is deciding who may write what, and the interesting part of this repo is that it answers that question twice, at two different layers, and writes both answers down. Whether you ever launch the app is beside the point.

Two rules, and the directory that enforces them

Rule one: single committer. Everything the hive knows lives in one local git repo, and only the Electron main process commits to it. Agents never call git. They write plain files. The design doc names the failure it's avoiding directly, .git/index.lock corruption under concurrency, and credits GitHub Desktop's commit-queue pattern as prior art. The main process commits with retry, backoff, and stale-lock cleanup, because it is the one process that has to deal with git being git.

Rule two: single writer per file. Each agent writes only inside its own agents/<id>/ directory. Nothing is ever written by two processes. Cross-agent delivery happens because the router, again in the main process, moves a message file out of a sender's outbox/ and into a recipient's inbox/.

The on-disk layout makes both rules visible at a glance:

hive/
  PROTOCOL.md            # the agent-facing contract
  registry.json          # roster: agent, role, capabilities, status, seat
  board.md               # shared blackboard, co-authored plans
  tasks.json             # task ledger
  log.jsonl              # append-only event feed
  agents/<agentId>/
    identity.md          # who am I, my role, my capabilities
    memory.md            # long-term memory, read at start, appended to
    inbox/               # messages delivered TO me
    inbox/.done/         # processed messages, kept for audit
    outbox/              # messages I want to SEND
    cursor.json          # { lastProcessed: <msgid> }

Three details in there are doing real work. Each message is one JSON file, written via temp file plus atomic rename, never a shared mailbox file that two agents co-edit. The event log is append-only and every consumer tracks its own cursor. And board.md, the one genuinely co-edited file in the system, is written by exactly one agent, the supervisor, acting as scribe.

Notice what's missing: no database, no message broker, no lock manager. The concurrency guarantee comes from the filesystem's rename semantics and from a layout where contention is structurally impossible. That's the part I'd steal.

The message envelope, and how it avoids two agents talking forever

The message schema is described as FIPA-lite, which the doc explains as taking the one useful idea from FIPA-ACL and KQML, the speech act, and dropping the LISP syntax. Seven fields: id, conversation, in_reply_to, from, to, act, subject, body, plus hops, requires_reply, needs_human and a timestamp.

The act field is an enum: request, inform, propose, query, agree, refuse, done. And the anti-livelock rules fall straight out of it. Only request, query and propose obligate a reply, so inform and done are terminal and a conversation can end. Every reply increments hops, and past a cap the supervisor escalates rather than letting two agents ping-pong. Re-seeing a message id you've already processed is a no-op, because cursor.json remembers.

If you have ever watched two agents apologize to each other for six turns, you already understand why a terminal speech act matters.

The autonomy loop is equally plain. When an agent finishes a turn, Claude Code's Stop hook fires and posts to a Unix socket. The main process checks that agent's inbox, and if there are unread messages it replies {"decision":"block","reason": <messages>}, which keeps the agent working instead of stopping. The guard against infinite recursion is stop_hook_active, Claude Code's own flag for exactly this. Idle agents get woken when they're holding unread mail.

That is a whole autonomous work loop built from one documented hook and a directory.

Where the human control actually lives

Now the part that should give you pause, and to the project's credit it says so out loud.

A privileged supervisor agent, called GOD and seated in Michael's office, adjudicates cross-agent traffic. Routine requests it resolves itself so the system keeps running unattended. Critical items get escalated to you. The README lists three critical categories: spend, destructive operations, and scope changes. HIVE.md lists four, adding unresolvable conflicts.

Then this, from the design doc, about what defines "critical":

Its escalation policy (what counts as "critical") lives in its system prompt and is the primary control surface, tune the prompt, not the code.

Read that as a security property rather than a configuration note. The rule that decides whether a destructive operation or an unbudgeted spend reaches a human is a paragraph of English handed to a language model, which then judges each case. Everything below it is hardened. The write path is single-committer, the mailbox is atomic, the loop cap is a counter. The gate on top is a persuasion surface.

The taxonomy itself is good. Spend, destruction, scope, deadlock is a compact and honest list of what a person still has to decide when a room full of agents is working. I'd argue that four-item list is the second most reusable thing in the repo. But a taxonomy is a policy, and a policy enforced by a prompt is a policy an agent can talk itself out of.

Put this into practice

You do not need the app to use any of this. Two evenings, roughly, and you can retrofit an existing setup.

1. Turn your agent mailbox into a directory. One JSON file per message, filename <timestamp>-<msgid>.json so it sorts, written to a temp path and then renamed into place. Atomic rename on the same filesystem is the whole concurrency story. Delete nothing; move processed messages into .done/ so you keep an audit trail.

2. Elect one committer. Whatever your orchestrator process is, it gets the only git credentials in the system. Agents write files. The orchestrator commits, with retry and backoff. If your agents currently run git commit themselves, this is the single highest-value change on this list.

3. Give each agent exactly one writable directory. Its own. Everything else is read-only to it. This is easier to enforce than any locking scheme and it makes "who wrote this" answerable from the path alone.

4. Add hops and a cursor before you need them. A hop counter on every message with an escalation at the cap, and a per-agent record of the last processed message id. Both are a handful of lines and both prevent failure modes that are miserable to debug at 2am.

5. Write your escalation list down, then put it somewhere enforced. Start with the four categories: spend, destructive operations, scope changes, unresolvable conflicts. Then do the thing Munder Difflin doesn't, and back at least the first two with a mechanism. A hard token ceiling in the harness. A command allowlist in a PreToolUse hook that returns a deny for rm -rf, force pushes, and anything touching production credentials. Keep the prompt as the fast path for judgment calls, and keep code underneath it for the two categories where being talked around is expensive.

6. If you want to read the whole thing, clone it and open two files. HIVE.md for the coordination design, SPEC.md for the terminal and event plane. You'll get more out of thirty minutes with those than an hour of running the app, and neither requires a build. The app itself needs Node 18+, a C/C++ toolchain for the node-pty native addon, and Claude Code on your PATH.

Honest limitations

This repo argues with itself in a few places, and you should know where before you rely on it.

The README says the supervisor escalates critical items "into an approvals queue you act on," and the feature table lists an approvals panel. HIVE.md says the opposite: "there is no separate approval queue," with human-in-the-loop handled natively through Claude Code's own permission prompts in the supervisor's session. Both documents are on main right now. My read is that the design doc describes the current intent and the README describes a UI that exists, but you'd want to check which one your build does before wiring anything to it.

The memory claims need the same care. The README calls the memory layer "the fastest memory layer in the world." HIVE.md, discussing whether to adopt MemPalace over MCP, says to validate its retrieval first because "its public benchmarks are overstated per independent audit." The shipped Phase 3 integration wraps the MemPalace CLI and the doc's own status line says it still "needs a live mempalace install to validate retrieval end-to-end." Take the architecture seriously. Take the superlative as marketing.

Platform support is stated twice, differently. The status note says macOS (signed), Windows and Linux builds are all available on the releases page. The prerequisites section three paragraphs later says "macOS (macOS-first; Windows/Linux untested)."

The roadmap is honest about three gaps that matter. Avatar movement today "mixes real hooks with a synthetic fallback loop," so what you're watching on the floor is not always what the agent is doing. Per-agent memory.md grows without bound, with reflection and summarization still unbuilt. And durable persistence of agents, layout and command history across restarts is listed as future work, so a restart costs you the room.

It is Claude Code specific, whatever the secondary coverage says. The README's first line calls it a local multi-agent harness for Claude Code, the default spawn command is claude, the event plane is built on Claude Code hooks, and the cost telemetry reads ~/.claude/projects/ JSONL transcripts. You can point it at another command, and the hive will keep working because it's just files, but the autonomy loop rides on hooks that other CLIs implement differently or not at all.

The license splits. Code is MIT. The bundled pixel art comes from LimeZu via shahar061/the-office under a free-version license that is non-commercial only, and the recolored Office cast inherits that restriction. To ship anything commercial you replace the art or buy a LimeZu license. The repo states this clearly, in an admonition block, which is more than most projects manage.

And the obvious one: every avatar is a real Claude Code session. Fifteen cute characters walking around a floor is fifteen concurrent agent sessions billing to your account. The Activity tab surfaces token counts and an estimated cost per agent per session, which is genuinely useful and is also an estimate.

What I keep thinking about

The joke is the distribution strategy and the architecture is the payload. That combination worked, which is worth noting on its own: a file-based coordination design nobody would have read as a blog post got read by thousands of people because it came wrapped in sprites.

The question I can't put down is the prompt-as-control-surface one. "Tune the prompt, not the code" is a real design philosophy, it makes the escalation policy editable by non-programmers, and it is going to be how most agent harnesses ship, because it's the fastest thing to build. Munder Difflin at least writes it in the design doc where you can see it. Most tools with a supervisor agent have the same property and never say so.

So go look at yours. Find the thing in your stack that decides what interrupts a human, and check whether it's a conditional or a paragraph. If it's a paragraph, that's not automatically wrong. But you should have picked it on purpose.

---

Sources: the Munder Difflin repository, its README and HIVE.md design document, both read from main on August 23 2026; the project site; the Hacker News discussion. Star count taken from the repository's shields.io endpoint on August 23 2026, because GitHub's own HTML pages have been serving stale counts for this repo.