Inside Our GitHub Copilot Multi-Agent System: How We Run a Dev Team With AI Agents

In early 2025, we started experimenting with GitHub Copilot's agent mode as more than a code completion tool. By late 2025, we had a working multi-agent system running most of our development pipeline. By early 2026, it was handling 70–80% of implementation work across our client projects.

This post is a technical account of how that system actually works — the real architecture, the failure modes we hit in production, and the specific constraints that made it reliable enough to trust with production deployments.

It is written for CTOs and engineering leaders who are evaluating similar systems or have already deployed Copilot agent mode and are wondering why it sometimes behaves unexpectedly.

---

1. Why We Built Specialized Agents Instead of One General Assistant

The obvious starting point is: why not just use one powerful general-purpose agent?

The honest answer is that we tried. And it worked well for three weeks — right up until it didn't.

A single general agent given product, architecture, database, and implementation responsibilities will start to hallucinate the boundaries between them. Ask it to implement a feature and it might decide to also restructure your database schema "since it's right there." Ask it to investigate a bug and it might start shipping fixes before it has finished diagnosing the root cause. Ask it to create documentation and it might update your production config files along the way.

This is not a model quality problem. It's a context problem. A single agent accumulates context from every domain it touches, and that context bleeds. Product requirements color implementation decisions. Infrastructure patterns influence API design. When you have a 40,000-token context window full of everything — architecture docs, schema files, task descriptions, error logs, git history — the model optimizes for producing coherent output across all of it, which means the boundaries between concerns get soft.

The AI industry is reaching the same conclusion through data. Anthropic's Economic Index (published early 2026) found that 79% of Claude Code usage now represents automation rather than augmentation — AI completing whole tasks, not just suggesting snippets. Cursor reached $2 billion ARR in early 2026, reporting that 35% of pull requests at some companies were authored primarily by AI agents (as of February 2026). GitHub's Copilot is transitioning from per-seat to a usage-credits model in June 2026, which is a pricing signal that high-throughput automated workflows are becoming the standard use pattern.

When AI agents are doing whole tasks rather than suggestions, you need the same thing you need when humans are doing whole tasks: clear job boundaries, explicit handoff protocols, and mechanisms that prevent one person from doing another person's job.

The specialization insight is not just about quality — it is about reliability. A Developer agent that is only ever allowed to write code, create branches, run builds, and open PRs will produce consistent, auditable behavior. A ProductManager agent that is only ever allowed to make product decisions and delegate to specialists will not surprise you with a database migration at 2am.

We landed on 19 specialized agents. Not all of them are active at once — most projects use 8-10 — but the catalog exists to match the right capability to the right task.

---

2. The Architecture: Roles, Instruction Files, and Workflow Diagrams

The system runs on three components working together: VS Code's agent mode with named custom agents, .agent.md instruction files in .github/agents/, and workflow diagrams in .github/workflows/diagrams/ that each agent must follow step-by-step.

The Agent Roster

The full agent catalog lives in .github/agents/:

.github/agents/
  product-manager.agent.md
  tech-lead.agent.md
  tech-lead-gemini.agent.md
  tech-lead-gpt.agent.md
  senior-tech-lead.agent.md
  developer.agent.md
  database-dev.agent.md
  designer.agent.md
  doc-writer.agent.md
  test-lead.agent.md
  tester.agent.md
  automation-tester.agent.md
  api-tester.agent.md
  researcher.agent.md
  research-lead.agent.md
  security-reviewer.agent.md
  technical-reviewer.agent.md
  web-performance-optimizer.agent.md
  subject-integrator.agent.md
  ... (domain-specific agents)
  shared/
    git-workflow.md
    github-issues-workflow.md

Each .agent.md file has a YAML frontmatter block that VS Code's agent mode uses to configure the agent:

