E3d Pilot

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/ 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). When every slot is busy a call waits its turn, first in and first out, for up to E3D_MCP_QUEUE_WAIT_SEC (90); e3d_debate_start queues without holding the call.
• 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.

| E3D_DEBATE_SEARCH_MAX_PER_CALL | 3 (1-10) | Search cap per model call. It is native for Anthropic a