Integration guide
Running a Qwen-native agent team on Olano
The question people ask is whether Olano supports Qwen. The more useful one is which of qwen-max, qwen-plus, the Qwen3 series and QwQ belongs in which seat of a five-agent team — and whether the team's memory survives when you change your mind.
The short answer: Alibaba's Qwen family is a named, first-class provider in Olano, not something reached through a proxy. Model strings are qwq:qwen-max, qwq:qwen-plus, qwq:qwen3-235b-a22b, qwq:qwen3-32b or qwq:qwq-plus; the key is DASHSCOPE_API_KEY; the international endpoint is selected with DASHSCOPE_API_BASE. Each agent gets its own model, you can switch mid-conversation, and memory and threads live independently of the model — so moving an agent from qwen-plus to qwen-max does not restart anything.
Third-party platform details on this page were checked on 26 September 2026 against each vendor's own documentation. Endpoints, model names and terms move quickly — confirm against the vendor's current docs before relying on them. Olano behaviour described here reflects the current release.
Three routes, chosen by where the data is processed
- DashScope, China endpoint. One key and the whole line-up is available. Inference happens in mainland China — the right route when the entity and the customers are there.
- DashScope, international endpoint. Same models, with
DASHSCOPE_API_BASEpointed at the international service. This is the route for an overseas entity, or for a Chinese company that wants its overseas customers' conversations processed outside the mainland — the residency reasoning is in where your agents actually run. - Open weights, locally. Qwen3 ships open weights; Olano runs local models through Ollama and
qwen3:8bis on the default suggestion list. Prompts never leave the machine, which makes it the natural home for the one role that handles the most sensitive material while the rest stay on the cloud.
All three can coexist in one deployment. That is not a compromise — different roles have different residency and cost requirements, and assigning a model per role is how you honour both.
Assign by role, not by "strongest"
Take a common five-agent team: a lead, support, sales support, research, email. Two rules do most of the work: high-volume simple work goes to the fast model, low-volume hard work to the capable one, and anything that needs multi-step thinking to the reasoning model.
| Role | Shape of the work | Model | Why |
|---|---|---|---|
| Lead | Understands your intent, delegates, summarises | qwen-max | Its judgement steers the whole team; worth the strongest model |
| Support | Hundreds of classifications and replies a day | qwen-plus | High volume, answers are look-ups; the fast model is accurate enough at a tenth of the cost |
| Sales support | Reads a prospect's site, drafts something specific | qwen3-235b-a22b | Reads a lot before writing; context length matters more than speed |
| Research | Compares several sources, reaches a conclusion | qwq-plus | Genuinely multi-step; this is what a reasoning model is for |
| Handles the most personal data | qwen3 via Ollama | Most sensitive role stays local; prompts never leave the box |
Treat the table as a starting point. Run twenty of your own real tasks through the candidates with the model names hidden before you commit — the method is in multi-model agents.
Setup is three steps
- Save
DASHSCOPE_API_KEYin the deployment's console. It can be a deployment-wide key or scoped to one agent — credentials resolve per agent, so two agents in one deployment can use two different Alibaba Cloud accounts. - Set each agent's model string, for example
qwq:qwen-plus.qwqis the provider prefix; after the colon is DashScope's model name. Names beginning withqwqtake the reasoning-model path; everything else takes the standard one. - On the international service, add
DASHSCOPE_API_BASE. Nothing else changes.
No SDK to install, no proxy to run. That is the practical difference between a named provider and a model reached through an OpenAI-compatible route: the second works, but every extra layer is one more place to break. That route is covered step by step in Hunyuan and TokenHub on Olano.
What follows the agent when you change model
This is the question that most decides a platform choice and is least often asked. In Olano an agent's memory, skills, configuration, approval history and current conversation thread all live independently of the model. Move an agent from qwen-plus to qwen-max — or to DeepSeek, Kimi, or any non-Chinese model — and the conversation continues from the last message with nothing lost.
Which also means choosing Qwen is not lock-in. Run the whole team on it today; swap the research seat for a different reasoning model next quarter; migrate nothing. What memory actually holds, and where, is in how AI agents remember.
Two mistakes worth avoiding
- Putting the reasoning model on the high-volume seat. QwQ thinks at every step; used for email triage it costs far more than expected and answers slowly. Keep it for roles that genuinely reason.
- Forgetting that China and international are two endpoints. Keys are not interchangeable and model availability can differ. The common failure is an overseas deployment configured with a China-endpoint key: every request fails and nothing says why.
Next
If the same team also needs to reach WeCom, DingTalk or Feishu on one side and WhatsApp or Telegram on the other, the channel half is in connecting agents to WeCom, DingTalk and Feishu, and the overall shape for a company operating across both is in Chinese companies expanding to Southeast Asia.
Related reading
Multi-model agents
Routing by task shape, and why it beats prompt-tuning on cost.
Hunyuan and TokenHub on Olano
The OpenAI-compatible route, how to set it up, and how it differs from a named provider.
WeCom, DingTalk and Feishu
What each of the three Chinese channels needs and how they behave in groups.
Where your agents actually run
The four places an agent touches data; the model call is one of them.
FAQ
Does Olano support Alibaba's Qwen models?
Yes, as a named first-class provider rather than through a proxy. Model strings use the qwq: prefix — qwq:qwen-max, qwq:qwen-plus, qwq:qwen3-235b-a22b, qwq:qwq-plus — the key is DASHSCOPE_API_KEY, and DASHSCOPE_API_BASE selects the international endpoint.
Can different agents use different Qwen models?
Yes, and it is the recommended pattern: qwen-max for the lead, qwen-plus for high-volume support, QwQ for research that genuinely reasons, and open-weight Qwen3 through Ollama for the most sensitive role. High-volume simple work goes to the fast model, low-volume hard work to the capable one.
Do I lose memory or the conversation when I switch models?
No. Memory, skills, configuration, approval history and the current thread are stored independently of the model, so switching between Qwen models — or to another vendor entirely — continues from the last message. Choosing Qwen is therefore not lock-in.
Where is data processed when using Qwen?
It depends on the route: the DashScope China endpoint processes in mainland China; the international endpoint, selected with DASHSCOPE_API_BASE, processes outside it; open weights through Ollama run on your own machine so prompts never leave it. The three can coexist in one deployment, assigned per role.
Where should the QwQ reasoning model be used?
On roles that genuinely need multi-step reasoning, such as research that compares several sources. Not on high-volume seats — it thinks at every step, so using it for email triage costs far more than expected and replies slowly.
One key, a model per role
The whole Qwen line-up out of the box, with the China endpoint, the international endpoint and local open weights able to coexist — and memory that stays put when you change your mind.