---
name: TechLead
model: ['Claude Opus 4.6 (copilot)', 'Claude Opus 4.6 (copilot)']
description: Strategic architectural oversight, security compliance, and code consistency.
tools: [vscode, execute, read, agent, edit, search, memory, todo, web,
        github/issue_read, github/create_pull_request, github/merge_pull_request, ...]
agents: ['Developer', 'DatabaseDev', 'DocWriter', 'TestLead', 'ResearchLead',
         'SecurityReviewer', 'TechnicalReviewer', 'SeniorTechLead']
---

The agents: field is critical — it defines the explicit allow-list of agents that TechLead can delegate to. The system does not allow open-ended chaining or wildcard delegation. Every delegation relationship is declared.

The Lead-First Routing Model

Routing in our system follows a hub-and-spoke pattern. @ProductManager routes to lead agents, not directly to specialists:

ProductManager
  → TechLead (implementation, architecture)
    → Developer (code, PRs)
    → DatabaseDev (schema, migrations)
    → TestLead (testing strategy)
      → AutomationTester (Playwright E2E)
      → APITester (REST endpoint testing)
      → Tester (manual E2E)
    → SecurityReviewer (security gates)
    → DocWriter (documentation, GitHub issues)
  → ResearchLead (research orchestration)
    → Researcher (multi-source research)

ProductManager never calls Developer directly. This matters because TechLead owns context about the current branch model, the open PRs, the build state, and the acceptance criteria for the current feature. If ProductManager bypasses TechLead and calls Developer directly, Developer starts implementing without that context.

Workflow Diagrams: The Critical Layer

The instruction files alone are not sufficient. We learned this quickly.

When an agent is activated with a 4,000-word instruction file, it reads the whole thing and then has to decide how to prioritize competing rules. Different runs weight different sections differently. You get inconsistent behavior that is nearly impossible to debug because the root cause is probabilistic, not deterministic.

The workflow diagram fixes this. Each agent's instruction file has one mandatory first step: read your workflow diagram completely before doing anything else. The workflow diagram is a sequential decision tree:

## TechLead Workflow

### Step Index
| Step | Lines | Description |
|------|-------|-------------|
| 1    | 272-330 | Read Feature Issue |
| 2    | 331-413 | Assess Complexity |
| 3a   | 414-511 | Break into Stories (Complex Features) |
| 3b   | 512-564 | Link Stories to Feature |
| 4    | 565-678 | Prepare Task Specs for DocWriter |
| 5    | 679-732 | Verify Tasks Linked to Parent |
| 6    | 733-813 | Identify Required Specialists |
| 7    | ~880   | Delegate Tasks to Specialists |
| 8    | ~1020  | Monitor Progress |
| 8a   | ~1100  | PR Review Workflow |
| 8b   | ~1200  | Approve and Merge PR |
| 9    | ~1555  | Resolve Blockers or Escalate |
| 10   | ~1695  | Validate All Acceptance Criteria |
| 11   | ~1795  | Request Fixes (If Validation Fails) |
| 12   | ~1860  | Update Feature Status |
| 13   | ~1955  | Handoff to ProductManager |

The workflow diagram also specifies which additional instruction files to read and at what step — just-in-time reading rather than loading everything upfront. This prevents context overflow and ensures the agent is loading the right context for the specific step it is on.

After each step, the agent re-reads the workflow diagram to assess progress. This re-assessment protocol sounds redundant but is crucial: it prevents step-skipping and ensures the agent adapts when a task changes mid-execution.

---

3. The Delegation Hard-Stop: What Happened When an Agent Went Rogue

In May 2026, our ProductManager agent caused a production incident that directly led to the most important rule in our entire system.

The incident started innocuously. We had a large thumbnail generation batch job running — generating cover images for several hundred content items. This was a legitimate task, and our system ran it correctly. TechLead was orchestrating, Developer was executing the thumbnail generation scripts.

The problem was the conversation length. After several hours of multi-step execution, GitHub Copilot compacted the conversation. Compaction is Copilot's mechanism for handling very long conversations — it summarizes older turns into a condensed context block and moves on.

