Cut agent token spend with a governed semantic layer
Agent token spend climbs when every question starts from scratch. Data Workers has agents read one governed definition per metric instead of rediscovering the schema each time, sends each task only the context it needs, and reports usage and cost per agent and per action.
Before and after
| Today | With Data Workers |
|---|---|
| Agents re-read the schema and try several queries on every question | Agents read one governed definition and go straight to the answer |
| "Revenue" defined three ways, so the agent picks one and is sometimes wrong | One definition with a named owner; conflicts are surfaced, not guessed |
| Every question carries a pile of tables the agent might need | Each task gets only the context it needs |
| A model bill nobody can break down by team or task | Usage and cost reported per agent and per action |
| A spike you find on the invoice | An alert when an agent's usage leaves its normal range |
Agent token spend grows fastest where agents have no shared definitions: each question means re-reading tables, choosing between competing versions of a metric and running again when the first answer looks off. A governed semantic layer removes that rework and the wrong answers that come with it. Context bloat and multi-agent token cost describe the problem; this page is the operating model that fixes it. If you have no governed set yet, start with build your semantic layer.
How it works
1. Give agents the definitions to read
The Data Context & Catalog agent lists the definitions you already keep, such as dbt MetricFlow, with list_semantic_definitions, and marks the trusted source for each metric with get_authoritative_source. Where two definitions disagree it says so and drafts one with define_business_rule for the metric's owner to approve. Nothing is rewritten into a new tool.
2. Answer from the definition, not the schema
Agents resolve the metric with resolve_metric before they write raw SQL, and get_table_schema_for_sql supplies the schema for the task at hand. The agent stops re-deriving what "revenue" means and stops loading every table in sight, so each question carries less context and needs fewer retries. When the data is missing, it says so instead of guessing, as covered in how agents avoid hallucinating on your data.
3. Watch what the agents spend
The Usage Intelligence agent reports usage and cost per agent and per action with get_cost_enrichment, and flags an agent whose usage leaves its normal range with detect_usage_anomalies. Finance sees which questions the spend buys; the platform team sees where agents still have to dig.
The impact metrics we move
- •Conflicting definition settled: from about a month to 8 h
- •Agent usage report by team and task: from about a week to 1 h
- •Wrong answer traced to its definition: from about a day to ~10 min
Where teams start
- •The five metrics your agents are asked about most. Revenue, active customers, churn, margin and pipeline, each with one owner.
- •dbt MetricFlow, Cube or a BI-tool model. Bring the definitions you already run and point the agents at them first.
- •Agent traffic on your warehouse. Where repeated exploratory queries add up on Snowflake, Databricks or BigQuery; see reducing Snowflake credits from agent queries.
- •One team's agent bill. Start usage and cost reporting for a single domain's agents and read it against a baseline.
What powers it
The Data Context Wizard keeps the shared understanding of your estate: what each table means, who owns it and which source is the trusted one. The Data-Agents Swarm does the work, with the Data Context & Catalog agent serving definitions, the Data Science & Insights agent answering from them and the Usage Intelligence agent reporting what it all costs. The Autonomous Data-Conductor routes each proposed definition to its owner, Autopilot Routines flag stale context and documentation gaps as they appear, and Autopilot Standards can hold every domain to a rule such as "every metric has an owner". Background: grounding LLM analytics in a semantic layer. See it in practice in AI cost management, semantic layer and governed context and AI and ML platform data teams.
The climb: from assisted to autonomous to agentic
Every transformation runs on the same ladder from our thesis. Today agents watch (L0), suggest (L1) and act after approval (L2), and each domain's owner decides how far to go. L3 and L4 are where a domain can go on its own review record, not something running now.
The pilot
- •Scope. The governed definitions for one domain, such as revenue and customer metrics, and the agents or assistants that query them.
- •First week. Agents start by watching and suggesting: they list every definition, show the conflicts and report current agent usage per action, with receipts. That is your baseline.
- •By week two. The first definitions are approved by their owners and served to the agents you chose; anything sensitive stays with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Conflicting definition settled: from about a month to 8 h
- •Agent usage report by team and task: from about a week to 1 h
- •Wrong answer traced to its definition: from about a day to ~10 min
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Will this lower our model bill? Agents get only the context a task needs, so there is less to read and fewer retries. You can check it yourself: usage and cost are reported per agent and per action, against your week-one baseline. We do not quote a savings percentage.
Do we have to replace our semantic layer? No. Agents read the definitions you already keep, for example in dbt MetricFlow, and flag where they disagree.
Does Data Workers charge by token? No. Pricing is published tiers with unlimited seats, no usage meter and no markup on model spend. You bring your own model.
What if the agent is wrong? Answers show their source, SQL is checked against the warehouse before it runs, and corrections people make are remembered so the same wrong answer does not come back.