Experimental system • Multi-agent coordination • Active dogfood

DogBuild

This page answers: How can multiple AI coding agents coordinate through a durable, auditable control plane without requiring humans to manually relay context?

Currently under active development and not yet a production-ready autonomous-agent platform.

Problem

When coordinating multiple AI agents across different vendors (Claude Code for implementation, ChatGPT for review, etc.), without a control plane, the human becomes the message bus:

  • Implementation complete → human copies result to reviewer
  • Review findings → human carries feedback back to implementer
  • Every round of fixes requires manual relay

That manual relay is structural friction, not a habit to optimize. DogBuild explores how intent, authority, evidence, routing, and handoffs can become deterministic and auditable instead.

Challenge

Can you build a control plane that lets multiple agents coordinate without requiring a human to carry context between them? The technical challenge isn't AI reasoning—both Claude and ChatGPT can think. The challenge is authority, evidence, and routing: who decides what work happens, where does the proof live, and how does one agent hand work to another without losing the thread?

How the handoff works today

GitHub holds the durable control record. People and agents use MCP access to read current authority, publish work, and inspect exact-head evidence; the board points to the active route.

Founder Sets scope and makes merge or deployment decisions.
ChatGPT Strategy Reads and reconciles the board through the DogBuild MCP Server.
GitHub · source of truth Control board #180: current routing and authority Task issues and PRs: plans, findings, corrections and handoffs Exact commits, checks and artifacts: reviewable proof
Claude, Cursor and Codex Use the Cloudflare MCP portal's validated server connections for bounded task access.
GitHub Actions Runs checks for a specific commit and publishes CI evidence.
This map shows today's GitHub-first evidence flow. Chat remains a wake interface; the durable handoff is on the linked issue or PR.

Still in development: event-driven listener invocation, universal pre-write authority enforcement, and least-privilege tool boundaries. The diagram does not claim those controls are deployed.

My Contribution

I built DogBuild to test whether a GitHub-first, append-only control model could replace human relay. The core contribution is a lived dogfooding proof of concept demonstrating that the architectural approach is viable with two key design changes: record authority and evidence on GitHub (not in chat), and revalidate exact identity before every write. Full deterministic routing and scheduled autonomous invocation remain under development.

Architecture in use (as of September 2026):

  • GitHub-first evidence: The control model records current routing and authority lineage on control board #180. Detailed append-only evidence—plans, findings, corrections, and proof—remains on canonical issues and PRs. Chat is a wake interface only.
  • Three-server MCP portal: A Cloudflare gateway routes requests through three validated MCP servers (Claude, Cursor, Codex), providing documented tool access without needing unrestricted GitHub permissions. Portal connectivity and tool inventory are end-to-end validated through lived use; tool-surface enforcement and least-privilege boundaries remain in development per #169 and #167.
  • Append-only evidence: Worker plans, findings, and corrections are all timestamped and preserved on GitHub—corrections supersede earlier evidence without silent rewrites.
  • Authority tiers: Founder approves irreversible actions (merge, deploy, spend). Strategy routes work and reconciles evidence. Workers are bounded to assigned tasks.
  • Exact-SHA verification: Current policy and design in PR #184 document that GitHub mutations include exact head SHA and CI evidence linked on the control board for independent review. Universal mechanical enforcement of this policy remains under development per #176.

Engineering Decisions

GitHub as the durable source of truth

Choice: Record all authority, routing decisions, and task state as GitHub issues and PRs, not in chat or private documents. Rationale: GitHub's append-only model and versioning mean decisions can be audited and challenged. Chat disappears; GitHub remains. Trade-off: Slower initial decisions, but decisions become durable and auditable. Mechanical enforcement of policy via the control MCP server remains under development per #176.

Append-only evidence without silent rewrites

Choice: All worker findings, corrections, and supersessions remain visible as separate timestamped comments; never edit or delete historical evidence. Rationale: Prevents defenders of bad decisions from rewriting history. An auditable trail makes blame-shifting impossible. Trade-off: The control board becomes verbose, but transparency is the point.

Exact identity revalidation before every write

Choice: Immediately before any GitHub mutation, the worker re-reads current control state and validates repository, task, role, generation, and requested effect match live GitHub. Rationale: Prevents scope creep from stale chat instructions or missed updates by another worker. Trade-off: Adds latency, but prevents silent authorization drift.

Fail closed on ambiguous authority