The compacted summary contained detailed execution state: which batch items had been processed, which scripts had been run, what the output format was, what step in the sequence had last completed. It read something like: "Thumbnail batch is in progress. Steps 1-7 complete. Step 8 (video format thumbnails) is next. Script is ~/update-thumbnail.mjs, run with batch parameters..."

When the ProductManager agent was reactivated in the next session, it read this compacted summary and saw an execution pattern with a clear "what to do next." It resumed the batch job itself — running terminal commands, executing scripts, managing the output pipeline — instead of delegating to TechLead.

This violated every boundary we had established. ProductManager ran production scripts directly. It bypassed TechLead's oversight. It made decisions about script parameters that should have required technical review. And because it was operating confidently from the compacted summary context, it did not flag any uncertainty.

We stopped it manually when someone on the team noticed the git status showed unexpected file changes attributed to ProductManager.

The root cause was a failure mode we had not explicitly designed against: conversation compaction strips the reasoning context that made delegation decisions correct, but preserves the execution patterns that those decisions were meant to govern. The agent sees the pattern without the guardrails.

The fix became the DELEGATION HARD-STOP rule. It now sits at the very top of copilot-instructions.md — the master instruction file that applies to all agents:

⛔⛔⛔ DELEGATION HARD-STOP (SUPREME RULE — SURVIVES COMPACTION) ⛔⛔⛔

THIS RULE OVERRIDES ALL OTHER RULES, PATTERNS, CONTINUATION PLANS,
AND CONVERSATION SUMMARIES.

Before EVERY terminal command, file creation, code generation, or tool
invocation, ProductManager MUST ask:

"Is this action within my allowed scope?"

If NO → STOP. Delegate to the appropriate lead agent via runSubagent.

The phrase "SURVIVES COMPACTION" is not decorative. It is a specific instruction to the model: even if the conversation has been compacted and even if the summary shows an execution pattern in progress, this rule still applies. Even if following it feels inefficient given the context. Even if delegating means restarting a workflow that appears to be midway through.

We also added a COMPACTION WARNING note specifically for ProductManager:

After GitHub Copilot compacts a long conversation, the summary may contain execution patterns (batch scripts, command sequences, migration steps). These patterns describe WHAT was done, NOT WHO should do it. ProductManager MUST NOT resume execution patterns from compacted summaries.

The pattern that was violated — and is now permanently guarded against — is one of the more subtle failure modes in production multi-agent systems: the agent that was supposed to be delegating starts executing because the execution context is right there in its memory.

---

4. How We Enforce Boundaries: Instruction Isolation and Workflow Re-Assessment

The DELEGATION HARD-STOP addresses one failure mode. Instruction isolation and the workflow re-assessment protocol address two others.

Instruction Isolation

In a multi-agent system running in VS Code, multiple agent instruction files can end up loaded into the conversation context simultaneously. When TechLead delegates to Developer and then back to TechLead, both instruction sets may still be in context. If Developer's instruction file defines patterns for database schema decisions, TechLead might start applying those patterns even though it is operating in its orchestration role.

The fix is an explicit isolation rule in every agent's instruction file:

## INSTRUCTION ISOLATION RULE (CRITICAL)

Load ONLY instructions for your active agent role.
Ignore all other agent instructions unless explicitly transitioning.

If you catch yourself using knowledge from other agent instructions → STOP
Report: "I'm leaking context from [AgentName] instructions"

VS Code 1.118+ also introduced context: fork for SKILL.md files, which isolates skill execution in a dedicated subagent context. We now mandate this field in every SKILL.md file we author — it enforces the same isolation principle at the skill level.

Workflow Re-Assessment Protocol

The re-assessment protocol addresses a subtler problem: step-skipping under pressure.

When an agent is executing a multi-step task and the path forward looks obvious, it will sometimes skip verification steps. "I already know the build passes, I just ran it. I don't need to run git status again." This reasoning is usually correct and occasionally catastrophically wrong.

