I’m building Cassis, a tool for maintaining the context used by analytics agents.
Of course, before you can maintain context, you need a context to begin with.
By context, we mean the information an analytics agent needs to generate the right queries to answer questions reliably: what business domains that data covers, what tables and columns mean, what are governed metrics and joins, etc.
So far, we’ve been building that first version manually with customers. They send us what they have (schema dumps, dbt repos, glossaries, internal documentation, query logs, dashboard exports, and so on) and we assemble it with the help of coding agents. Eventually, we want to automate as much of this as possible in the product.
In the meantime, I wanted teams to be able to assemble their initial context without us, so I packaged our internal methodology into skill (instructions, scripts, and review checkpoints). The guiding principles behind it are: 1. you already have most of what an analytics agent need in your repo and internal docs and 2. you should never let an LLM invent business meaning for you. So bootstrapping context is mostly about recovering what already exists, connecting it to the right data objects, and keeping track of what each source can actually support.
The skill takes in: your schema dump, dbt code, plus glossaries, docs, dashboards and query logs if you have them. During the process, it generates a list of questions to answer for key decisions (e.g. how to cut your business into relevant domains), when it detects gaps, and when it detects ambiguities. The result is a repo with a first version of your context as YAML and markdow files, in a file tree, that you can feed your analytics agent (or a PR enriching your dbt repo with structured metadata and docs): metrics, business domains, joins.
It runs locally with your favorite coding agent and doesn’t require a Cassis account. We’ve built and tested the workflow with Claude Code so far.
Happy to get your feedback on the approach and the skill itself.