Recruit Holdings Teaches Its Text-to-SQL Agent to Read a Website's Hidden Context

The problem: right data, wrong answers

Recruit Holdings 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, which dbt Labs describes as comparable to CarGurus in the US.

The team had built a Slack-based analytics agent, internally nicknamed Goro. Product managers and analysts can ask it 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, and dimensional models generated through dbt, plus a semantic layer for common metrics.

That setup handled straightforward questions. It failed on UX-specific ones, such as how many users tapped a "make a reservation" button. The event log held a cluster of near-identical event names (tap reserve, tap reserve icon, show render, complete reservation) that, according to the post, no model could reliably disambiguate from the data alone.

An issue-driven fix instead of a general ontology

Morita's team considered building a general-purpose system ontology to capture this kind of tacit knowledge. They rejected the idea because it lacked concrete, provable examples in production.

They chose what Morita called an issue-driven approach instead: 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. It encodes user actions such as page views, clicks, checkouts, and conversions, the UI elements those actions target, and the log entries they generate. All of it sits in a single, reviewable file that the analytics agent can query alongside the dbt-generated schema.

Keeping the context from going stale

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

Morita's answer was procedural as much as technical:

• The YAML log design file must be written and reviewed before any related feature ships.
• Front-end logging code is generated from that file rather than written by hand.
• QA test cases are built against the same file, so a mismatch between design and implementation is 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 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.

What comes next

Morita's team is now experimenting with writing user-journey intent, not just implementation and design, into the same kind of structured file. The goal is for the agent to eventually reason about whether a sequence of actions looks like a drop-off rather than only counting events.

For teams building text-to-SQL agents, the case points to a practical lesson from the source: access to the right tables is not enough when the meaning of event names lives only in people's heads. Recording that meaning in a versioned file, and tying it to how logging code and tests are produced, is how Recruit kept the agent's answers accurate. dbt Labs says every keynote and breakout from dbt Summit 2026 is available on demand.