E3D Pilot

Multi-model AI problem solving: independent answers → critique → convergence → human decision → execution → review → provenance.

e3d-pilot is an open-source system for getting multiple AI models to work on the same problem instead of trusting a single model's answer — from a one-off question to a fully executed, human-gated software change.

It starts simply. Ask several configured models (Claude, Codex, Grok, Devin, or others you wire in) the same question. Let them answer independently, see and critique each other's positions, revise, expose real dissent, and converge on the strongest answer. That's bin/e3d-debate — a standalone tool, no repo or pipeline required. It's also available inside your editor as an MCP server: use it from GitHub Copilot, Claude Code, or Cursor with one npx line.

Then e3d-pilot takes the same instinct further, into real software work: discover → ideate → approve → draft → negotiate → execute → review → publish → outcome. Every step is preserved in an append-only ledger, so the system (or a human, or a fresh AI session) can later reconstruct where an idea came from, which models or people influenced it, what it produced, and what happened afterward.

Try e3d-debate in 60 seconds

git clone https://github.com/spacepacket1/e3d-pilot.git
cd e3d-pilot

bin/e3d-debate \
  "Should e3d-pilot's provenance data be a graph, or is that over-engineering?" \
  --providers claude,codex --rounds 3

(Any lib/providers/<name> adapter can join — add devin/grok-build/others if you have them configured; claude/codex are the two most people trying this will already have.)

Round 1: every provider answers independently. Round 2+: each sees the others' prior-round positions and must defend, revise, rebut, or concede. The debate stops early if they genuinely converge; a synthesizer then reads the full transcript and reports a final answer, consensus, and any remaining dissent.

That question isn't hypothetical — it's a real debate we ran this way, condensed from the full transcript:

QUESTION
Should the E3D 3D graph generalize into a standalone product, or should
e3d-pilot instrument its own provenance instead?

CLAUDE (round 3, the only one to formally reach "approved")
Don't create e3d-graph yet — build a confidence-annotated, domain-neutral
provenance emitter inside e3d-pilot, prove attribution questions are
answerable from the data alone, add a 2D lens only if they are, and extract
a public repo only on external pull or paid demand.

CODEX (round 3)
Build outcome-linked Pilot provenance first, then open-source a narrow
standalone viewer only if measured workflow value and external pull
justify extraction.

DEVIN (round 3)
Instrument Pilot with a domain-neutral provenance schema from day one; gate
public extraction on the internal experiment succeeding, not on indefinite
deferral.

GROK-BUILD (round 3)
Do not ship standalone e3d-graph; instrument Pilot provenance first and
treat visualization as a 2D lens inside E3D.

SYNTHESIS
Do not ship a standalone e3d-graph product. Instrument e3d-pilot now with
an append-only, domain-neutral, confidence-annotated provenance schema —
the ledger stays canonical, the graph is an index, not memory. Validate by
answering real attribution questions from the data alone before any UI.

DISSENT (reported, not hidden)
Devin and partly Codex would gate public extraction on the internal
experiment succeeding; Claude and Grok-build require external pull or paid
demand instead — a real, named disagreement the tool didn't paper over.

What happened next: we built exactly that, then ran it against three real ideas in this repo's own history. All three came back "more useful than reading the raw ledger by hand" — and one of them caught a real error in the spec that proposed it. Later graph-intelligence queries were evaluated just as honestly: one clear win, two explicitly "no signal" because the real data was still too sparse — reported as-is, not oversold. That full arc (spec, dogfood results, the honest misses) is in docs/provenance-graph-experiment.md and docs/graph-intelligence-experiment.md.

Experimental: the provenance graph. e3d-pilot now derives structural relationships — ideas, actors, models, decisions, repos, commits, evidence, outcomes — from its own immutable event ledger. We're testing whether that graph reveals patterns that are genuinely hard to get from the raw ledger, not claiming it already does.

You don't need the rest of e3d-pilot to use e3d-debate on its own — see e3d-debate below for the full flag reference. Keep reading for the part that takes a debate's answer all the way to a shipped, reviewed, provenance-tracked change.

