What the model actually sees when your vector store finds nothing
The instinct is to rewrite the tool descriptions. Make the vector store one more specific. Make the HTTP Request one more narrow. Spend an afternoon iterating on prompts. That helps sometimes, but it won't solve this.
Here's what's happening: when your vector store finds no matching documents, it returns an empty array. The model reads that as "the tool ran successfully and found nothing." Which is true. The problem is that result looks identical to "this query is outside the vector store's scope" — both show up as silence in the context the model sees.
When the model gets silence from one tool, it reaches for the next option. HTTP Request is right there. It's doing what you'd want in theory — if one source doesn't have the answer, try another. The routing logic just breaks down when "no results" and "wrong tool" produce the same output.
This shows up in the n8n community forum regularly, and there's a closed GitHub issue (#11173) showing the same pattern across different model providers. The description is consistent: agent picks HTTP when the answer is in the vector store, or picks HTTP first and never tries the vector store at all.
Change what the tool returns when it finds nothing
The fastest fix is making the vector store return an explicit string on a miss instead of an empty array.
Add a Code node inside the tool's sub-workflow that checks the similarity score of the retrieved documents. If the score falls below your threshold, return a string like NO_MATCH (top score: 0.38, threshold: 0.75) rather than an empty array or nothing at all. That's a stated result, not silence. The model can reason about it.
This change also unlocks something useful in the system prompt. Once the empty case has a distinct return value, you can write a specific rule: call the vector store first; only call HTTP Request when the output is NO_MATCH. Vague descriptions get ambiguous results. A rule that references a specific output string is harder to override.
A tool that returns nothing and a tool that returned nothing relevant look the same to the model. If you want them treated differently, they have to output differently.
Write the priority rule into the system prompt
Tool descriptions tell the model what a tool does. The system prompt tells it how to reason. Both matter, but they do different jobs.
Once the vector store is returning explicit NO_MATCH values, add something like this to the system prompt:
Always call the Knowledge Base tool first. Only call the HTTP Request tool if the Knowledge Base returns NO_MATCH. Never call HTTP Request before checking the Knowledge Base.
That reads like overkill. Without it, the model treats the tools as peers and picks whichever seems more relevant to the question. With an explicit ordering rule, it follows a procedure.
Two things worth keeping in mind: the tool names in the system prompt have to match the names in n8n's configuration exactly (case-sensitive, no paraphrasing), and the tool count matters more than most people realize. Agents with two to three well-described tools route more consistently than ones with five or more. If you've got a dozen tools attached, narrowing the list is often worth trying before anything else.
Take the routing decision away from the model
If you've done both of the above and the agent is still wandering, remove the HTTP Request tool from the agent entirely.
Build the routing as a workflow branch instead. The agent calls the vector store. If it returns NO_MATCH, an IF or Switch node routes to an HTTP Request node downstream. The agent never chooses between them — the workflow structure makes that decision.
You give up flexibility. The agent can no longer make judgment calls about when an API call is appropriate. But if your use case has a clear condition for when the HTTP call should fire, building that into the workflow beats hoping the model infers it correctly every time.
A router you control beats a router you prompt. When the routing decision has real stakes, it shouldn't live inside the agent.
This matters most when the HTTP action has real consequences — API usage costs, rate limits, write operations. We've built this pattern into several client workflows where the external API call was expensive and had to be a last resort, not a first guess. The agent handles the knowledge retrieval; the workflow handles the escalation.
It's also worth reading alongside the broader question of when an agent adds value versus when a deterministic workflow is better — the routing decision is one place where the answer often ends up being "both, in layers."
A few other things to rule out first
Before rebuilding the workflow: check that the vector store is actually filtering by similarity score. If you're returning the top K documents regardless of relevance, the model might receive low-score results, treat them as an answer, and still call HTTP to confirm. A score threshold changes the behavior significantly.
Also try swapping the model. GPT-4o and Claude Sonnet follow tool ordering instructions more reliably than faster, smaller models. If changing the model fixes the routing, you've found the real constraint, and you can decide whether the cost difference is worth it.
And if you're not sure what the agent is actually picking, add logging: a Code node that writes the tool name and input to a table on every call. That's faster than debugging from outputs alone. Related: if the agent is routing correctly but the writes themselves aren't landing, that's a different problem — see when n8n runs green but the write never landed.
If you're building AI automation workflows that need predictable tool routing, this pattern — explicit NO_MATCH strings plus a downstream routing branch — is usually where we land in production. The agent does the retrieval; the workflow does the escalation. Clean separation, and both sides stay testable.
Sources
- AI Agent with HTTP Request, Code, and Vector Store — n8n Community (the thread that prompted this post)
- Issue #11173: AI Agent vector store tool (Supabase) — n8n GitHub
- AI Agent not using Vector Store — n8n Community
— Cole