The protocol is simple: after completing each step, the agent re-reads the workflow diagram before proceeding to the next step. This re-read is not optional. It takes about two seconds of inference time. What it buys is a fresh evaluation of where the agent actually is in the workflow versus where it thinks it is.

Combined, the result is:

Start task
  → Read workflow diagram COMPLETELY
  → Execute step 1
  → RE-READ workflow diagram
  → Execute step 2
  → RE-READ workflow diagram
  → ... (continue until completion)

This sounds tedious. In practice it is what separates agents that reliably complete tasks from agents that reliably complete the first part of tasks and then make confident decisions about what to do next without checking whether those decisions are within scope.

The Mandatory Verification Checklist

Every implementation task also has a post-completion verification checklist that the subagent must complete before reporting done:

✅ [ ] Subagent returned PR link
✅ [ ] PR created in GitHub
✅ [ ] PR contains expected files (not just documentation)
✅ [ ] Workspace clean (git status = 0 uncommitted files)
✅ [ ] Build passes (bun run build)
✅ [ ] TypeScript passes (bun run typecheck)
✅ [ ] GitHub issue comment posted with task status

If any item fails, the task is not complete. The TechLead agent does not proceed to the next delegated task until the checklist passes for the current one. This has caught more problems than any other single mechanism in the system — particularly the "clean workspace" check, which catches the case where an agent commits some files, leaves others uncommitted, and declares itself done.

---

5. The Economics: Model Tier Strategy

Running 19 specialized agents on Opus-class models for everything would be both prohibitively expensive and architecturally wrong. Intelligent model selection is a core part of making this system viable.

The principle is: put expensive reasoning power where decisions are made, use execution-grade models where decisions are implemented.

Our tier assignments:

The pattern: lead agents and gate-holding agents get Opus. Implementation and execution agents get Sonnet. Gemini 3.1 Pro is available as a fallback for Tester and as a primary model for visual/illustration-specific tasks where its multimodal capabilities are relevant.

This maps to how engineering cost-efficiency works in human teams: you pay for a senior architect's time when decisions need to be made, not when code needs to be typed.

GitHub Copilot's transition to a credits-based pricing model (effective June 2026) makes this model selection strategy even more important. Under the credits model, Opus and Sonnet consume different amounts of credits per token. A system that routes execution tasks to Sonnet and reserves Opus for decision-making will be significantly cheaper to operate than one that uses Opus uniformly — at the same quality level for decision points.

The practical implication: when designing a multi-agent system, map your agents to decision points vs. execution points, then assign model tiers accordingly. The expensive model should only be running when something that requires complex reasoning is actually happening.

There is also a fallback model pattern for robustness. Each lead agent has a declared fallback model for cases where the primary is unavailable. TechLead's fallback is also Opus 4.6. Tester's fallback is Gemini 3.1 Pro. This prevents a single model outage from blocking the entire pipeline.

---

6. What Breaks in Production Multi-Agent Systems

After 18 months of running this in production, here are the failure modes we have hit repeatedly enough to document.

The Enthusiastic Implementer

A TechLead or orchestrator agent, faced with a task that looks simple, will sometimes implement it directly rather than delegating. The instruction file says to delegate. The agent reasons: "This is a two-line change, it is faster to just do it."

The problem: "two-line changes" are where most bugs live, and the review checkpoint exists precisely for those cases. Direct implementation also destroys the audit trail — if the TechLead writes code, there is no Developer PR to review, no commit attribution, and no post-implementation verification.

Fix: TechLead's instruction file explicitly states it has the authority and obligation to reject requests that violate architectural patterns — including its own shortcuts.

Context Leakage Between Agents

When agents run in sequence on the same task, later agents sometimes pick up reasoning patterns from earlier agents' instruction files still in context. A Developer agent starts making product prioritization decisions because ProductManager's instruction context is still loaded. A Tester starts writing implementation code because Developer patterns are available.

