# How the GOD Agent (Michael) Orchestrates Task Assignment and Escalation in Munder Difflin

> Discover how the GOD agent Michael orchestrates task assignment and escalation in Munder Difflin. Learn about its autonomous role in dispatching tasks and monitoring stalled work.

- Repository: [Chaitanya Giri/munder-difflin](https://github.com/chaitanyagiri/munder-difflin)
- Tags: internals
- Published: 2026-08-20

---

**The GOD agent Michael serves as the autonomous central orchestrator in the Munder Difflin hive, bootstrapping via a dedicated PTY session, assigning tasks through the `dispatch` tool to generate kanban cards, and escalating stalled work via the `realtimeCompletionWatcher` monitoring loop.**

In the Munder Difflin repository, the "GOD" agent—implemented as **Michael**—functions as the single source of truth for coordinating autonomous agents. According to the source code in `chaitanyagiri/munder-difflin`, Michael manages the entire lifecycle of work orders through a three-stage pipeline: bootstrap and orientation, task assignment, and escalation management.

## Bootstrap and Orientation: Initializing the GOD Agent

When a fresh session begins, the renderer spawns a dedicated pseudo-terminal (PTY) specifically for Michael. In [`src/renderer/src/hooks/useHive.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/hooks/useHive.ts) (lines 49–58), the system establishes Michael’s session using the constant `GOD_ID = 'god'` and initializes the `pty-god` process.

Michael receives the `INITIAL_GOD_PROMPT`, a terse system instruction that commands the agent to:
- Read the memory file
- Review the current board state
- Check fleet health
- Begin orchestrating operations

This bootstrap sequence ensures Michael starts with complete context of the hive’s state before processing any user requests or Slack events that land in its inbox.

## Task Assignment: Dispatching Work Orders

Michael creates concrete *work-order* messages that the system transforms into task cards on the kanban board. The dispatch flow follows a strict protocol defined across multiple source files.

**The dispatch sequence works as follows:**

1. **Payload Construction** — Michael builds a dispatch payload using `buildSpawnCommand` or `remoteControlCommandForProvider` to define the task parameters.
2. **Hive Transmission** — The payload is transmitted via `hiveSend` with the parameter `to: "god"`, ensuring the GOD agent receives the instruction.
3. **Tool Execution** — The `dispatch` tool, defined in [`src/renderer/src/realtime/actions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/realtime/actions.ts) (lines 68–84), creates a structured task card containing `title`, `objective`, `context`, `constraints`, and `done-when` criteria, then posts it to [`hive/tasks.json`](https://github.com/chaitanyagiri/munder-difflin/blob/main/hive/tasks.json).

The `dispatch` tool exposes a formal interface that Michael invokes through voice or UI commands, converting abstract requests into trackable work items with specific completion criteria.

## Escalation and Follow-up: Monitoring Task Lifecycle

After dispatching a task, Michael continuously monitors its progress through the `realtimeCompletionWatcher` system. Located in [`src/main/realtimeCompletionWatcher.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeCompletionWatcher.ts) (lines 25–40), this module tracks the dispatched correlation ID and marks tasks complete when the assignee replies or the kanban card flips to "done."

**Escalation triggers include:**
- **Cost overruns** — When task execution exceeds budget thresholds
- **Breaker armed** — When circuit breakers detect failure patterns
- **No progress** — When the assigned agent fails to update the task within timeouts

When escalation is required, Michael receives notifications via `hiveSend` with `act: "inform"`. According to [`src/main/realtimeActions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeActions.ts) (lines 71–84), Michael can then invoke **re-dispatch**, **re-assign**, or issue **ping** and **steer** commands to unblock the responsible agent and redirect the workflow.

## The Complete Orchestration Flow

The full lifecycle of task management in the Munder Difflin hive follows a closed-loop system:

1. **Spawn** — Renderer creates Michael’s PTY (`pty-god`) via the hook in [`src/renderer/src/hooks/useHive.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/hooks/useHive.ts)
2. **Initial Prompt** — Michael processes `INITIAL_GOD_PROMPT` and drains its inbox to triage pending requests
3. **Ingestion** — User messages or Slack events arrive in Michael’s inbox, enriched via `enrichTaskPrompt()` into self-contained work orders
4. **Board Creation** — Michael sends messages `to: "god"` via `hiveSend`, populating [`hive/tasks.json`](https://github.com/chaitanyagiri/munder-difflin/blob/main/hive/tasks.json) with structured task cards
5. **Active Monitoring** — `realtimeCompletionWatcher` tracks each correlation ID for completion signals or stall conditions
6. **Escalation Loop** — Stalled tasks return to Michael’s inbox through the `act: "inform"` channel, triggering re-dispatch or intervention commands (ping/steer) via [`src/main/realtimeActions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeActions.ts)

The [`src/shared/agentProvider.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/shared/agentProvider.ts) file provides the provider-agnostic logic for spawning agents and wiring their PTYs, ensuring Michael can orchestrate any compatible agent in the fleet through a uniform interface.

## Summary

- **Michael** is the GOD agent (`GOD_ID = 'god'`) that serves as the hive’s central orchestrator in the Munder Difflin codebase.
- **Task assignment** occurs through the `dispatch` tool in [`src/renderer/src/realtime/actions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/realtime/actions.ts), which creates structured kanban cards with specific completion criteria.
- **Bootstrapping** happens in [`src/renderer/src/hooks/useHive.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/hooks/useHive.ts), where Michael receives the `INITIAL_GOD_PROMPT` and begins draining its inbox.
- **Monitoring** is handled by [`src/main/realtimeCompletionWatcher.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeCompletionWatcher.ts), which tracks correlation IDs and detects task completion or stalls.
- **Escalation** uses `hiveSend` with `act: "inform"` to return stalled tasks to Michael, who can re-dispatch or issue **ping** and **steer** commands via [`src/main/realtimeActions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeActions.ts).

## Frequently Asked Questions

### What is the GOD agent in Munder Difflin?

The GOD agent is a specialized autonomous agent named **Michael** that functions as the central orchestrator for the Munder Difflin hive. According to the source code in [`src/renderer/src/hooks/useHive.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/hooks/useHive.ts), Michael operates under the identifier `GOD_ID = 'god'` and manages all task assignment, monitoring, and escalation workflows within the system.

### How does Michael assign tasks to other agents?

Michael assigns tasks by invoking the `dispatch` tool defined in [`src/renderer/src/realtime/actions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/realtime/actions.ts) (lines 68–84). The tool constructs a work order with fields like `title`, `objective`, `context`, and `done-when`, then posts the task card to [`hive/tasks.json`](https://github.com/chaitanyagiri/munder-difflin/blob/main/hive/tasks.json). Michael builds the dispatch payload using `buildSpawnCommand` or `remoteControlCommandForProvider` and transmits it via `hiveSend` with the parameter `to: "god"`.

### What triggers task escalation in the hive?

Task escalation triggers when [`src/main/realtimeCompletionWatcher.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeCompletionWatcher.ts) detects stalled work through cost overruns, armed circuit breakers, or timeout conditions. When triggered, the system sends a notification to Michael via `hiveSend` with `act: "inform"`, allowing the GOD agent to re-assign the task or issue intervention commands like **ping** or **steer** from [`src/main/realtimeActions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeActions.ts).

### Where is the task dispatch logic implemented?

The primary task dispatch logic resides in [`src/renderer/src/realtime/actions.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/renderer/src/realtime/actions.ts), which defines the `dispatch` tool interface. Supporting functions for payload construction exist in the hooks layer, while the spawning mechanisms are implemented in [`src/shared/agentProvider.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/shared/agentProvider.ts). The monitoring logic that closes the assignment loop is located in [`src/main/realtimeCompletionWatcher.ts`](https://github.com/chaitanyagiri/munder-difflin/blob/main/src/main/realtimeCompletionWatcher.ts).