Use e3d-pilot from GitHub Copilot, Claude Code, and Cursor (MCP)

e3d-mcp is a zero-dependency Model Context Protocol server. It lets an AI coding assistant ask for a multi-model second opinion mid-task, instead of committing to the first answer one model gives it. It's published on npm as e3d-pilot and listed in the official MCP registry as io.github.spacepacket1/e3d-pilot.

A real result in quick mode (11 seconds, two models), from asking whether a small CLI should default to a flat JSON file or SQLite:

FINAL ANSWER: Default to a flat JSON file for a small CLI. It has no dependencies, is
human-readable and diffable, and is easy to hand-edit and debug. Write it atomically
(temp file, then rename). Move to SQLite once you need indexed queries, concurrent
writers, or data beyond a few MB.
CONSENSUS: split
DISSENT: Codex prefers SQLite as the default for any persistent mutable state because
it gives transactions, concurrency safety, and schema evolution at low cost.

The disagreement is the point: you get the answer and the strongest case against it, instead of one model's confident guess.

Install

VS Code (GitHub Copilot agent mode): one-click install, or add this to .vscode/mcp.json:

{
  "servers": {
    "e3d-pilot": { "type": "stdio", "command": "npx", "args": ["-y", "--no-update-notifier", "-p", "e3d-pilot", "e3d-mcp"] }
  }
}

Claude Code:

claude mcp add e3d-pilot -- npx -y --no-update-notifier -p e3d-pilot e3d-mcp

Cursor (~/.cursor/mcp.json) and other clients that use the mcpServers shape:

{ "mcpServers": { "e3d-pilot": { "command": "npx", "args": ["-y", "--no-update-notifier", "-p", "e3d-pilot", "e3d-mcp"] } } }

Any MCP client that can launch a stdio server should work; the shapes above are each client's standard format.

Prerequisites: Node 18+, jq, bash 4+ (macOS ships 3.2: brew install bash jq), and at least two model CLIs logged in (e.g. claude and codex). Check them all at once:

npx -y -p e3d-pilot e3d-mcp --doctor

--doctor reports what's missing and how to fix it. It does not need the full pipeline's e3d-code executor (it only notes whether that is installed). From a clone, bin/e3d-mcp --print-config --local prints a config that points at your checkout.

Using it

In Copilot agent mode (or any client), ask: "Before you pick a storage layer, run e3d_debate on SQLite vs flat JSON for this CLI." To make the assistant do this unprompted for contestable design choices, copy examples/copilot-instructions.md into .github/copilot-instructions.md or AGENTS.md. Don't use it for lookups or questions with an obvious answer; it is slow and costs money.

Cost and limits

• quick debates take seconds to a minute and thorough ones a few minutes; both spend your model credits. The server caps e3d_debate with E3D_MCP_MAX_ROUNDS (3), E3D_MCP_MAX_PROVIDERS (4), E3D_MCP_MAX_CONCURRENT (2), and E3D_MCP_TIMEOUT_SEC (900).
• It uses whatever provider CLIs and keys are in the server's environment (see e3d-pilot providers list).
• The Copilot coding agent runs on GitHub-hosted runners, where those provider CLIs aren't installed. Use the local (stdio) setup above for now.

Web search in debates

Every debate prompt states today's UTC date. The API providers (anthropic-api, openai-api, gemini-api, xai-api) can also use their vendor's own web search tool in the debate rounds. It is on by default, and the question text may then be sent to a search provider. CLI voices, MCP-sampling voices and the synthesizer never search; they are told they have no web access. Pass web_search: false to e3d_debate or e3d_debate_start, or --web-search off to e3d-debate, to turn it off for one debate. Search results are treated as untrusted data: see docs/web-search-providers.md for what each vendor allows and what risk remains, and docs/web-search-interface.md for the result shapes.

If a search call fails, times out, uses a tool other than search, or the vendor has search disabled, that model is asked again without search, and the answer says so ("web search was unavailable ..."). The answer also reports how many models could search ("on for N of M models").

• e3d_debate and the read-only tools never write to a repo. The pipeline tools below do, only through the same gated CLI paths as a person would, and e3d_pilot_propose writes to the repo's .e3d-pilot/ ledger.

