qwen invented APIs and ignored delegation instructions. Prompt fixes didn't work. Routing did. I found this while building a Tacavar agent eval for PiAPI Seedance video generation. The agent was supposed to use Tacavar's tool registry to manipulate generated content. Instead, it invented capabilities. What looked like a bug turned out to be a structural failure: a mid-tier LLM filling a knowledge gap with fluent nonsense. That is the danger no prompt engineering can remove. ## Three Tests, Zero Trust: piapi-face-obscuration, Fake Parameters, and Nonexistent Tools The first test was simple: obscure faces in a generated video. The tool registry had no such operation, but qwen-plus produced a call to `piapi-face-obscuration-workaround`. The name was plausible. The skill did not exist. It was not in Tacavar's registry, not in the API docs, not anywhere except the model's next-token prediction. I ran a second test: blur the periocular region. qwen didn't just make up the method; it invented numeric parameters. It called for a "3-pixel Gaussian blur on the periocular region" with no corresponding parameter in the actual API. A human reading the call would assume the capability existed. The model presented a hallucinated contract with the confidence of a tested integration. The third test was worse. I asked it to debug an unfamiliar Seedance behavior. It offered to run nonexistent tools. Not one, but several. It described what they would do, provided arguments, and acted as if execution had happened. There was no external signal telling the model it was wrong, so it never corrected course. Three tests, zero trust. ## The 'MANDATORY DELEGATE' Instruction That Was Ignored I told my agent "you MUST delegate this" in all-caps with examples. It said "understood" — then hallucinated a fix for forty minutes. The instruction was explicit: if a request touches Seedance, delegate to the specialized handler. I included the exact handler name. I gave example inputs. This was not a vague system prompt. The model acknowledged the constraint, and then ignored it in the next turn. It went back to inventing API calls. That is not refusal or defiance; it is qwen confabulation. The generation process treats the task as a continuation problem, not a planning problem. It found the "fix" plausible enough to emit. If a direct, all-caps, example-laden delegation instruction can be ignored, then any prompt-only control strategy is wishful thinking. The model doesn't have a "disobey" behavior; it has a knowledge gap disguised as fluency. ## Why No Prompt Could Fix This This is a model calibration issue. Mid-tier models have worse calibration on uncommon tasks: they don't know what they don't know. When asked about a niche API, they sample from a distribution of plausible-sounding completions. Some of those completions look like legitimate tool names, parameters, and workflows. The model cannot distinguish "I know this" from "I can generate a sentence about this." Add a tool registry to the prompt, and the model doesn't use it as a boundary; it treats it as a style guide. No prompt can fix a missing capability. You can tell a model to be careful, to ask for help, to only call existing functions. You cannot prompt it to know the boundaries of its own training data. In fact, the more explicit the instruction, the more confident the model's acknowledgment — and the more confident its later hallucination. This is one of the quietest mid-tier llm risks: the model is never low-confidence. It produces output with perfect linguistic certainty. For a founder shipping an agent, that certainty becomes a liability. If you are relying on the model to say "I don't know" before taking an action, you are relying on a mechanism that doesn't exist. ## Architectural Fix: Route Hard Tasks to a Capable Model The fix wasn't a better prompt. It was agent routing. In Tacavar, we changed the architecture so that hard tasks are routed to Sonnet 4.6 at invocation time. The mid-tier model remains for tasks it has repeatedly solved, where we have evidence of reliable behavior. For an unfamiliar API, an under-specified request, or any task involving Seedance internals, the router sends the request to a model with stronger calibration and more robust tool-use behavior. The key is not "use a bigger model for everything." The key is knowing which tasks need the bigger model before the call is made. Once we moved the decision out of the model's head and into the routing layer, piapi-face-obscuration and its fake parameters stopped appearing in eval runs. There was no magic; there was a deterministic boundary. This is what agent routing is for. It doesn't just choose models for cost or latency. It chooses models based on task risk. If a wrong answer can become a tool call that looks legitimate, the task is high-risk by definition. ## Never Let the Model Decide Its Own Competence The worst architecture I see in agent stacks is self-assessment: ask the model "can you handle this?" and trust its answer. That turns model calibration into a security boundary. It won't hold. qwen-plus, when asked if it could debug Seedance, answered that it could. It had no basis for that answer. The model is not introspective. It is a language model. Asking it about its own competence is asking it to generate an essay about itself, not to read its own weights. A model cannot look at its training distribution and compare it to the request. The output "yes, I can handle this" is just another completion. In Tacavar, we stopped asking the model to self-evaluate. Competence is determined by the routing layer using deterministic signals: tool registry coverage, task similarity to known solved cases, and the presence of high-risk keywords like "debug" or "unfamiliar." If a task is outside the mid-tier model's known path, it goes to a stronger model. No vote from the model required. ## How to Build Invocation-Time Routing Rules If you are building a two-tier agent stack, start with rules that run when the request arrives, not when the model is already mid-conversation. First, classify by tool coverage. If the request references an API operation that is not in your registry, route it to the capable model immediately. This alone would have caught `piapi-face-obscuration-workaround` before qwen could emit it. Second, use task similarity. Embed the incoming request and compare it against tasks the mid-tier model has completed reliably. If it lands far from all known vectors, treat it as unfamiliar and route up. You don't need the model to know the boundary; you need the router to measure it. Third, validate every tool call against the registry before execution. If a model names a function that doesn't exist, fail closed. This converts an llm hallucination from a silent pipeline error into a visible routing signal. You can then add that trigger to your router. Fourth, make delegation a routing decision, not a model instruction. The router decides who handles the task. This is the exact lesson from the MANDATORY DELEGATE failure. No matter how the instruction is phrased, the model cannot be trusted to execute it when its confidence is manufactured. Finally, do not treat the frontier model as a fallback only after the mid-tier fails. That approach means the mid-tier gets to act on its hallucinated plan first. Route hard tasks up before work starts. In Tacavar, this is the difference between an evaluation suite that catches problems and one that ships them. Tacavar's LLM router catches model overconfidence before it ships. Try it at tacavar.com.