There is a strong pull toward simplicity when choosing AI models. Pick one provider. Use one model for everything. Keep the integration surface small. We understand this instinct. We rejected it.
Cleo uses different models from different providers for different tasks. The conversational intelligence uses one family of models. Service-layer text generation uses another. Image generation comes from a third. Embeddings from a fourth. Each was chosen for a specific reason, and none of them is interchangeable.
The specialisation thesis
Language models are not general-purpose in the way people assume. A model that excels at nuanced, multi-step reasoning in conversation may not be the best at generating structured marketing copy. A model optimised for fast, focused text generation may not be the best at holding a complex strategic dialogue. An image model from one provider may produce dramatically different aesthetic qualities than one from another.
When you force a single model to do everything, you get average performance across all tasks instead of excellent performance on each one. In a product where output quality directly translates to business results for the user, average is not good enough.
The routing philosophy
Our architecture routes each task to the model best suited for it. Conversational reasoning goes to a model that excels at nuanced dialogue. Content generation tasks go to a model that produces clean, structured output quickly. Image generation goes to a model that produces the highest visual quality. Embeddings go to a model with strong semantic understanding at low latency.
This routing is invisible to the user. They interact with Cleo as a single intelligence. Behind the scenes, their request may touch two or three different models in the course of being fulfilled. The user does not need to know or care which model generated their Instagram caption versus which one reasoned about their campaign strategy.
The integration cost
Multiple models means multiple providers, multiple APIs, multiple billing relationships, multiple failure modes. This is a real cost. We manage it through a unified configuration layer that abstracts provider-specific details behind consistent interfaces. When we switch a model or add a provider, the change is contained to one place.
Why this compounds
The multi-model approach compounds in value over time. As new models emerge with specific strengths, we can slot them into the appropriate role without disrupting the rest of the system. We are not locked into a single provider's roadmap. We can choose best-in-class for each task independently.
The user experiences this as a product that simply produces excellent results. That experience rests on a deliberate architectural decision to never settle for one model's compromise when multiple models' specialisation is available.
- Cleo's Team