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 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!
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
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)
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