Multi-model analysis of a task or plan

[rodneybotco]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

I want to spar GPT 5.4/5.5/etc vs Opus 4.6/4.7/etc on a task or plan and provide a rich way for me to accept parts of that plan, push back on other parts, remember what I liked about each model's decisions so future plans can benefit from that, etc

Is your feature request related to a problem? Please describe.

The problem is frontier coding models provide insights and bugs that collectively yield a better plan when run by each other

Additional context

Build this but with a richer way to evaluate the plan, accept parts of it, etc https://kau.sh/blog/agent-kombat/

Operating system (OS)

macOS

How important is this feature to you?

5 (Can't work without it!)

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None

[oz-for-oss]

@rodneybotco

You can view the triage session on Warp.

Here's what I found while triaging this issue:

This looks like a broader Agent planning/evaluation feature gap rather than a bug in current /plan behavior. Existing Agent primitives such as /plan, /orchestrate, model/profile selection, and plan opening appear relevant but do not cover the full requested review-and-merge workflow.

Maintainer details

I concluded that feature request for a richer Agent planning workflow that compares multiple frontier models' plans, lets users accept or reject specific parts, and feeds those preferences into future planning..

Triage summary

This is a feature request for a richer Agent planning workflow: run multiple frontier models against the same task or plan, compare their outputs, accept or reject selected pieces, push back on parts of the plan, and carry learned preferences into future planning.

Classification

• Type: enhancement
• Area: Agent workflows and AI-specific UI
• Reproducibility: unknown / not applicable, because this is a requested capability rather than a defect with reproduction steps
• Design needs: likely needs product/design mocks because the requested workflow includes side-by-side evaluation, partial plan acceptance, pushback, and preference memory

Evidence from code inspection

• app/src/search/slash_command_menu/static_commands/commands.rs defines /plan as a planning prompt and /orchestrate as a multi-agent parallel task command.
• app/src/ai/blocklist/controller.rs routes /plan and /orchestrate into distinct UserQueryMode values before sending Agent requests.
• app/src/ai/agent/api/convert_to.rs forwards those modes to the multi-agent API.
• app/src/terminal/input/plans/mod.rs and app/src/terminal/input/plans/view.rs expose an inline plan menu for selecting and opening existing plans.
• app/src/ai/execution_profiles/mod.rs and app/src/ai/execution_profiles/profiles.rs store Agent model and profile configuration, but the inspected paths do not show a first-class comparison/evaluation state for multiple named model outputs or persisted preference feedback.

Likely implementation areas

This likely spans Agent request orchestration, plan artifact/document UX, execution-profile/model selection, and persistence of user feedback/preferences. The closest existing primitives are /plan, /orchestrate, execution profiles, and the inline plan menu, but the requested feature is broader than any one of those existing surfaces.

Duplicate check

No duplicate is being flagged from the provided recent/open issues. #9260 appears adjacent because it mentions Agent Mode harnesses, and #9214 mentions plan content, but the provided summaries do not describe the same multi-model plan-comparison and partial-acceptance workflow, and the duplicate workflow requires at least two likely matches.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[captainsafia]

@rodneybotco Thanks for filing this issue! We think this is a great idea. Curious to hear something from you about the ideal experience for this: would you be interested in having a /plan entrypoint that queries N models and produces N plans or is the idea that you can feed an existing plan to N models for post-review?

Figuring this out, will help us identify what a spec for this would look like. I've marked this as ready-to-spec in case you'd like to open a PR with a product/tech spec for us to start iterating on.