Multi-Agent Coding Scaffold

Production‑ready workflow controls for multi‑agent coding — turns memetic drift risk into concrete evidence pipelines.

Why This Exists

When multiple LLM coding agents collaborate, they can converge on wrong answers because early sampled outputs become evidence for later agents — a failure mode Tanaka calls memetic drift. Agreement among agents is not proof. It can mean they copied each other's framing rather than independently verified the facts.

This scaffold treats multi-agent coding as an evidence pipeline rather than a conversation:

• Separation of concerns — explorers, implementers, verifiers, and integrators are distinct roles with bounded context.
• Claim provenance — material claims must point to code, tests, logs, or runtime observations, not to other agents.
• Artifact-first verification — verifiers inspect diffs and tests before reading the implementer's rationale.
• Risk-adaptive routing — controls scale with risk level; trivial changes use a fast path, high-risk work uses strict isolation.

The result is a repeatable, reviewable process that resists groupthink and produces durable records that humans can audit.

What This Provides

• Role prompts — independent exploration, bounded implementation, artifact-grounded verification, and conflict-aware integration.
• Task & report templates — force claims to cite code, tests, commands, or runtime evidence.
• Governance policies — context sharing, claim provenance, write ownership, and verification gates.
• Risk model — maps failure modes to required controls by risk level (low / medium / high).
• Validation script — checks the scaffold is complete after edits.

Quick Start

# 1. Copy into your coding repository
cp -r multi-agent-coding-scaffold/* your-repo/
cd your-repo

# 2. Configure agent instructions for your project
cp AGENTS.example.md AGENTS.md
# Edit AGENTS.md: project context, languages, build commands, high-risk areas

# 3. Start a task
cp templates/task-brief.md tasks/my-first-task.md
# Fill in problem, acceptance criteria, risk level, write ownership

# 4. Run agents using the prompts in prompts/
#    Explorer → Implementer → Verifier → Integrator
#    (in that order, with context isolation)

# 5. Gate before merging
#    Use templates/verification-gate.md

# 6. Validate the scaffold (after editing it)
pwsh ./scripts/validate-scaffold.ps1

Default Workflow

1. Brief — write acceptance criteria, constraints, allowed write areas, and risk level before agents begin.
2. Explore — run one or more explorers independently (read-only). They inspect code before seeing each other's hypotheses.
3. Compare evidence — compare cited artifacts, not vote counts. Preserve unresolved disagreement.
4. Implement — one owner patches a bounded area. Record why if scope must expand.
5. Verify — a separate verifier checks the diff against tests and behavior. For high-risk work, use blind verification (hide the implementer's rationale).
6. Integrate — an integrator resolves conflicts, confirms provenance, and records residual risk.

Directory Layout

multi-agent-coding-scaffold/
  AGENTS.example.md       # Example project‑specific agent instructions
  README.md               # This file
  docs/
    bayesian-orchestration-relevance.md   # [Orchestration paper relevance]
    feedback-pipeline-steelman-rebuttal.md # [Pipeline design deep‑dive]
    operating-model.md                    # [Lifecycle & decision rules]
    risk-model.md                         # [Failure modes, controls by risk]
  policies/
    claim-provenance.md      # Provenance labels for material claims
    context-sharing.md       # When agents may/may not see prior conclusions
    verification-gates.md    # Gate levels by risk, blocking conditions
    write-ownership.md       # Preventing overlapping agent edits
  prompts/
    explorer.md              # Read-only investigation
    implementer.md           # Bounded patch owner
    verifier.md              # Artifact-grounded review
    integrator.md            # Final assembly & release readiness
  templates/
    task-brief.md            # Start here for every task
    agent-report.md          # Evidence table for agent outputs
    handoff.md               # Structured context transfer
    verification-gate.md     # Acceptance criteria & residual risk
    decision-record.md       # Architecture/behavior change history
  scripts/
    validate-scaffold.ps1    # Check scaffold integrity

Drift-Resistant Rules

• Do not use majority agreement as a decision rule.
• Do not ask agents whether they agree with a previous agent.
• Do require file paths, line references, commands, outputs, or runtime observations for material claims.
• Do keep implementation ownership explicit and narrow.
• Do run at least one verifier that evaluates artifacts rather than rationale for high-risk changes.
• Do record residual risk — uncertainty that remains after verification.

Adapting to a Project

Keep the policy files stable and make project-specific changes in AGENTS.md, task briefs, and verification gates. The scaffold intentionally avoids language-specific commands; add local build, test, lint, typecheck, migration, and deployment checks in the target repo's AGENTS.md.

In-Depth Reading

Document	What it covers
docs/risk-model.md	Failure modes, risk levels (low/medium/high), required controls
docs/operating-model.md	Full lifecycle, decision rules, minimum records
docs/feedback-pipeline-steelman-rebuttal.md	Steelman / rebuttal of the pipeline, edge cases, build plan
docs/bayesian-orchestration-relevance.md	How Bayesian decision theory applies to agent orchestration

Related Work

• Tanaka (2024) — "When Is Collective Intelligence a Lottery?" — the memetic drift result that motivates this scaffold's evidence pipeline.
• Papamarkou et al. (2026) — "Position: Agentic AI Orchestration Should Be Bayes-Consistent" — adds a decision-theoretic control layer for routing, stopping, and escalation. Our docs/bayesian-orchestration-relevance.md discusses the fit.

Contributing

Contributions are welcome! Please open an issue first to discuss changes.

• Bug reports and feature requests: open an issue
• Pull requests: see CONTRIBUTING.md
• Before submitting, run pwsh ./scripts/validate-scaffold.ps1 to check scaffold integrity.

License

MIT