Skip to content

Context maintenance for analytics agents

Schemas change, definitions move, and nobody updates the context your agents read. Cassis catches the drift, drafts the fix, and proves it against evals. Each fix goes to the person who owns the definition, and your agents only read what your team has approved.

Not on the data team? Send them this page

Trusted in production by data teams, including

Cassis keeps the context answering 1,000+ Alaners' analytics questions current on a 6,900-table warehouse.

The problem

Context drift does not fail CI

Business logic changed

User

How many accounts activated last month?

Agent
·Searching context for “activated account”
×No definition found
→ Using accounts.status = 'active'

2,431 accounts activated last month.

Expected expression
✓ first_deployment.status = 'succeeded'

1,847 accounts activated last month.

Schema changed

declared unit change in dbt manifest
− deployments.duration · seconds + deployments.duration · milliseconds
Query, unchanged MEDIAN(deployments.duration)
Median deploy time
before change
4m 12s
after change
2d 22h

3 context references affected

The loop

Serve always current, tested, approved context to your agents

Claude Code · cassis-context

01/06 · Listing maintenance issues

› List the open Cassis issues.
● cassis · list_issues
Open issues (2)
1. No governed definition of “activated account”
cause: ontology_gap · impact: wrong_answer · observed in 6 conversations
Proposed fix: activated after the first successful production deployment.
2. Pending source change
Source: declared unit change in dbt manifest
deployments.duration · seconds → milliseconds
breaking · 3 context references affected

02/06 · Drafting the metric proposal

› Fix the activated account gap.
● Drafting a metric change from 6 observed conversations.
● Write(cassis/metrics/activated_accounts.yml)
Proposal only · Approval required from @activation-data
description: >
  Accounts whose first successful production deployment
  occurred in the requested period. Internal accounts excluded.
display_name: Activated accounts
domain_path: product/activation
expression: COUNT(DISTINCT "ACCOUNT_ID")
filters: '"IS_INTERNAL" = FALSE'
name: activated_accounts
synonyms:
- activated accounts
- activated customers
table_name: FIRST_DEPLOYMENT
table_schema: PRODUCT
unit: accounts

03/06 · Validating the context files

$ cassis context check
✓ YAML parsing, round-trip and import validation passed
✓ 35 files valid · schema references resolve

04/06 · Testing against the eval suite

$ cassis eval run
✗ failed How many accounts activated last month?
not_equivalent · gold SQL returned 1,847, the agent returned 2,431
the draft counts accounts whose first deployment failed
11/12 passed
$ # count only succeeded first deployments, rerun
✓ 12/12 passed · month boundaries · retries · internal accounts
each case scored against its gold SQL, validated by a domain owner

05/06 · Pushing the review branch

$ git checkout -b cassis/activated-accounts && git add cassis/ && git commit -m "Govern the activated account definition" && git push -u origin HEAD
✓ Branch pushed to origin/cassis/activated-accounts

06/06 · Opening the GitHub pull request

$ gh pr create --title "Govern the activated account definition" --fill
https://github.com/acme/analytics-context/pull/42
PR #42 opened · Review required: @activation-data via CODEOWNERS
Keeping enterprise-scale context up to date
“In one summer, I built the context for our analytics agent on Alan's 6,900-table warehouse, on my own. Using Cassis tools in Claude, I automatically draft each domain from our existing data assets, run checks and evals, review the PR, make the decisions, and move on to the next domain.”
Chloé Pont , Data Scientist, Alan
Detection

How Cassis detects drift

As the context runtime for your analytics agents, Cassis records a gap each time an agent has to guess: no governed definition, two plausible signals, a clarifying question.

It also diffs every schema and dbt change against the context that references it. Your definitions are imported, not redefined.

When nothing your team approved covers a question, the agent says so and asks instead of guessing.

Claude Code · Cassis MCP
› Ask Cassis: how many accounts activated last month?
● cassis · ask_question
“Activated account” is not defined in the context.
Two plausible signals:
1. accounts.status = 'active'
2. First successful production deployment
Pick one or provide your own definition.
› List the open Cassis issues.
● cassis · list_issues
Open issues (2)
1. No governed definition of “activated account”
cause: ontology_gap · impact: wrong_answer · observed in 6 conversations
Proposed fix: activated after the first successful production deployment.
2. Pending source change
Source: declared unit change in dbt manifest
deployments.duration · seconds → milliseconds
breaking · 3 context references affected
Your workflow

