Agent orchestration patterns

Research Question

What agent orchestration patterns, verification strategies, and multi-model delegation techniques are demonstrated by Burke Holland's Anvil, Max, and the orchestrator/planner/coder/designer multi-agent gist — and which of these can be directly applied or adapted to build a personal AI assistant that operates without a local IDE?

Supporting questions:

• How does Anvil's "prove it, don't promise it" philosophy (SQL (Structured Query Language) verification ledger, baseline snapshots, adversarial multi-model review) differ from simpler single-agent coding loops, and what does that mean for trust in autonomous agents?
• What is the Orchestrator->Planner->Coder->Designer delegation pattern in the multi-agent gist, and how does parallelisation by file-disjoint phases work in practice?
• How does Max's persistent-daemon model — spinning up GitHub Copilot CLI (Command-Line Interface) workers, routing tasks, learning skills from skills.sh — differ from session-scoped agent invocations?
• What design choices would allow a personal assistant inspired by Max to work entirely through GitHub website interactions and mobile (no local IDE, no Codespace)?
• What are the failure modes and trust boundaries of adversarial multi-model review (as used in Anvil's "Forge" step)?
• How does session memory backed by SQL (as in Anvil and Max) compare to in-context memory for long-running autonomous tasks?

Findings

Executive Summary

[inference] The best-fit architecture for this repository is a GitHub-native assistant that uses durable verification artifacts, specialist delegation, and persistent external memory instead of a laptop-resident Max-style daemon. Sources: GitHub Copilot coding agent create a pull request (PR) ; GitHub Copilot Chat in GitHub ; Max documentation page ; Repo instructions URL

[fact] Anvil's published design centers trust on recorded checks, baseline-versus-after comparison, and a SQLite evidence bundle rather than on unverified agent prose. Source: Anvil project site

[fact] Burke Holland's four-agent gist separates orchestration, planning, coding, and design, and it only parallelizes work when file ownership does not overlap. Sources: Raw orchestrator agent file ; Raw planner agent file

[inference] Max shows that long-running assistants need layered continuity, but this repository must realize that continuity through GitHub-managed surfaces, repository state, and approved credentials rather than through an always-on personal machine. Sources: Max documentation page ; GitHub Copilot Chat in GitHub Mobile ; Repo instructions URL

Key Findings

1. [high] [inference] Anvil demonstrates that an autonomous assistant becomes more trustworthy when it records builds, tests, lint checks, baselines, and reviewer verdicts as durable evidence artifacts that can be inspected independently of the model's narrative summary. Sources: Anvil project site ; Prior completed research
2. [high] [fact] Burke Holland's four-agent gist enforces a delegation boundary in which the orchestrator coordinates phases and conflict avoidance, the planner researches and decomposes, and the specialists execute within explicitly scoped domains and files. Sources: Raw orchestrator agent file ; Raw planner agent file
3. [medium] [inference] The gist's assignment of Claude Opus to orchestration, GPT-5.3-Codex to coding, and Gemini to design should be treated as a role-routing heuristic tied to workload shape rather than as a universal fixed mapping for every repository. Sources: Raw coder agent file ; Raw designer agent file
4. [high] [inference] Max's three-layer continuity model of persistent live session, SQLite long-term memory, and conversation logging addresses different failure modes, making it more robust for long-running work than relying on in-context memory alone. Sources: Max documentation page ; Max README
5. [high] [inference] skills.sh, GitHub Copilot skills, and Max's learn-skill mechanism all converge on SKILL.md-based packaging, which means the repository can adopt community skill structure while still curating actual project skills through its separate upstream submodule. Sources: skills.sh docs ; Vercel guide to agent skills ; GitHub Copilot skills ; Repo instructions URL
6. [high] [fact] The repository's browser-first operating model already exposes documented assistant entry points in GitHub issues, the agents panel, GitHub web chat, GitHub Mobile chat, repository instructions, custom agents, and project skills. Sources: GitHub Copilot coding agent create a pull request (PR) ; GitHub Copilot Chat in GitHub ; GitHub Copilot Chat in GitHub Mobile ; GitHub Copilot custom agents ; GitHub Copilot custom instructions on GitHub
7. [high] [inference] Max's local daemon and Telegram bot are not directly portable to this repository because they depend on a continuously running machine and credentials that are outside the repository's approved credential table. Sources: Max documentation page ; Repo instructions URL
8. [medium] [inference] Adversarial multi-model review is a valuable critique layer after execution, but it cannot replace executable verification because reviewers can still miss state-specific, environment-specific, or integration-specific failures that only real checks expose. Sources: Anvil project site ; Prior completed research

Assumptions

• [assumption] The repository's published operating constraints remain authoritative during implementation planning, especially the owner's GitHub-website-plus-iOS workflow and the approved-credentials table. Source: Repo instructions URL
• [assumption] GitHub's documented web and mobile surfaces are sufficient as the user-facing control plane for an assistant even if they are less feature-rich than Max's daemon-plus-Telegram experience. Sources: GitHub Copilot Chat in GitHub ; GitHub Copilot Chat in GitHub Mobile ; Max documentation page

Analysis

• [inference] Deployability should be weighted more heavily than feature richness in this repository, because the owner's fixed control surfaces are GitHub web and iOS rather than a continuously running personal machine. Sources: Repo instructions URL ; GitHub Copilot Chat in GitHub ; GitHub Copilot Chat in GitHub Mobile
• [inference] Anvil's verification pattern deserves priority over sophisticated model routing, because evidence artifacts mitigate session-boundary and trust risks more directly than choosing among specialist models does. Sources: Anvil project site ; Prior completed research
• [inference] Max's continuity design is worth adapting only at the durable-state layer, because GitHub-native surfaces can reproduce instruction, memory, and workflow state without reproducing a laptop daemon's ambient presence. Sources: Max documentation page ; GitHub Copilot coding agent create a pull request (PR) ; Repo instructions URL

Risks, Gaps, and Uncertainties

• [fact] Max's public documentation is sufficient to establish the architecture pattern but not every internal implementation detail, so claims about exact internal routing logic or storage schema would overreach the available evidence. Source: Max documentation page
• [fact] Anvil's public site documents the philosophy and loop structure strongly, but deeper implementation details beyond the published description were not required to answer the transferability question. Source: Anvil project site
• [fact] GitHub Mobile has documented limitations around repository indexing and context quality, so a browser-first assistant may need repository preparation work to get the best possible answers in mobile contexts. Source: GitHub Copilot Chat in GitHub Mobile
• [inference] The exact boundary where GitHub-native workflows stop being sufficient and a dedicated long-running service becomes necessary remains unresolved and depends on how proactive or cross-channel the desired assistant must become. Sources: GitHub Copilot coding agent create a pull request (PR) ; Repo instructions URL

Open Questions

• [inference] At what point does a GitHub-native assistant need a dedicated service layer for proactive reminders, scheduled follow-up, or cross-repository memory instead of repository and workflow state alone? Sources: GitHub Copilot coding agent create a pull request (PR) ; Repo instructions URL
• [inference] Which assistant functions should be encoded as project skills versus repository instructions versus custom agents so that the system stays discoverable without becoming brittle? Sources: GitHub Copilot skills ; GitHub Copilot custom instructions on GitHub ; GitHub Copilot custom agents
• [inference] Can Anvil-style evidence bundles be expressed as a reusable GitHub workflow or skill pattern for this repository without adding new credentials or external infrastructure? Sources: Anvil project site ; GitHub Copilot skills ; Repo instructions URL

Output

• Type: knowledge
• Description: Transferable design patterns from Anvil, Max, and Burke Holland's multi-agent gist, with a concrete recommendation to implement a GitHub-native assistant that uses evidence-first verification, explicit role delegation, and durable external memory rather than a local daemon.
• Links: Anvil project site ; Max documentation page ; Raw orchestrator agent file

sources

• [x] Anvil project site
• [x] Multi-agent orchestration gist (overview page)
• [x] Raw orchestrator agent file
• [x] Raw planner agent file
• [x] Raw coder agent file
• [x] Raw designer agent file
• [x] Max project site
• [x] Max documentation page
• [x] Max README
• [x] GitHub Copilot SDK getting started
• [x] GitHub Copilot Chat in GitHub
• [x] GitHub Copilot Chat in GitHub Mobile
• [x] GitHub Copilot coding agent create a pull request (PR)
• [x] GitHub Copilot custom instructions on GitHub
• [x] GitHub Copilot custom agents
• [x] GitHub Copilot skills
• [x] skills.sh docs
• [x] Vercel guide to agent skills
• [x] Repo instructions URL
• [x] Prior completed research
• [x] Prior completed research
• [x] Prior completed research
• [x] Prior completed research
• [x] Prior completed research