How Recruit Holdings, the company behind Indeed, taught its text-to-SQL agent to read a website's hidden context

At dbt Summit 2026, Junya Morita, manager on the data management group at Recruit Holdings, walked through how his team tackled one of the more frustrating problems in applied text-to-SQL: agents that technically had access to the right data but still returned wrong answers because they misidentified event names. Recruit Holdings, the Tokyo-based parent company of Indeed, runs matching platforms across jobs, housing, automotive, beauty, and weddings in Japan.

Morita's team works on the automotive marketplace, a car listings service called Car Sensor comparable to CarGurus in the US. The team had built a Slack-based analytics agent, internally nicknamed Goro, so product managers and analysts could ask natural-language questions and get back SQL, results, and insights without waiting on a data team.

The agent had access to table definitions, golden queries, and dimensional models generated through dbt, plus a semantic layer for common metrics. That was enough for straightforward questions.

It fell apart on UX-specific questions, like how many users tapped a "make a reservation" button, because the underlying event log contained a cluster of near-identical event names (tap reserve, tap reserve icon, show render, complete reservation) that no model could reliably disambiguate from the data alone.

Morita's team considered building a general-purpose system ontology to capture that kind of tacit knowledge, then rejected it for lacking concrete, provable examples in production. Instead they took what he called an issue-driven approach: pick a specific failure, identify the exact hidden context needed to resolve it, and write that context into a YAML file rather than leaving it undocumented in people's heads.

The result is a "web domain context" schema that encodes user actions (page views, clicks, checkouts, conversions), the UI elements those actions target, and the log entries they generate, all in a single, reviewable file that the analytics agent can query alongside the dbt-generated schema.

But that context kept going stale. Recruit's automotive team runs dozens of A/B tests a month, so the UI changes constantly, and two product teams can unintentionally define conflicting meanings for the same event without any version control tool catching it.

Morita's fix was procedural as much as technical: the YAML log design file now has to be written and reviewed before any related feature ships, front-end logging code gets generated from that file rather than written by hand, and QA test cases are built directly against the same file so a mismatch between what was designed and what was implemented gets caught before release.

In the live example Morita walked through, the agent was asked for the unique user count on a niche "residual value loan" screen. Without the domain context file, that kind of query name has no reliable mapping to an event ID. With it, the agent searched the log design table, matched the string to the correct event, and returned the right number.

Looking ahead, his team is now experimenting with writing user-journey intent (not just implementation and design) into the same kind of structured file, so the agent can eventually reason about whether a sequence of actions looks like a drop-off rather than just counting events.

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →