I spent three weeks building a hybrid SQL + search agent for supply chain intelligence. It could query our Snowflake database, search the web, and synthesize answers. It worked beautifully — until I noticed it was confidently wrong about 30% of the time.
The pattern was always the same: the agent would find the right entity in our database, go to the web for additional context, and come back with information about a different company. Not a random company — a famous one. The one that dominated search results for that topic.
Snowflake AI Research published a paper in June 2026 that gave this failure a name: the salience trap. It’s one of three handoff failures in their HybridDeepResearch benchmark. Reading that paper changed how I architected the entire system.
I didn’t discover these failure modes from the paper. I discovered them from users reporting wrong answers, then found the paper explained exactly what I was seeing.
The salience trap hit me first. A user asked “Which of our battery suppliers have had EPA violations?” The agent correctly found our supplier — a mid-size manufacturer I’ll call LithiumCore. Then it searched the web for “battery supplier EPA violations” and returned a wall of results about Tesla. The answer came back: “Tesla has had EPA violations.” Tesla isn’t our supplier.
Dropping the anchor was subtler. A user asked about a company they’d seen in the news — “That company announcing a gigafactory in Nevada, do we order from them?” The agent found the company name from search results, then wrote a SQL query that returned all suppliers instead of filtering for that specific company. The WHERE clause just… wasn’t there.
Skipping the intersection was the most common. “Which active suppliers are in sanctioned countries?” The agent searched the web for sanctioned companies, found three names, and returned all three. It never checked whether those companies were actually in our supplier database. Two of them weren’t.
The HybridDeepResearch paper’s key insight isn’t about better prompts or smarter models. It’s about system architecture. Their top-performing system, ArcticSwarm, keeps SQL and search insulated from each other during execution. They only interact at a validation layer.
I implemented this as what I call the entity-lock gate. The rule is simple: once one modality identifies an entity, that entity becomes a hard constraint on the other modality’s results. Not a suggestion. Not a preference signal. A filter.
For sql_to_search — the most common pattern — it works like this: SQL finds LithiumCore Technologies. That name becomes a literal string filter on search results. Any web result that doesn't contain "LithiumCore Technologies" in its title or body gets discarded. Even if it's the top Google result. Even if it's perfectly relevant to "battery EPA violations." The critical decision was making this a filter, not a ranking signal. Early versions boosted results mentioning the entity but still included high-ranking alternatives. That didn’t work — the agent would still gravitate toward the salient result in its synthesis step. Hard filtering is less flexible but actually solves the problem.
The search_to_sql pattern — where you discover an entity from the web and then query your database — turned out to be significantly harder than I expected. The paper warned about this (they call it the hardest pattern "by a wide margin") but I didn't fully appreciate why until I built it.
The issue: translating a fuzzy entity name from a news article into a precise SQL WHERE clause requires exact string matching against your database’s naming conventions. “LithiumCore” in a news headline might be stored as “LithiumCore Technologies Inc.” in your supplier table. The agent needs to handle this resolution step explicitly — you can’t just trust the LLM to get it right in a single shot.
My workaround: after search resolves an entity, I validate that the entity actually appears in the SQL results. If SQL returns 15 rows and none of them contain the discovered entity name, I flag it as “anchor dropped” rather than returning potentially unrelated data. It’s conservative, but it’s honest.
The other surprise: parallel fusion is actually the easiest pattern, not the hardest. Because you have a rigid database shortlist acting as a natural filter on fuzzy web results, the intersection step is straightforward. The paper’s evaluation data confirmed this — parallel fusion had the highest scores across all tested frameworks.
The interface organizes questions by reasoning pattern — SQL→Web, Web→SQL, Parallel Fusion, SQL Only, Web Only. Each category has clickable buttons that fire the corresponding pipeline. You can also type freely.
Youtube Demo:
The validation tab is where the entity lock becomes visible. It shows three columns: SQL entities (what we found in our database), search entities (what we found on the web), and the intersection. If the intersection is empty, the answer says so — it doesn’t fall back to returning web results alone.
The whole thing runs on Groq’s free tier (LLaMA 3.3 70B) with local SQL search for the demo. Swap to Tavily for real web results or Snowflake Cortex for production. No code changes — just a config dropdown.
The entity lock is intentionally over-restrictive. It will sometimes reject valid search results because they use a slight name variation. I’d rather have a false negative (no external info found) than a false positive (wrong company substituted). For enterprise use cases, precision matters more than recall.
Store API keys in a Snowflake table, not secrets objects, on trial accounts. External Access Integrations (required for binding secrets to Streamlit apps) aren’t available on trial. A simple APP_SECRETS table with ACCOUNTADMIN-only access is the pragmatic workaround.
The salience trap isn’t a prompt engineering problem. It’s an architecture problem. When your agent crosses the boundary between structured database results and unstructured web search, you need a mechanism that prevents one modality from overriding the other.
Entity-lock validation is that mechanism. It’s simple — filter search results to only those mentioning the SQL-identified entity. It’s conservative — it will miss valid results that use name variations. But it eliminates the most common and most damaging failure mode in hybrid enterprise agents.
Full source is on GitHub. It runs on a trial Snowflake account with Groq’s free tier. Ask it a question that spans your database and the web, and watch whether the entity lock catches what a naive agent would miss.
GitHub: hybrid_agent This article represents the author’s personal views and experience, not those of any employer.
👏 Give it a clap if it added value
🔗 Share it with your team
➕ Follow for more
📘 Medium: Satish Kumar 🔗 LinkedIn: satishkumar-snowflake See you in the next one! 👋
The Entity Lock Pattern: Preventing Hallucination When AI Agents Cross the SQL/Web Boundary was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.