lucamrtl

Thanks for the comment - i believe the anthropic team was referring to sql here, not natural language

Thanks for the comment, good question - there's some overlap. Graphene does the full query -> viz loop, and the model has to be handwritten in their GSQL. It's kinda like a code-first BI tool. Whereas ktx is building and managing the context (interface between BI stack and agents), so doing the modeling part of the job and focusing on agent context rather than viz. Hope that's more or less clear

Thanks for writing the article!

Quick update - we just released support for codex as LLM backend :)

Nice! Feel free to join our slack community btw: ktx.sh/slack

we always like chatting with folks that have tried building similar projects in the past

Thanks for the feedback - the length is typically because we’re also processing query history to infer acceptable joins, etc. But we have a lot of optimizations to implement, so we’re positive this will run faster in the coming weeks. Looking into the pg_desc issue now, thanks for reporting!

Here's the community https://ktx.sh/slack

We currently support anthropic models for the setup (whether through claude pro/max plan) or through API. Adding support for openai API / codex should be pretty straightforward - would love to get you in the community slack to get more details on your copilot setup

Thanks!

Just to complete the answer if that's where your question was going - we actually built a prepackaged project that users can use to experiment with ktx before running any kind of ingestion. In our docs we also have a link to a demo postgres, dbt, metabase, and notion that users can access to try out ktx

And better comparisons from the semantic layer space are tools like Wren, Cube, dbt MetricFlow

Just to clarify what semantic layer is: you can think of it as a set of functions

So you define the definitions of metrics like "monthly revenue" once, and that definition is runnable. If an agent asks for "monthly revenue by region", the semantic layer will compile that request into SQL and run it (the same way everytime so that calculation method is consistent)

And development was done around link detection and text to sql benchmarks to measure/compare different approaches

Thanks for the question! Just to complete - OpenVikings is context/memory infrastructure for agents. ktx is analytics context for data agents specifically. So they're in different categories

The way we think about the space: there's a "semantic layer" side (Cube, dbt MetricFlow, Wren's engine) that compiles correct SQL but is hand-authored. And a "company brain" side (OpenViking, Glean, wikis) that indexes prose but can't query data warehouses safely. ktx is built to be both halves at once - a YAML semantic layer and a searchable wiki of business definitions, cross-linked (each wiki page references the metrics it explains) and auto-maintained

100% open source library for testing NLP models and datasets! Come contribute!