Recruit Holdings Fixes Text-to-SQL Agent's Event Name Confusion

At dbt Summit 2026, Junya Morita, a manager in Recruit Holdings' data management group, explained how his team solved a persistent problem with their text-to-SQL analytics agent: it had access to the right data but still returned wrong answers because it misidentified event names. Recruit Holdings, based in Tokyo and the parent company of Indeed, operates matching platforms across jobs, housing, automotive, beauty, and weddings in Japan.

Morita's team works on the automotive marketplace Car Sensor, a car listings service similar to CarGurus in the US. They built a Slack-based analytics agent nicknamed Goro so product managers and analysts could ask questions in natural language and receive SQL, results, and insights without waiting on a data team. The agent had access to table definitions, golden queries, dimensional models generated through dbt, and a semantic layer for common metrics, which handled straightforward questions fine.

It broke down on UX-specific questions, such as how many users tapped a "make a reservation" button, because the event log contained near-identical event names - tap reserve, tap reserve icon, show render, complete reservation - that no model could reliably tell apart from the data alone. Morita's team considered building a general-purpose system ontology to capture that tacit knowledge but rejected it for lacking concrete, provable examples in production. Instead they took 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, the UI elements those actions target, and the log entries they generate, all in a single, reviewable file 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 must now 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 design and implementation gets caught before release. In a live example, the agent was asked for the unique user count on a niche "residual value loan" screen. Without the domain context file, that 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, the team is experimenting with writing user-journey intent 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.

Source: dbt Labs Blog