Skip to content

Your AI agent has your data. Not your context. Sigil fixes that.

Three revenue columns. Undocumented joins. Fiscal quarters that start in February. Without business context, every answer looks right but isn’t.
Get started free
No credit card. 2-min setup.
Claude
Hey Sigil, what's our monthly churn rate and how is it trending?
Used 3 integrations, loaded tools
Logo churn: 3.2% in July, down from 4.1% in June. 3-month trend: improving.
Excludes trial-only accounts (never converted). Paused subscriptions held for 90 days before counting as churned. Active = subscription_status 'active' AND mrr > 0.
The problem

Your agent returns clean results. They're still wrong.

It does not know which of your three “revenue” columns is canonical, that fiscal quarters start in February, or that the customers table includes churned accounts unless you filter by status. No error. No crash. Just confident wrong answers that feed bad decisions.

“81.2% of text-to-SQL failures stem from schema and semantic misunderstanding, not syntax errors.”

Atlan Research, 2026
Scenario: “How many active customers do we have?”
Without context
-- Agent generates a reasonable-looking query
SELECT COUNT(*) FROM customers;

-- Result:
4,847
-- Looks right. Ships to the board deck.
✗ Included 1,208 churned accounts (status = ‘churned’)
✗ Included 94 internal/test accounts (is_internal = true)
✗ Included 2,342 pre-migration records from before Jan 2024
With Sigil context
-- Agent reads context records first, then generates:
SELECT COUNT(*)
FROM customers
WHERE status = ‘active’
  AND is_internal = false
  AND created_at > ‘2024-01-01’;

-- Result:
1,203
-- Matches the data team’s known-correct count.
Context records that informed the correct query
METRIC DEFINITION
name: active_customers
formula: COUNT(*) FROM customers
         WHERE status = ‘active’
         AND is_internal = false
note: “Only post-migration data (Jan 2024+) is reliable”
EXCLUSION RULE
applies_to: all customer metrics
exclude_when: is_internal = true
reason: “94 internal QA and demo accounts”
KNOWN GOTCHA
table: customers
warning: “Pre-2024 records were bulk-imported from legacy system.
created_at, status, and plan_type are unreliable.
Always filter created_at > ‘2024-01-01’”
Get started free
No credit card. 2-min setup.
Sigil was built in production at a $13M B2B SaaS company and deployed company-wide as the primary self-service analytics tool. The database playbooks extend that proven context model to warehouse sources.
What it fixes

Four problems. One context layer.

Ad-hoc request overload

Half of inbound data requests are repeats. AI agents can answer them if they know which tables to query, which filters to apply, and what “active customer” actually means.

Metric disagreements

Three teams query the same database and get three different numbers. Without governed definitions, agents pick whichever column seems most plausible.

Tribal knowledge loss

Your schema has 847 tables. Why are there three “revenue” columns? Which one is canonical? That knowledge lives in one person's head. Sigil makes it queryable.

Schema complexity

Cryptic column names, implicit join logic, near-duplicate migration tables. Dumping the schema into the agent's context doesn't help. Structured definitions do.

The context model

The context your agent is missing.

Sigil stores structured business context alongside your data tools, not in them. Four types.
{ metrics }

Metric definitions

The canonical formula for every metric your company tracks. Without this, the agent guesses. “Active users” could mean 30-day logins, 7-day events, or accounts with status = ‘active’.
metric: monthly_active_users
formula: COUNT(DISTINCT user_id)
         WHERE last_event_at > NOW() - INTERVAL 30 DAY
exclude: internal_users, test_accounts
source_table: events
{ aliases }

Field aliases

The mapping between what people call things and what the database calls them. Business users say "revenue." The database has gross_amount, net_amount_usd, amount_local_currency, and mrr_amount.
alias: “revenue”
maps_to: orders.net_amount_usd
note: “NOT gross_amount. Always use net_amount_usd.”
alias: “signup date”
maps_to: users.confirmed_at
note: “NOT created_at. That’s row insertion, not confirmation.”
{ exclusions }

Exclusion rules

The filters that must always be applied. Every company has records that should not be counted: test accounts, internal users, pre-migration data, sandbox environments.
exclude_when: account.is_internal = true
reason: “94 internal QA and demo accounts”
exclude_when: created_at < ‘2024-01-01’
reason: “Pre-migration data is unreliable”
applies_to: all customer metrics
{ gotchas }

Known gotchas

The warnings that save hours of debugging. The things a senior analyst would tell a new hire on day one. They live in people’s heads and in painful board-meeting memories.
warning: “The ‘users’ table includes deleted accounts.
Always join on users.status = ‘active’”
warning: “revenue_monthly is a snapshot, not real-time.
For current revenue, use SUM(orders.net_amount_usd)”
warning: “fiscal_quarter != calendar_quarter. FY starts Feb 1.”
Guided setup per table. No code, no schema files.
How it fits

Sits alongside your data tools, not inside them.