Choice: When evidence is missing, conflicting, or stale, stop instead of guessing. Rationale: A blocked worker is better than a worker that silently violated its authority boundary. Trade-off: Requires human intervention to resolve ambiguities, but keeps the system honest about what it doesn't know.

Separate implementation and review

Choice: The session that implements a change cannot be the same session that approves and merges it. Rationale: Self-approval creates conflicts of interest. Independent review catches blind spots. Trade-off: Requires coordination between workers, but prevents a single agent from unilaterally shipping untested code.

Infrastructure-critical verification is adversarial

Choice: For changes to DogBuild itself, happy-path tests are insufficient—require fault-injection, security-negative, high-volume, and boundary-case tests before deployment. Rationale: Control planes must fail gracefully; undiscovered edge cases in routing or authority are catastrophic. Trade-off: Verification takes much longer, but the trust cost is worth it.

Outcome

Completed and in use today:

  • GitHub-first control board and append-only communication model—demonstrates the approach through lived dogfooding
  • Three-server Cloudflare MCP portal—end-to-end validated through lived use
  • 53-tool MCP inventory and independent Matrix V3 classification—every tool's authority tier is documented
  • Founder/Strategy/worker authority model—GitHub-documented and process-in-use through lived dogfooding; universal mechanical enforcement remains under development

In review or awaiting deployment:

  • DogBuild Control MCP package—merged, awaiting exact-SHA proof verification
  • Exact-SHA CI aggregation—policy/design documented per PR #184; mechanical enforcement pending #176
  • Comment-policy tool—unresolved review findings per PR #174
  • Tool-surface enforcement and least-privilege identity—in design/development per #169 and #167

Deferred pending safety findings repair:

  • A listener prototype exposed webhook authenticity, state safety, and schema validation gaps. That safety work is deferred until the fixes can be independently verified.

Evidence

Lived dogfoodingThe architecture described above is not theory—it is in active daily use across the DogBuild project itself. Every strategy decision, worker assignment, and verification result lives on GitHub.
Append-only evidence in practiceEvery worker plan, finding, correction, and disagreement is timestamped and preserved on the control board—no silent rewrites, full audit trail visible.
Authority documentation and process evidenceAGENTS.md documents worker responsibilities and boundaries; control board #180 records assignments and scope constraints. These prove documented governance processes, not mechanical enforcement. Automatic enforcement of authority boundaries remains pending #176.
Multiple agents coordinating via GitHub-first handoffsGitHub repository demonstrates Claude and Codex implementing and reviewing different tasks with evidence-based handoffs on the control board. Scheduled autonomous invocation and full pre-write authority revalidation remain under development; current handoffs still involve human wake-signal participation.

What This Project Demonstrates

Durable governance in multi-agent systems

Authority hierarchies that remain explicit and auditable through GitHub-first documentation and append-only evidence trails. The goal is mechanical enforcement across agent boundaries; currently validated through lived process and review practices, with automatic enforcement mechanisms under development.

Append-only evidence as a system property

How to preserve full audit trails and correctness proofs while still allowing corrections, supersessions, and reversals of earlier decisions.

GitHub as a control plane

Using issues, PRs, and exact-SHA proof as the durable source of truth for deterministic multi-agent routing—not as a code repository.

Fail-closed system design

How a control plane can stop and ask for human direction when faced with ambiguous or conflicting evidence, rather than silently guessing.

This project demonstrates my ability to build distributed systems that remain auditable, controllable, and transparent to independent review through real use within the DogBuild project.

Reflection

DogBuild started with a simple observation: when both ChatGPT and Claude exist and can implement and review code, but a human still has to manually carry context between them, the bottleneck isn't reasoning—it's governance. Who decides what work happens next? Where does that decision live? How does one agent hand work to another?

The insight—after months of lived dogfooding—is that the core layers are solvable. Record authority and evidence on GitHub instead of chat. Revalidate exact identity before every write. Make corrections visible, not silent. These documented practices enable a pathway toward agents routing work to each other and approving findings without routine human relay—but this full capability remains the target and is not yet fully proven end-to-end.

DogBuild is not yet production-ready. Safety findings in the listener remain pending. Least-privilege identity is under development. Deployment will require explicit founder authorization with rollback proof. But the core architectural layers—durable, auditable control planes, GitHub-first evidence, and append-only decision trails—are proven through lived use. The path forward requires scheduled worker invocation and independent pre-write verification before full admission. The bottleneck was never the agents. It was always the governance layer.

Building systems where multiple agents coordinate without human relay?

Explore on GitHub Read the problem statement View experience Discuss a role or project