KOHO builds Claude-powered analytics tool KoDa on years of dbt governance

What KoDa does and how it is built

KOHO is a Canadian fintech with about 250 employees, currently in phase two of three toward a Canadian banking license. More than 10 percent of its staff are data people. In a session at dbt Summit 2026, summarized by dbt Labs, Célia Bru, senior director of data, and Gabriel Gambacorta, technical product manager, described KoDa, the company's self-serve analytics tool.

Employees ask questions in Claude, and answers come from a governed dbt data mart running on Redshift, with Bedrock and Claude providing the LLM layer. Gambacorta explained that KoDa is a "KoDa skill": markdown files plus pre- and post-hook MCP calls, surfaced through Claude Code and connected to the dbt marts through a Redshift MCP server.

Bru said the main components already existed: a clean dbt mart, a production-grade warehouse and an LLM available companywide. What was missing was connecting them securely and in a governable way.

Design limits and the governance behind them

The team set firm design principles for KoDa:

• It is scoped to analytics use cases only, with no debugging or investigation of individual transactions.
• It touches only certified dbt mart models, with no raw data or PII.
• It is read-only and cannot write back to the warehouse.
• Every employee gets the same single experience.
• Every answer traces back to the same company-wide dbt definitions.
• It runs on infrastructure KOHO already had, not new vendor tooling.

Bru said none of this would have been possible without earlier work. She described a "referee position" for the data team: it owns the inputs into a decision but not the decision, and it owns metric definitions so no team decides what counts as a win. That approach led KOHO to scrap its entire pipeline in 2022 and rebuild it in dbt. The rebuild now comprises roughly 1,400 models with tests and documentation, with all PII stripped out.

Because KoDa works only with governed marts, Bru said, it has become one of the strongest arguments for moving the rest of the company onto the same foundation. Teams without a governed mart cannot use the tool.

Evaluation took the real effort

According to Gambacorta, the skill itself was not the hard part. The evaluation layer was. Roughly 11 commits from three people over three months went into building context libraries and what he called an "eval council", a growing library of about 375 real analyst questions.

The library supports offline evaluation, which tests whether a change to the style guide improves or worsens answer quality, and online evaluation. In the online case, every question KoDa answers is logged, and an analyst on a weekly rotation reviews new or high-priority ones.

Gambacorta noted that roughly a third of dbt Summit sessions this year touched on context or the semantic layer, but only about one in 33 covered evaluation. He called that backwards, given how much of KOHO's effort went into evals.

Trust, adoption and what comes next

Bru said the data team built its credibility over years by being in the room for every answer, and self-serve tools remove the team from that room. For now, KOHO logs every question KoDa is asked and still personally reviews any self-serve result headed to the board.

Both speakers argued the bottleneck is shifting from tooling to people: teaching a company when to trust a self-serve answer and when to return to the data team, and building enough data literacy that people ask better questions.

In the Q&A, they described a hub-and-spoke team of domain-specialist analysts who write role-specific example queries to drive adoption. They also said KoDa's usage volume already exceeds what used to reach the data team through Slack, which suggests it surfaces questions that were never asked before rather than only replacing old ones.

For other companies, the case points to governed data models and evaluation work as the prerequisites for a tool like this, rather than the choice of model.