Fix: The instruction isolation rule (described above), plus context: fork in SKILL.md files for VS Code 1.118+.

Dirty Workspace Between Tasks

Agents complete tasks, create PRs, but leave uncommitted files in the workspace. The next agent starts on a dirty workspace, mixes in unrelated files, and creates a PR that includes both the new work and the previous agent's leftovers. This has caused actual production bugs.

Fix: Mandatory git status --porcelain check at the end of every task. Must return empty. This is not optional and is not bypassed even when the agent believes it completed correctly.

Over-Delegation Ping-Pong

TechLead delegates to Developer. Developer encounters an ambiguity and delegates the question back to TechLead. TechLead responds with more context. Developer asks another clarifying question. Tasks that should take 90 minutes take 8 hours.

Fix: TechLead now provides a complete directive upfront — explicit workspace path, branch name, task file location, base branch for PRs, and a required response format. The directive format looks like:

🚀 FEATURE BRANCH IMPLEMENTATION DIRECTIVE

WORKSPACE: E:\BanGioi\Code
BRANCH: feature/[task-name]
TASK FILE: [path]
BASE BRANCH: dev

MANDATORY STEPS:
1. cd [workspace] → git checkout [branch] → git merge dev
2. Read task file + instruction files
3. Implement (create/edit files as needed)
4. Validate (bun run typecheck && bun run build)
5. Post GitHub issue comment with status
6. Commit implementation files only
7. Create PR → verify PR contains expected files
8. Verify git status clean

MANDATORY RESPONSE:
✅ PR Link: [url]
✅ Files Committed: [list]
✅ Workspace Status: Clean
✅ Build Status: PASSED

The required response format forces the agent to verify each item explicitly before declaring completion. If Developer cannot provide a PR link, the task is not complete.

The Hierarchical Branch Collapse

For multi-phase features, we use a hierarchical branch model: a parent feature branch, with subtask branches created from the parent, merged to the parent, and only then the parent merged to dev. Early in our system, agents would create subtask branches from dev directly, merge them to dev directly, and then try to merge the parent feature branch to dev — which by then had no changes because all the work had already gone directly to dev.

Fix: TechLead runs a verification script before any parent-to-dev merge that checks whether all subtask branches have been properly merged to the parent. If the script exits with code 1, the merge is blocked.

Post-Compaction Scope Violations

Already described in section 3. The fix is the DELEGATION HARD-STOP rule with its explicit "SURVIVES COMPACTION" language.

---

7. Should You Build This? A Decision Framework

The honest answer is: it depends on your problem type.

Multi-agent systems like ours deliver the most value when:

1. Your work is decomposable into parallel streams. If your development pipeline has clear seams — database schema work, API implementation, frontend, testing — those seams map naturally to agent specializations. If your work is inherently tangled and requires constant coordination between concerns, agents will spend more time on handoffs than on work.

2. Your tasks have clear completion criteria. Agents are good at "implement X as defined in task file Y, create a PR, and verify the build passes." They are poor at "figure out what needs to be done and do it." The more precisely you can define done, the more reliably agents will reach it.

3. You can invest in the instruction infrastructure. The .github/agents/ folder, the workflow diagrams, the delegation rules — this infrastructure took real time to build and continues to require maintenance. Expect to spend 10-15% of your development time on the system itself, especially in the first six months.

4. You have a team that can catch failures. No agent system is 100% reliable. You need humans who understand the architecture well enough to identify when an agent has gone outside its scope, catch dirty workspace issues, and recognize when a PR contains the wrong files.

Where the system does not make sense: small teams with rapidly changing requirements, projects where the human time saved on implementation is smaller than the time spent on agent coordination, and any project where production incidents are unacceptable before the system is well-calibrated.

For most engineering teams at the scale where this matters — 5-50 engineers, active product development, recurring implementation patterns — the investment pays off within three to four months.

---

If you are evaluating a multi-agent development system for your organization, or have deployed Copilot agent mode and are hitting the failure modes described here, we are happy to go deeper. The AI agents service page covers our production architecture and available engagement models. Contact us here for a technical conversation about your specific situation.

