Add Model Diversity with a Cross-Vendor Council

The advanced council uses models from different vendors rather than running every agent on one model. The purpose is to reduce dependence on the characteristic behavior and vulnerabilities of a single model family.

Prompt diversity and model diversity solve different parts of the problem. Role prompts vary the perspective assigned to each agent. Cross-vendor execution also varies the model producing that perspective.

The cross-vendor mode sends council work through OpenRouter, which provides access to multiple LLMs. One run includes responses from GPT, Gemini, an Opus model, and Grok, with an additional model used in a reviewer role.

The models produce separate answers, and the workflow combines them through the council's review process. The user can inspect each model's contribution rather than receiving an opaque final answer with no indication of which models participated.

The motivation is that different models often respond in different ways and may be stronger at different kinds of work. A cross-vendor council uses that variation as part of the deliberation process.

The business example shows that architecture can affect the recommendation. The same-model council leaned toward scaling the low-ticket membership. The cross-vendor council leaned more toward the high-ticket path.

This divergence is important. It demonstrates that a council's answer is influenced by both its role prompts and its model composition. Calling several agents does not automatically make a result neutral if every agent shares one underlying model.

The cross-vendor workflow is treated as the most thorough mode because it combines both forms of diversity: multiple agent roles and multiple model families.

Use cross-vendor mode when the decision warrants extra thoroughness and the user wants the perspectives of several model families in one coordinated process.

The decision prompt should remain the same kind of detailed strategic brief used in default mode. The difference is not that the question becomes less specific. The difference is that the council routes the work across several models before review and synthesis.

Inspect the model-level outputs after the run. Compare where they agree, where they differ, and whether the final recommendation reflects the range of responses shown in the council trace.

Cross-vendor execution requires additional setup, an API key, and paid API usage. It is therefore not the default recommendation for every question.

The example also shows that additional model diversity can change the answer rather than merely strengthening the original conclusion. A user should be prepared to examine the reasoning, not treat the cross-vendor result as a decorative confirmation of the single-model output.

Cross-vendor mode adds model diversity to role diversity. Use it when the value of a broader, more thorough deliberation justifies the extra configuration and cost.