Run the pipeline from your editor

Status (0.2.0): the pipeline tools and the sampling default are new. They are tested with scripted MCP clients and fake providers, not yet verified inside a real VS Code Copilot session. Approving from the editor is off unless you set E3D_MCP_ALLOW_APPROVAL=1, and the pipeline tools only touch repositories you allow.

Besides debates, e3d-mcp can drive the human-gated pipeline, so an assistant can go from a decision to a draft PR without leaving the editor. The tools call the same CLI code paths a person would; they never reimplement a stage or weaken a gate.

A worked flow from Copilot agent mode

1. "We need local persistence. Run e3d_debate on JSON vs SQLite." The verdict comes back with its dissent.
2. "Propose that as an idea, with the debate as evidence." e3d_pilot_propose records it as proposed.
3. (optional) e3d_pilot_start with discover then ideate to have the pipeline find ideas for the repo itself.
4. You approve it (see below). Nothing is drafted or written before this.
5. "Implement it." e3d_pilot_implement drafts and negotiates a phased spec, then pauses. Poll e3d_pilot_job_status.
6. "Show me the plan." e3d_pilot_code_plan lists each phase with its model, the files it touches, and the verify commands.
7. If it looks right: e3d_pilot_execute. If not: e3d_pilot_cancel_paused. Execution ends with a draft PR for a person to review.
8. Merging is not available over MCP. approve-merge and merge stay CLI-only on purpose, so the last gate is always a person at a terminal (or the web UI).

Trust model

• Gate 1 is a person's decision. e3d_pilot_approve does not approve by default. If the server operator sets E3D_MCP_ALLOW_APPROVAL=1 and the editor supports MCP elicitation, it asks the person in the editor's own prompt; an agent cannot answer that prompt for them. Without both, it returns the command to run (e3d-pilot ideas approve ...) or you can use the web dashboard.
• confirm_phrase alone would only prevent accidents (an agent can read it from an error message), which is why it is not the approval mechanism. reject and request_changes accept it because they only stop work.
• The CLI enforces approval itself. Every mutating stage checks a digest-bound approval inside the stage, so no tool here can skip it.
• Repo allowlist. Pipeline tools only operate on E3D_MCP_REPOS (a :-separated list), the client's workspace folders, or, if neither exists, the git repository the server was started in. Paths are resolved through symlinks, must be a git repository's top level, and anything outside is rejected. (The four original tools predate this and are unchanged.)
• Code is written in a separate worktree on a per-run branch, under the existing protected_paths, max_diff_files/max_diff_lines ceilings and verify-before-publish rules. Your working tree is untouched.
• Logs, artifacts and errors pass through secret redaction.

Cost model

• Tools say in their descriptions whether they are FREE or SPEND MODEL CREDITS. code_plan uses e3d-code --list and --preflight only, which write nothing (--dry-run is deliberately avoided because it records a "completed" phase in the manifest).
• Caps: one job per repo at a time, E3D_MCP_MAX_JOBS (2) across repos, E3D_MCP_JOB_TIMEOUT_SEC (3600), E3D_MCP_MAX_PHASES (8), plan tokens expire after E3D_MCP_PLAN_TTL_SEC (1800) and are void if the spec or the repo's HEAD changes.
• There is still no per-day or per-session spend cap and no cost reporting. Treat the caps above as guardrails, not a budget.

Copilot's own models by default

When the client supports MCP sampling (VS Code does, per its docs), e3d_debate uses the client's own models (Copilot) as one or two of its voices and adds any model CLIs it detects on the machine (claude, codex, gemini, ...), instead of requiring two CLIs. The first request prompts you to authorize the server to use your models; you can restrict which in MCP: List Servers > Configure Model Access. Results report which models actually answered and warn when every voice resolved to the same model (that is one model arguing with itself, not a debate). Without sampling, the default is the original claude + codex. Pin it with E3D_MCP_PROVIDERS=claude,codex, or cap it with E3D_MCP_AUTO_VOICES. Sampling spends your Copilot usage.

Sampling can only answer text-in, text-out prompts, so it works