Manage your context directly in your Git repository

Cassis structures your context as a Markdown and YAML file tree following Google's Open Knowledge Format.

Use the CLI and MCP from your preferred development environment to inspect detected issues, review and test proposed fixes, and publish approved context through your existing Git workflow.

acme / analytics-context Pull request #42

Govern the activated account definition

#42

acme-data wants to merge 1 commit into main from cassis/activated-accounts
Evidence: 6 observed conversations · Proposal only

cassis/metrics/activated_accounts.yml
+1 + description: >
+2 + Accounts whose first successful production deployment
+3 + occurred in the requested period. Internal accounts excluded.
+4 + display_name: Activated accounts
+5 + domain_path: product/activation
+6 + expression: COUNT(DISTINCT "ACCOUNT_ID")
+7 + filters: '"STATUS" = ''succeeded'' AND "IS_INTERNAL" = FALSE'
+8 + name: activated_accounts
+9 + synonyms:
+10 + - activated accounts
+11 + - activated customers
+12 + table_name: FIRST_DEPLOYMENT
+13 + table_schema: PRODUCT
+14 + unit: accounts
✓ cassis context check 35 files valid · schema references resolve
✓ cassis eval run 12/12 passed · month boundaries · retries · internal accounts
● CODEOWNERS review Review requested from @activation-data
→ On merge published · the next "activated accounts" answer uses this definition version 12

The repository above is a specimen. Browse a real context repo on GitHub, CI gates included.

Where it fits

One approved version for every agent you run

The context lives in your Git repository, not inside a warehouse or one assistant. Every agent you run reads it through Cassis over MCP, so they all get the same approved version, and a gap exposed by any agent's question comes back to your team.

Data platforms
WarehousesLakehouses
Modeling
dbtSemantic layers
BI and documentation
BICatalogsDocs
Your Git repository
Cassis web app
Conversational interface
AI clients
Claude CodeCodexDust
Agents and workflows
SlackAnalytics agents
Get started

How it works

  1. 01

    Connect your environment

    Connect Cassis to your Git repository and install the Cassis CLI. Then give it your schema: a scoped read-only warehouse connection, or a DDL dump if you would rather not connect one yet.

  2. 02

    Bootstrap your context

    Run the bootstrap from your coding agent. Cassis writes the first context tree to your repository from your schema, dbt project, BI exports, query history, and docs.

  3. 03

    Serve it over MCP

    Connect Claude Code or any MCP-compatible agent. Cassis can answer questions, generate SQL, or return only the context the calling agent needs.

  4. 04

    Maintain it in your workflow

    List detected issues from your development environment, apply and test proposed fixes, then merge the approved pull request to publish a new context version.

Security

Choose your security posture

Data access

Metadata only

No warehouse connection

Cassis uses your schema, dbt project, documentation, and questions. Your warehouse or existing agent executes the generated SQL. Row data stays in your environment. Evals score by SQL equivalence review.

Scoped warehouse access

Selected datasets only

Cassis executes generated SQL through a dedicated read-only role. Access is limited to the datasets your agents use, with no warehouse writes. Evals execute the generated and expected SQL and compare result rows.

Hosting

Cassis-managed

Hosted by Cassis

Hosted on AWS in Paris, in the eu-west-3 region.

Cloud-prem

Available on request

A Cassis-managed private deployment in your own cloud environment.

Inference

Managed inference

Anthropic through Bedrock

Cassis manages Anthropic inference through Amazon Bedrock.

BYOK Bedrock or Vertex AI

Your own account

Use your Amazon Bedrock or Google Vertex AI account.

Connecting your own warehouse starts with a conversation. One domain's schema is enough, as a read-only connection string or a DDL dump. Talk to us.

Get your data ready for analytics agents, and keep it that way

Bring one domain and we'll go through it with you: what your agent would get wrong today, which definitions your team has never settled, and what keeping them current takes.