Your agent already connects to your data tools. It can read schemas, run queries, pull events, and return results. What it cannot do is interpret those results in the context of your business.
Your data tools

Raw data access

BigQuery, Snowflake, Postgres, Stripe, PostHog, and more. Schemas, queries, events, and results exposed to your agent as-is.

Sigil

Business context

Metric definitions, field aliases, exclusion rules, known gotchas. The structured definitions that turn raw data access into correct answers.

Your AI agent

Accurate answers

Correct filters. Right columns. Right exclusions. Trusted results that match what your data team would produce.

Result
Your agent queries with the right columns, the right filters, and the right formulas, across every data tool.
Unlike dbt Semantic Layer or Cube, Sigil does not require a transformation layer. It sits alongside your stack, providing context without requiring you to change your schema, your pipelines, or your existing tools.
Your data stays where it is. Sigil stores only your definitions: metric formulas, aliases, exclusion rules, and gotchas. No row-level data. No query results. No credentials.
Supported tools

Works with your entire data stack.

9 database engines with dialect-specific playbooks, plus any other tool your agent connects to.

BigQuery

Cost-aware queries, dataset discovery, partition filtering, UNNEST for arrays, dry-run before expensive queries.

Snowflake

Schema/database hierarchy, credit-conscious warehouse queries, VARIANT/ARRAY handling, SAMPLE-based profiling.

PostgreSQL

Schema-aware table documentation, EXPLAIN-first validation, index-aware join patterns, TIMESTAMPTZ handling.

Databricks

Unity Catalog namespace (catalog.schema.table), backtick quoting, SQL warehouse compute-time cost model.

Amazon Redshift

Postgres-derived schema.table namespace, cluster compute cost model, distribution-key aware query patterns.

Trino

Federated catalog connectors, cross-catalog join cost awareness, schema-level scoping.

ClickHouse

Two-level database.table namespace, case-sensitive identifiers, MergeTree engine awareness.

MySQL

Two-level database.table namespace, backtick quoting, charset/collation-aware context.

DuckDB / MotherDuck

Local + cloud modes, Parquet/CSV source attachment, case-insensitive matching, read-only enforcement.

StripePostHogMixpanelSegment+ any tool
See all integrations →
Common questions

Questions from data teams.

How is this different from dbt Semantic Layer?

Different layers, complementary roles. dbt Semantic Layer defines metric calculations in the transformation layer. Sigil defines business context for AI agents at query time: which columns to use, what to exclude, what the gotchas are. dbt tells the warehouse how to compute a metric. Sigil tells the agent which metric to compute and why. You can use both: Sigil can import metric definitions from your dbt project and enrich them with the business context dbt does not capture.

How is this different from Cube?

Cube is a semantic layer that sits between your application and your database, pre-aggregating data and exposing it through an API. Sigil is a context layer that sits alongside your existing warehouse MCP with no transformation layer, no deployment, and no pre-aggregation. If you already use Cube, Sigil complements it by adding the business context (aliases, gotchas, exclusions) that Cube's metric definitions do not capture.

How is this different from a data catalog (Atlan, DataHub, etc.)?

Catalogs describe. Sigil computes. A data catalog documents that a column exists, who owns it, and when it was last updated. Sigil tells the agent which column to use, how to calculate the metric, what to exclude, and what will go wrong if it ignores the gotchas. Catalogs are reference documents for humans. Sigil is structured context for agents.

Does Sigil require a data warehouse?

No. Sigil works with any database that has an MCP server: BigQuery, Snowflake, Postgres, MySQL, and five more. It also works with CRM and operational tools (HubSpot, Gong) directly. You do not need a warehouse, a transformation layer, or a semantic layer to use Sigil.

Can I use this with dbt?

Yes. Sigil can import metric definitions from your dbt project and enrich them with business context that dbt does not capture: gotchas, aliases, temporal caveats, and exclusion rules. If you have already defined metrics in dbt, Sigil makes that work accessible to AI agents and business users who cannot use dbt directly.

Does Sigil access my data?

No. Sigil stores only your definitions: metric formulas, aliases, exclusion rules, and gotchas. Your data stays in your warehouse. Sigil never sees your query results, your row-level data, or your database credentials.

How long does setup take?

Sigil's onboarding flow walks you through each table: fields, aliases, joins, gotchas, and the metrics that depend on it. A focused analytics schema of 10-15 key tables typically takes a few hours across one or two sessions.

We already have documentation. Why do we need this?

Documentation rots. Confluence pages go stale. dbt YAML files lag behind schema changes. Sigil context records are versioned, queryable by agents at runtime, and structured so the agent can act on them, not just read them.

“Documentation can no longer be a static file rotting in a wiki: it must be a living, versioned asset that agents can query to understand why a pipeline exists or how revenue is calculated.”

Gradient Flow

Same metric. Same answer. Every tool.

Structured context for every data source, every metric, every definition. Guided setup. No code.

GET STARTED FREELOG IN
Free to start. No credit card. Works with 50 fields or 50,000.