Parallax — multi-agent research

Given a topic, parallax assembles a team of analyst agents, each with a distinct identity and research mission:

1. Recruits a tailored roster of analyst agents for the topic.
2. Lets the user approve the roster, or edit it by saying things like "add X" or "remove Y".
3. Deploys each agent to research the topic from its own viewpoint, staying in role — drawing on available skills, MCP tools, and conversation context before falling back to web search.
4. Synthesizes agent reports into one structured markdown document: convergent findings, comparison table (when it fits), agreements, disagreements, open questions, and per-agent deep-dives.

All state lives in the conversation. There is no file saved between turns — the "current roster" is whatever agent list was most recently shown in the chat.

Requires at least one research tool. Web search is the default, but agents will also use available skills, MCP servers, and conversation context. If no research tools at all are available, tell the user and stop — don't attempt to run research from memory.

Commands

After the roster is shown (Step 3), also accept natural add/remove instructions like add Economist, add Economist and Trade Unionist, remove 2, drop 2,5, remove the regulator one. The goal is low-friction editing.

Workflow

Step 1 — Classify the invocation

Look at the user's message and decide which of these it is:

• New topic. A string that reads as a fresh topic (or /parallax "<topic>"). Go to Step 2.
• Edit command. After Step 3 has shown a roster: any message that adds or removes agents (e.g. "add X", "remove 2", "drop the regulator one"). Go to Step 3 directly, mutating the roster already in context.
• Approval signal. ok, go, proceed, yes, etc. Go to Step 3.5 (deployment mode selection).
• Mode + approval. run sequentially or run in parallel. Approve the roster and go directly to Step 4 in the chosen mode, skipping Step 3.5.

If an edit command arrives but there is no in-progress roster visible in the conversation, say so and ask the user to start a run with /parallax "<topic>". Do not fabricate a roster.

Step 2 — Recruit analyst agents

Assemble a roster of 4–10 analyst agents for the topic.

• Adaptive count. Narrow factual questions deserve ~4 agents. Broad debates ("was Brexit a success", "is nuclear power good or bad") can warrant the full 10. Note that 8+ agents at 5 searches each is ~40–50 web operations — prefer the lean default (3 searches) for large rosters, and avoid exceeding 8 agents unless the topic genuinely demands it.
• Each agent is a real role or stakeholder with an actual opinion and agenda — e.g. "Short-seller", "EU regulator", "Open-source maintainer", "Leave-voting small business owner". Not abstract framings like "Pessimistic view" or "Long-term perspective".
• Diverse in kind. Don't just vary optimism/pessimism. Mix insider vs. outsider, regulator vs. industry, winner vs. loser from the thing, domestic vs. foreign, expert vs. affected layperson.

For each agent, hold onto: short name, one-line role description, one-line rationale for why this agent's viewpoint matters for this topic.

Step 3 — Present the roster and wait

Render the current agent roster as a numbered markdown list:

I propose this analyst team for **<topic>**:

1. **<name>** — <role description>
   *Why:* <rationale>
2. **<name>** — <role description>
   *Why:* <rationale>
...

Reply with one of:
- `ok` to approve (you'll choose deployment mode next)
- `run sequentially` or `run in parallel` to approve and set mode in one step
- `add <name>` to add an agent
- `remove <name or number>` to drop one
- Or combine freely — plain language is fine

Then stop and wait for the user.

When they respond:

• Apply the edits to the roster.
• If they added or removed anything, re-show the updated numbered roster and wait again.
• Loop until the user signals approval.
• If the roster ever becomes empty, refuse approval — tell them the roster is empty and ask them to add at least one agent.

Never skip this confirm loop, even if the roster looks obviously right. The user's edits are the whole point of the flow.

Step 3.5 — Deployment mode selection

When the user approves with ok / go / proceed / yes (without specifying a mode), show this prompt and wait:

Agent roster approved — N analysts ready. How would you like to deploy them?

- **Sequential** — agents deployed one at a time with progress notes as each completes. You can say "more depth" mid-run to increase search depth. Works in all environments.
- **Parallel** — all agents deployed simultaneously as subagents. Much faster, but no mid-run control and all reports arrive at once. Requires Claude Code or Claude Cowork — not available in claude.ai web chat.

Reply `sequential` or `parallel`.

If the user already said run sequentially or run in parallel during the edit loop, skip this step entirely and proceed directly to Step 4 in the chosen mode.

Step 4 — Deploy agents

Once the mode is known, proceed accordingly.

Sequential deployment

Deploy each agent one at a time, in roster order.

Print a brief one-liner and begin immediately — do not wait for a reply:

Deploying N agents sequentially (~3 searches each). Say "more depth" at any point to switch to ~5 per remaining agent.

Default to ~3 searches per agent. If the user says "more depth" mid-run, apply it to all remaining agents.

For each agent:

1. Survey available resources. Before searching the web, check what's already available:
   • Skills: Are any loaded skills relevant to this agent's domain? (e.g. a financial-analysis skill for a short-seller, a legal-research skill for a regulator). If so, invoke them as part of the research plan.
   • MCP tools: Are there MCP servers that provide relevant structured data? (e.g. a stock-data API, a news feed, a company database, a document store). If so, query them before or instead of web search.
   • Conversation context: Has the user shared relevant documents, files, data, or prior research in this conversation? If so, draw on that first. Use whatever combination of sources is available. Web search fills remaining gaps — it is not mandatory if other sources already cover the agent's research needs.
2. Plan 2–3 research angles that this agent would actually pursue given its role and agenda. Stay in role. A short-seller looks for accounting irregularities, insider sales, deteriorating fundamentals — not "Company X overview". A regulator looks for compliance history, enforcement precedents, cross-border jurisdictional questions. Adapt the angles to use the best available source for each.
3. Execute the research plan using the tools identified in step 1. For web search, use whatever tool is available (web_search, search, brave_search, etc.). Fetch the 1–2 most promising results per angle to read full content rather than relying on snippets (web_fetch, fetch, read_url, etc.).
4. Track claim → source pairs as you go. For non-URL sources (MCP data, uploaded files, skills), note the source type and identifier rather than a URL.
5. No padding. If a source returns nothing useful, say so rather than stretching weak results. If the agent genuinely has no relevant findings on this topic, record "no useful findings — agent N/A for this topic" and move on.

A short progress note between agents is fine ("Short-seller done — deploying the regulator"). Do not print interim findings inline; hold everythi