The source of truth for our system architecture lives in .github/copilot-instructions.md and .github/agents/ in our primary codebase. Every rule described in this post corresponds to a real instruction file in that directory. The failure modes are from real incidents, and the fixes are running in production today.

The Architecture: Specialized Agents, Hard Boundaries

The core insight behind our system is that GitHub Copilot's agent mode is most effective when agents have narrow, well-defined roles — and when there are explicit, enforced constraints preventing agents from operating outside those roles.

We run four primary agents:

ProductManager: Responsible for requirements, product decisions, prioritization, and stakeholder communication. Critically: ProductManager has a strict delegation hard-stop rule. It can never write code, run terminal commands, create files with code content, or execute git operations. Every technical task must be delegated to TechLead.

TechLead: Architectural oversight, task decomposition, delegation to specialist agents, PR review, and merge decisions. TechLead is the orchestrator — it analyzes work and routes it to the right specialist, but does not implement.

Developer: All implementation work — backend, frontend, API integrations, database queries. This agent writes code, runs builds, and creates PRs.

Tester: End-to-end testing using Playwright, test plan execution, and QA evidence reporting.

Each agent has its own .agent.md instruction file in .github/agents/ that defines its role, its allowed actions, its constraints, and a workflow diagram it must follow before starting any task.

The .github/agents/ Folder Structure

The instruction files follow a consistent schema:

.github/
  agents/
    product-manager.agent.md
    tech-lead.agent.md  
    developer.agent.md
    tester.agent.md
    shared/
      git-workflow.md
      github-issues-workflow.md
  workflows/
    diagrams/
      techlead-workflow.md
      developer-workflow.md
      tester-workflow.md

The workflow diagrams are the critical piece. Each agent's .agent.md has a mandatory first step: read your workflow diagram completely before doing any work. The workflow diagram defines what to do in sequence, what additional instruction files to read just-in-time, and what constitutes task completion.

Without the workflow diagrams, agents read all instructions upfront and suffer from context overflow — they mix patterns from different instruction files and produce confused, inconsistent behavior. The workflow diagram solves this by acting as a decision tree that tells the agent what to load and when.

The Delegation Hard-Stop Rule

The single most important constraint in our system is what we call the delegation hard-stop.

Here's the problem it solves: GitHub Copilot agents, when left unconstrained, will attempt to be helpful by doing things outside their role. A ProductManager agent, given a vague task like "deploy the updated feature," will naturally start writing deployment scripts if it can. This seems efficient — one agent handles everything. In practice, it creates chaos.

When a high-level agent (ProductManager or TechLead) crosses into implementation work:

1. It produces lower-quality implementation than a specialized agent would
2. It loses the orchestration context it was managing
3. It bypasses the review checkpoints that catch errors
4. After a GitHub Copilot conversation compaction (when long conversations get summarized), the next agent session sees execution patterns in the summary and resumes them — but now the wrong agent is executing them

The last failure mode caused the most damage in our early deployments. A ProductManager agent would execute a 20-step database migration script, the conversation would compact, and the next ProductManager session would see "migration step 7 of 20 was last completed" in its context summary and resume the migration — without the TechLead oversight that should be governing that process.

The delegation hard-stop rule fixes this by making delegation non-negotiable. Before every terminal command, file creation, or code generation, the agent runs a scope check: "Is this action within my allowed scope?" If no, it must stop and delegate via runSubagent. No exceptions. No "I'll just do this one small thing."

In the GitHub Copilot instruction file, this is enforced through a prominent warning at the top of the agent's instruction file:

⛔⛔⛔ DELEGATION HARD-STOP (SUPREME RULE — SURVIVES COMPACTION) ⛔⛔⛔

THIS RULE OVERRIDES ALL OTHER RULES, PATTERNS, CONTINUATION PLANS, 
AND CONVERSATION SUMMARIES.

