Back to examples

Investigate

When the council asks the questions.

Most hard problems are missing a fact, not an opinion. Ask your own AI to investigate with Pilot: the council answers, then asks the few questions whose answers would change that answer. Your AI checks what it can, asks you the rest, and the council goes again.

How it works, from your own AI

  1. Connect Pilot once

    Add Pilot's MCP server to the AI you already use, such as Claude, ChatGPT or GitHub Copilot. Pilot shows up there as a tool called e3d_investigate.

  2. Ask your AI to investigate

    Say what is wrong, in your own words. Your AI hands it to the council: several models from different vendors answer on their own, challenge each other, and come back with a verdict, the dissent, and up to three questions.

  3. Your AI does the legwork

    It answers the questions marked checkable with its own tools (your files, your logs, on-chain data) and cites each source. It brings you only the questions that need you, then sends everything back for the next round, until no question would change the answer.

What you type

Use Pilot to investigate why our agent stalled for three hours last night. Answer what you can check yourself and ask me the rest.

Prefer the website? Press Investigate instead of Ask on the Ask page; the questions appear under the verdict.

Two ways to work with the council from your AI

Both run the same multi-model council. The difference is who comes up with the next question.

e3d_debate: your AI asks the questions

In a normal conversation in Claude, ChatGPT, Codex or Copilot, your AI sends the council one question and reads back the verdict and the dissent. It can then ask you what it needs to know, on its own or because you asked it to, and send a sharper question to the council. Your AI steers; the council gives it several independent opinions.

Best for a single decision, or when you already know what matters.

For example

Ask Pilot whether we should move this service to Postgres. Before you ask, check with me about our traffic and team size.

e3d_investigate: the council asks the questions

The council itself writes the next questions, from the places where the models disagree, and says why each one matters and what each answer would rule out. Your AI answers the checkable ones with sources, brings you the rest, and keeps the case going round by round until nothing left would change the answer.

Best when something is wrong and you don't yet know what to ask.

For example

Use Pilot to investigate why our checkout emails stopped. Answer what you can check yourself and ask me the rest.

Use cases

Every case below is a real run with four models from four vendors. Each shows the problem, what the council asked, and what changed.

Real run

An AI assistant ran up a $1,099 bill

The problem

An AI agent sat for three and a half hours repeating "waiting…" until someone stopped it. Was the software broken, or was it something in how the agent was set up?

The council asked

  1. What exactly were the agent's instructions, and what counted as done?
  2. What was it waiting for, and did that thing ever start?

What changed

The instructions said "watch the test run and report the result." The test run never started, and nothing told the agent that was worth reporting. The agent was not broken. It was obeying.

The value: The fix is one sentence in the instructions, not new software, and the same stall cannot happen again.

Real run

Teaching an AI assistant to get better at its job

The problem

You want an assistant that improves your website's search ranking over time, not one that repeats the same edits forever.

The council asked

  1. Which assistant do you use?
  2. Can you measure whether a change worked?

What changed

Two short answers (Claude, and yes, through Google Search Console) turned general advice into a plan for one site: record every change with its reason, compare changed pages with unchanged ones after two to four weeks, and keep only what keeps working. Round one had one model off topic. Round two had full agreement.

The value: Advice you can act on this week, for your own site, in two rounds.

Real run, 2 rounds

Is this "new" token safe to buy?

The problem

A group chat is pushing a token. Its trading pool's liquidity tokens were just sent to the zero address, and the promoter says that proves it can't be rugged. You are about to put in $500.

The council asked

  1. Does the token you were pitched match VIDYA, the token this pool actually holds? (checkable)

What changed

Round one already said don't: web searches suggested the pool belonged to an old token, not a new one. The AI agent then checked the blockchain itself: the pool holds VIDYA, an old token, and the "zero address" transaction was someone withdrawing about half a percent of the liquidity, not locking it. Round two closed the case with all four models agreeing.

The value: The pitch fell apart on one checkable fact, found by your agent with a source you can open, before any money moved.

Real incident, replayed in 3 rounds

Our email stopped arriving

The problem

Mail to the company never arrives and a password reset never came. The email provider shows no outage and nobody changed anything.

The council asked

  1. Do senders get a bounce, or does mail vanish silently? (for you)
  2. Is your website on the same domain also down? (checkable)
  3. Who manages your DNS, and were there any expiry or billing notices? (for you)

What changed

Round one suspected an expired domain. The answers (no bounces, website up, and mail now forwarded to an address nobody recognises) moved round two to "treat it as a break-in". Round three read the account's audit log: two days of changes from unknown servers, including rehearsals of the takeover. The plan became: revoke every key from a clean device, keep the logs, restore the records and a security setting the attacker had quietly weakened, then secure every account that uses this email for resets.

The value: You stop the attacker before you fix the symptom, and you find the second change you didn't know to look for.

Real run, 2 rounds

Should we launch our new feature this week?

The problem

A new feature works on the test site and early users like it, but two cost alerts fired and one run was charged less than it cost.

The council asked

  1. Was the under-charge a pricing bug or an intentional discount? (for you)
  2. Can you cap spend per customer and switch the feature off instantly? (checkable)
  3. Do both alerts trace to one cause in your logs? (checkable)

What changed

The answers showed the under-charge was fixed and one alert was a known vendor quirk, but the other was still unexplained. The council's point: spending caps limit what customers pay, not what the vendors bill you. The verdict became a small pilot with a loss budget, and expand once that overrun is explained. This was our own decision about the feature on this page.

The value: A clear go or no-go with the one open risk named, instead of a gut call.

Good to know

  1. Every round is a debate

    Each round is priced like any debate and shows its estimate before it runs.

  2. Answers are data

    Your answers and any sources go to the models as information to weigh, never as instructions.

  3. Your AI shows its work

    Pilot tells your AI to answer only what it actually checked, to say where it looked, and to leave the rest to you. Each answer arrives labelled with who gave it and its source, so you can check it.

See all examples

Bring a problem that is missing a fact.

Investigate works best when the answer depends on something only you, or your agent, can find out.

Request early access