Anti‑Livelock Rules in Munder Difflin’s Communication Protocol

Munder Difflin’s FIPA‑lite messaging system prevents infinite ping‑pong between agents through three core anti‑livelock rules: terminal act designations, a bounded hops counter with god‑agent escalation, and idempotent message handling via unique IDs.

The anti‑livelock rules in Munder Difflin’s communication protocol ensure that autonomous agents can collaborate without getting trapped in endless request‑response cycles. These safeguards are implemented in the lightweight “FIPA‑lite” schema defined in HIVE.md and enforced by the system’s router and god orchestrator. Below are the three mechanisms that guarantee every conversation eventually terminates or escalates.

---

Terminal Acts: Only Request, Query, and Propose Obligate Replies

The protocol designates three speech‑act types as reply‑obligating: request, query, and propose. Every other act—including inform, agree, refuse, and done—is terminal and carries requires_reply: false.

This design guarantees that any conversation thread eventually hits a terminal act, cutting off the possibility of infinite back‑and‑forth. As defined in [HIVE.md](https://github.com/chaitanyagiri/munder-difflin/blob/main/HIVE.md), the recipient simply processes terminal messages without generating a response.

// A request that MUST be replied to
{
  "id": "2026-08-28T12-00-00-001Z-abc123",
  "act": "request",
  "requires_reply": true,
  "hops": 0,
  "to": "agent.coder",
  "body": "Please generate a TypeScript file for a file-watcher."
}

// An inform message—no reply required (terminal act)
{
  "id": "2026-08-28T12-00-05-001Z-def456",
  "act": "inform",
  "requires_reply": false,
  "hops": 1,
  "to": "agent.coder",
  "body": "File watcher generated successfully."
}

---

Hops Counter with God‑Agent Escalation

Every reply increments a numeric hops field tracked in the message envelope. The protocol enforces a hard cap on this counter; when exceeded, the god orchestrator intervenes instead of allowing agents to continue exchanging messages.

This bounded recursion mechanism forces escalation to a human operator before a livelock can develop. The hops property schema and escalation logic are specified in the low‑level protocol definition.

// A reply that increments the hop count
{
  "id": "2026-08-28T12-00-10-001Z-ghi789",
  "act": "inform",
  "requires_reply": false,
  "hops": 2,               // incremented from previous message
  "to": "agent.researcher",
  "in_reply_to": "2026-08-28T12-00-00-001Z-abc123"
}

When hops exceeds the configured threshold (commonly 5), the god agent surfaces the conversation for human review—breaking the potential livelock cleanly.

---

Idempotent Processing via Unique Message IDs

The third anti‑livelock rule relies on message deduplication. Every message carries a globally unique id field. Agents maintain a cursor.json file tracking processed IDs, and any re‑seen message ID is silently ignored as a no‑op.

This prevents duplicate handling from keeping a loop alive—if network retries or agent bugs cause message redelivery, the idempotency check stops the cycle before it begins.

---

Summary

Munder Difflin’s anti‑livelock rules combine three complementary safeguards:

• Terminal act classification—only request, query, and propose require replies, ensuring conversations reach endpoints
• hops counter with god‑agent escalation—enforces bounded recursion before human intervention
• Unique ID idempotency—prevents duplicate message processing from sustaining loops

These rules are documented in [HIVE.md](https://github.com/chaitanyagiri/munder-difflin/blob/main/HIVE.md) and enforced throughout the agent communication layer.

---

Frequently Asked Questions

What happens when the hops limit is exceeded?

The god orchestrator captures the conversation and escalates it to a human operator. Agents are blocked from sending further messages in that thread, cleanly breaking the potential livelock.

Which speech acts are considered terminal in Munder Difflin?

inform, agree, refuse, and done are terminal acts that do not require replies. Only request, query, and propose obligate the recipient to respond.

Where are the anti-livelock rules documented?

The primary specification lives in [HIVE.md](https://github.com/chaitanyagiri/munder-difflin/blob/main/HIVE.md) under the “Anti‑livelock rules” section. The message schema and hops property are detailed in [SPEC.md](https://github.com/chaitanyagiri/munder-difflin/blob/main/SPEC.md).

How does idempotent processing prevent livelock?

Agents track processed message IDs in cursor.json. If a message with a previously seen id arrives again, it is ignored. This stops re‑handling of duplicates that could otherwise perpetuate an endless exchange.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}