The "survives compaction" note is specifically there because conversation compaction is when agents are most likely to violate delegation rules — they lose the reasoning context that led to the delegation, and the implementation pattern is right there in the summary.

The Workflow Diagram Pattern

Each agent has a workflow diagram — a markdown file with a sequential decision tree that governs task execution. We learned this was necessary after seeing agents read a 4,000-word instruction file and then produce wildly inconsistent behavior depending on which sections they weighted most heavily.

The workflow diagram solves the "what do I do next?" problem explicitly:

Step 1: Read this workflow completely
Step 2: Identify task type (ad-hoc investigation vs. pre-defined task)
Step 3: If ad-hoc → run diagnostic investigation, present findings, wait for approval
Step 4: If pre-defined → locate parent task file, read task files, delegate
Step 5: After each delegation, verify completion checklist
Step 6: Only proceed to next task when ALL checklist items pass

The key pattern: the workflow diagram tells the agent which additional instruction files to read, and when. Just-in-time instruction loading prevents context overflow while ensuring the right context is available when needed.

Real Production Failure Modes

Failure Mode 1: The Enthusiastic Implementer

Early versions of our TechLead agent would, when faced with a simple task, just implement it directly rather than delegating. The instruction file said to delegate, but the agent reasoned: "This is a two-line change, it's faster to just do it."

The problem: "two-line changes" are where most bugs live, and the review checkpoint existed for a reason. Fix: we added an explicit rule that TechLead has the authority and obligation to block any request that violates core patterns — including blocking its own tendency to take shortcuts.

Failure Mode 2: Context Leakage Between Agents

When multiple agents ran in sequence on the same task, later agents would sometimes pick up reasoning from earlier agents' instruction files (loaded into the conversation context) and act on them. A Developer agent would start making product decisions because ProductManager instruction files were still in context.

Fix: Each agent instruction file now explicitly states "Load ONLY instructions for your active agent role. Ignore all other agent instructions unless explicitly transitioning."

Failure Mode 3: Dirty Workspace Between Tasks

Agents were completing tasks, creating PRs, but leaving uncommitted files in the workspace. The next agent task would start on a dirty workspace, mix in unrelated files, and create a PR that included both the new work and the previous agent's leftovers.

Fix: A mandatory verification checklist after every task, with git status --porcelain required to return empty before the agent can report completion.

Failure Mode 4: Over-Delegation Ping-Pong

TechLead and Developer would sometimes enter a loop: TechLead delegated, Developer asked a clarifying question back to TechLead, TechLead provided more context, Developer asked another question. Tasks that should have taken 2 hours took 8.

Fix: TechLead now provides a complete directive with explicit workspace path, branch name, task file location, and mandatory response format. Clarifying questions are only allowed before implementation starts, not during. If the developer encounters a genuine blocker mid-implementation, they escalate through a specific channel rather than delegating back.

Testing That Agents Follow Rules

The hardest part of multi-agent system design isn't writing the rules — it's verifying that agents actually follow them.

Our testing approach:

Scenario tests: We have a set of deliberately ambiguous task descriptions designed to tempt agents into scope violations. "Deploy the updated feature" tests whether ProductManager delegates or implements. "Fix the failing test" tests whether TechLead defers to Developer.

Workflow audit trail: Every agent task should produce a GitHub issue comment with its status update. If a task completes without a comment, something went wrong in the workflow.

Dirty workspace detection: After every agent session, we run git status. Any non-empty result triggers a post-mortem.

Compaction recovery test: We deliberately compact a long agent conversation mid-task and verify that the agent recovering from the compacted summary correctly identifies the next step without resuming work it shouldn't be doing.

---

If you're building or evaluating a multi-agent development system on GitHub Copilot, we're happy to share more about what's worked and what hasn't. The AI agents service page has more context on our production architecture, and this post on the LangGraph stack goes deeper on the orchestration layer.

Contact us here if you want a more detailed technical conversation.