The Multi-Model Workflow

The insight behind the framework

Most teams use AI the same way they use a search engine: one query, one answer, one output. This works well for simple lookups.

For complex work — where the problem space is uncertain, the stakes are real, and errors compound — this approach underuses what AI systems can actually do.

The multi-model workflow is built on a different insight:

Different AI models, given different roles and constraints, produce qualitatively different outputs. Combining them in a structured sequence produces results that no single model would generate alone.

This is not about using more models for the sake of it. It is about assigning each model to the cognitive task it performs best, and structuring handoffs so that the output of each stage strengthens the next.

The three cognitive roles

Every complex task involves at least three distinct cognitive modes. The multi-model workflow assigns each to a different model or session.

Divergent thinking

What it looks like: Generating options, challenging assumptions, surfacing alternatives, asking what has been overlooked.

What suppresses it: Anchoring on existing patterns, sycophancy toward the user's framing, prior context that primes convergence.

How to enable it: Use a model with no prior context on the specific task. Ask open-ended questions. Explicitly prohibit it from proposing solutions — just analysis and challenge.

Convergent thinking

What it looks like: Translating ideas into plans, grounding abstract concepts in concrete constraints, identifying what specifically needs to change and in what order.

What suppresses it: Too much creative freedom, insufficient context about real constraints, no framework for what "done" means.

How to enable it: Use a model with strong context about the environment (codebase, org structure, prior decisions). Provide the divergent output as input. Ask for a structured plan with explicit constraints and flags.

Governance and verification

What it looks like: Reviewing the plan against invariants, checking for violations of rules the team has committed to, verifying that the work meets the definition of done.

What suppresses it: Being too close to the work, having authored the plan, optimizing for completion over correctness.

How to enable it: Use a model in a different session, without memory of the planning process. Give it the plan and the governing rules. Ask it to identify violations, not improvements.

The pattern in practice

[Divergent session]
  Input: Scoped task + open-ended questions
  Output: Approaches, risks, alternatives, open questions

[Convergent session]
  Input: Scoped task + divergent output + real constraints
  Output: Structured plan with explicit flags

[Critique session]
  Input: Structured plan
  Output: Annotated plan with issues and gaps

[Governance + execution session]
  Input: Refined plan + governing rules
  Output: Verified, shipped work

The human reviews and approves at each boundary.

Key principles

Never use the planner as the critic. The model that produced the plan is optimized to defend it. A separate session — ideally a separate model — is required for genuine critique.

Divergence before grounding. Introducing real constraints too early collapses the solution space prematurely. Let divergent thinking happen before convergent planning begins.

Governance is a separate phase. Checking work against rules is a different task than doing the work. Collapsing them produces rubber-stamp governance.

The handoff artifact is as important as the output. Each phase produces a document that serves as the input for the next. The quality of that handoff — how clearly it captures what was learned and what remains open — determines how much value carries forward.

Adapting for different contexts

This framework generalizes across domains:

Software development: Scaffold → Ideate (architecture) → Plan (implementation) → Critique → Execute + verify

Strategic decisions: Frame → Diverge (council) → Synthesize → Challenge → Commit

Research and analysis: Define question → Explore broadly → Distill → Pressure-test → Publish

The specific tools, models, and outputs differ. The structure — diverge, converge, govern — is consistent.

What this is not

This is not a prompt-engineering technique. It is an organizational practice — a way of structuring how teams use AI tools so that the collective output is more reliable than any individual session.

It requires discipline, because the natural tendency is to collapse everything into one conversation. That feels efficient. It is efficient for simple tasks.

For complex, high-stakes, or irreversible work, that efficiency is false economy. The cost of a missed assumption found in critique is small. The cost of the same assumption found in production is large.

The multi-model workflow moves the error-finding to the cheapest possible moment.