Inspiration

It was 2 AM with seven Claude Code terminals open across two monitors. One was refactoring a parser, one was writing tests against the half-finished output, one was blocked waiting for me to paste a stack trace from the first into its prompt window. Another had silently exited an hour earlier after its input pipe closed and I hadn't noticed. The rest were somewhere between hallucinating a function that didn't exist and sitting idle, burning context tokens while they waited their turn. I wasn't coding anymore, I was a human message bus with terrible throughput and worse uptime. I closed the laptop and realized the topology was inverted: the agents should route work between each other, not through me. That whiteboard moment became Daddy Agent.

What it does

Daddy Agent is a local-first orchestration layer that turns a kanban board into the control plane for a team of autonomous coding agents. You define roles, drop tasks on the board, and a scheduler spawns agents in parallel that share a structured task graph and a typed message bus. Agents talk to each other directly, spawn subagents when a job needs to fan out, mutate the board as work progresses, and emit diffs that surface as per-card review surfaces with accept, reject, and comment semantics. Solo mode runs one agent against a self-managed backlog. Team mode scales it into a multi-process organization with cross-team direct messages, a live process inspector, deep session analytics covering shell calls, reasoning traces, and subagent fan-out, and a context monitor that breaks the model's working window into six readable categories in real time.

How we built it

The shell is Electron with a React and TypeScript renderer, Zustand for state, and Tailwind for the Aurora liquid-glass UI. Underneath sits a service layer in the main process that watches Claude's local session directory with debounced file watchers, streams session logs line by line, and feeds them into a chunk builder that produces a clean timeline of user turns, assistant turns, system events, and compaction markers, each annotated with token, cost, and tool metrics. A resolver reconciles spawn events with their parent calls so every running process is enriched with its team, role, and color. The message bus is split by transport: leads consume a streaming input channel and have inbox writes translated into that channel for them, while teammates run as independent processes whose mailboxes are picked up by the runtime between turns. Task references are first-class typed objects that survive every persistence boundary, encoded into markdown with invisible metadata so links round-trip through messages, comments, and descriptions without losing identity. A cache fronts the parser, virtual scrolling keeps the timeline cheap on long sessions, and a built-in MCP server exposes the whole control plane to external tools and agent plugins.

Challenges we ran into

The hardest subsystem was the inter-agent transport. Our first design relayed every teammate message through the lead, which produced duplicate deliveries, response loops where the lead answered on behalf of a teammate, and one memorable evening where two agents got into a polite recursive argument about which of them owned a migration. The fix was to disable the relay entirely, let the runtime deliver teammate-to-teammate messages directly, and keep the lead relay only for the lead's streaming input. Other sharp edges: post-compaction amnesia required a recovery layer that re-injects team-management instructions when the runtime collapses earlier turns, structured task references had to survive markdown serialization and IPC validation on the way back to the renderer, the diagnostic log for the CLI installer had to be size-capped and deduplicated on a short interval to keep rapid status polls from amplifying disk writes, and the chunk builder had to learn that a clean shutdown handshake is an ending event, not ongoing activity.

Accomplishments that we're proud of

✦ Zero setup, zero API keys, fully local, fully free. No backend, no telemetry, no hosted dependency.

✦ A kanban board where cards write code back, with per-task diff review and structured task references that survive every persistence boundary.

✦ A deduplicated, loop-free cross-agent message bus that survives spawn storms and compaction events.

✦ A six-category context tracker that decomposes the model's working window across CLAUDE.md files, mentioned files, tool outputs, thinking, team coordination, and user prompts, with phase-aware accounting across compaction resets, so token spend stops being a black box.

✦ A post-compaction recovery protocol that keeps long-running multi-agent teams coherent across context window collapses.

✦ A canonical feature-slice architecture that lets new cross-process features land without rewriting the renderer.

What we learned

Coordination cost, not raw model intelligence, is what bounds a multi-agent system. The whole product is a bet on a simple inequality:

$$\max_{i \in [1,n]}(t_i) + C(n) < \sum_{i=1}^{n} t_i$$

Read in plain English: the time to finish a batch of work in parallel is roughly the slowest single task t(i) plus the coordination overhead C(n) of running n agents together, and that total has to come in under the cost of doing every task one after another. When C(n) grows faster than the team (relay loops, duplicate deliveries, context bloat from cross-chatter), one good agent beats a crowd. When C(n) stays small (direct mailboxes, structured references, pruned context), the team wins decisively. Most of our engineering effort is a sustained attack on C(n): better mailboxes, typed task references, context hygiene, deterministic message identity, and a UI that makes the cost legible. The second lesson: the kanban board is the API. Once tasks became addressable objects with IDs, statuses, and typed references, the agent protocol, the review surface, and the navigation model all collapsed into one consistent abstraction.

What's next for Daddy Agent

✦ A marketplace of agent roles and team templates so a new user can instantiate a frontend squad or a migration strike team with one click.

✦ Hosted teams with a sync protocol so agents can keep working against a remote workspace while the laptop is closed.

✦ Voice-driven standups: speak a goal, get a populated board and a spawned team back.

✦ Cross-repo and cross-project orchestration so one operator can run several products from a single control plane.

✦ A deeper plugin surface so any external tool can register itself as a first-class teammate with its own inbox and task permissions.

✦ Distributed execution across multiple machines with a shared task graph, so coordination cost stays bounded even as the team grows past what a single host can schedule.

✦ And the dream: a night mode where you commit a backlog before bed and wake up to a stack of reviewed, tested PRs waiting on the board

Built With

Share this project:

Updates