Under the Hood: grounding CoWork with Cortex Sense — not just prompting it
Your agent isn't wrong because your data is dirty. It's wrong because it doesn't know what your data means. An LLM can read your schema perfectly — table names, column types, row counts — and still have no idea that net revenue means gross revenue after discounts, that the fiscal year starts in February, or that "active customer" excludes anyone who churned last quarter. That gap between the schema an agent sees and the business meaning it doesn't is where confident, wrong answers come from. Closing it is now the single highest-leverage thing a data team can do for AI.
That's also the thesis Snowflake built its entire Summit 2026 agentic story around.
What actually changed at Summit 2026
Two things matter for anyone running agents on Snowflake:
Snowflake Intelligence is now CoWork. Same product lineage — the personal work agent that decomposes a question, researches across structured and unstructured data, and returns a cited answer — new name. If you saw Episode 3, this is the thing you already built against. Existing deployments migrate automatically.
Cortex Sense is the headline, and it's about accuracy, not features. Cortex Sense is a runtime context-enrichment layer: it automatically assembles business context — query history, object metadata, BI dashboards, and Horizon Context semantic views — and feeds it to CoWork and CoCo at query time, with no manual configuration. Snowflake's own internal benchmark puts the difference starkly: 47% accuracy on complex enterprise queries without it, 83% with it— and just 23% for frontier coding agents wired up through Snowflake's MCP connector alone. The message Snowflake is sending could not be clearer: context, not the model, determines agent quality.
We agree with that framing. But there are two catches, and they're exactly where a data team's real work lives.
The two catches nobody puts on the keynote slide
Catch #1 — Cortex Sense is private preview (as of June 2026). CoWork is shipping to enterprises now; Cortex Sense is not generally available yet. So the default CoWork deployment today operates closer to that 47% baseline, withoutSnowflake's own context infrastructure at production readiness. You can't wait for the feature to flip on and rescue answer quality before your stakeholders start trusting (or distrusting) the agent.
Catch #2 — even at GA, Cortex Sense is only as good as what's underneath it. Read the description again: it assembles context from your semantic views, metadata, and dashboards. If those definitions are missing, ambiguous, or contradictory, Cortex Sense faithfully assembles ambiguous context. And there's a deeper trap that governance alone never solves: access control is not correctness. RBAC enforces who can query the revenue table; it says nothing about whether that table is accurate, consistently defined, or current. An agent querying a revenue figure with an upstream ingestion error will return a confident, beautifully-cited, wrong number — and every guardrail will have done its job.
So the work is the same whether Cortex Sense is in preview or GA: you build the governed context layer and you make sure the data beneath it is actually right. The good news is that this work is not throwaway — the semantic layer you build now is precisely the substrate Cortex Sense consumes later. You're not waiting for the feature; you're getting ahead of it.
Here's how we build it.
Under the Hood: the context layer, step by step
Step 1 — Put the business definitions in a governed semantic view
A semantic view is a schema-level Snowflake object that maps physical columns to business concepts — facts, dimensions, and metrics — and stores the definitions natively, under RBAC, where both Cortex Analyst and (eventually) Cortex Sense read them. This is where you kill ambiguity once, centrally, instead of in fifty different dashboards.
The canonical example is the one Snowflake itself uses: revenue is physically stored in a column called amt_ttl_pre_dsc, but the business always means gross revenue after discounts. You encode that once:
CREATE OR REPLACE SEMANTIC VIEW analytics.sales.revenue_model
TABLES (
orders AS prod.sales.orders
PRIMARY KEY (order_id)
WITH SYNONYMS ('sales', 'bookings')
COMMENT = 'One row per order line. Source of truth for revenue.',
unit AS prod.sales.business_unit_dim
PRIMARY KEY (unit_id)
)
RELATIONSHIPS (
orders_to_unit AS orders (unit_id) REFERENCES unit (unit_id)
)
FACTS (
orders.gross_amount AS amt_ttl_pre_dsc,
orders.discount_rate AS disc_rate
)
DIMENSIONS (
unit.unit_name AS unit_name WITH SYNONYMS ('business unit', 'segment'),
orders.order_date AS order_dt
)
METRICS (
orders.net_revenue AS SUM(orders.gross_amount * (1 - orders.discount_rate))
COMMENT = 'Net revenue = gross revenue after discounts. Use this for ALL
revenue reporting. Never sum amt_ttl_pre_dsc directly.'
)
COMMENT = 'Governed revenue model. These definitions are the single source
of truth for agents and BI alike.';
Now anyone — human or agent — asks the question the same way and gets the same number:
SELECT * FROM SEMANTIC_VIEW (
analytics.sales.revenue_model
METRICS net_revenue
DIMENSIONS unit_name
);
Step 2 — Write your comments like prompts, because they are
This is the part that separates "it compiles" from "the agent is actually right." In a semantic view, Cortex Analyst reads your COMMENT text as instructions, not documentation. The comment on net_revenue above isn't a note for a future engineer — it's telling the model which column is not revenue. Be that explicit everywhere: define what a metric means, when to use it, and what to avoid. If you don't write it down, the model guesses, and a guess is how you get a wrong answer on clean data.
Two more high-leverage moves on the same object:
- Synonyms so "business unit," "segment," and "BU" all resolve to one dimension. Agents fail constantly on vocabulary mismatch; this fixes it cheaply.
- Verified queries — known-good question/SQL pairs that anchor the model on your hardest or most political metrics:
-- inside CREATE SEMANTIC VIEW, after the COMMENT clause:
AI_VERIFIED_QUERIES (
net_rev_by_unit AS (
QUESTION 'What was net revenue by business unit last quarter?'
VERIFIED_AT 1717200000
VERIFIED_BY '(owner = data-platform@yourco.com)'
SQL 'SELECT * FROM SEMANTIC_VIEW (analytics.sales.revenue_model
METRICS net_revenue DIMENSIONS unit_name)'
)
);
One discipline worth stating plainly: only add verified queries you have actually validated. One wrong example teaches the model a bad habit at scale.
Step 3 — Measure the lift on your KPIs, don't take 47→83 on faith
Snowflake's benchmark is theirs, on their data. Before you tell your CFO the agent is trustworthy, prove it on your questions. Snowflake ships a Cortex Agent evaluation framework for exactly this — define a dataset of real questions with expected answers, then score the agent against it:
evaluation:
agent_params:
agent_name: "revenue_agent"
agent_type: "CORTEX AGENT"
run_params:
label: "Baseline — before semantic layer"
source_metadata:
type: "dataset"
dataset_name: "kpi_eval_set"
metrics:
- answer_correctness # how close the answer is to ground truth
- tool_selection_accuracy # did it call the right tools? (public preview)
- logical_consistency # reference-free; consistency across the run
Run it once before the semantic layer exists, run it again after. The delta is your evidence — and your regression test. Wire it into CI so a careless change to a metric definition can't silently re-break answer quality next month.
Step 4 — Fix the data the context layer points at
A perfect semantic layer over a stale or half-loaded table still produces a wrong answer, just a well-defined one. So the context work has a twin: source-to-report reconciliation, freshness checks, and catching the broken or partial feeds that quietly poison a metric. That's a whole topic — it's Episode 5 — but flag it now, because "the agent gave the wrong number" is at least as often an ingestion problem as a semantics problem.
What this means, by role
If you lead data or analytics: the semantic layer is no longer a BI nicety — it's the accuracy substrate for every agent you're about to be asked to deploy. Building it now pays twice: better Cortex Analyst answers today, and a ready-made context source for Cortex Sense when it GAs.
If you're the architect or lead engineer: treat semantic views as strict contracts, not flexible SQL. Model relationships explicitly, comment like you're prompting, anchor hard metrics with verified queries, and put an evaluation set in CI. This is the build work that makes the demo survive contact with production.
If you own the platform strategy (VP / CDO): the question your stakeholders are really asking is "can we trust this for a real decision?" The honest answer is "only as far as our governed definitions and our data quality go." That's a roadmap, not a blocker — and it's a far better place to invest than another model evaluation.
How we'd approach it
Most teams we talk to don't have a context problem they can see — they have a trust problem they can feel: two dashboards disagree, an agent answer doesn't match the board deck, nobody's quite sure which number is right. The fix starts with finding where the definitions diverge and where the data underneath is wrong, before pointing any agent at it.
That's the shape of our AI-readiness assessment — a fixed-scope first step that maps your sources, definitions, and the gaps between what your reports say and what your data actually contains, so the agents you ship are accurate by construction. If your CoWork answers are landing in the "confident but wrong" zone, that's the place to start.
Notes & sources: Cortex Sense status and the 47%→83% figure are from Snowflake's own materials and product announcements (Snowflake Summit 2026, June 2); Cortex Sense is in private preview as of June 2026, so treat the figure as a vendor benchmark and validate on your own data. Semantic-view DDL and the comment-as-instruction behavior follow Snowflake's CREATE SEMANTIC VIEW and semantic-view documentation; semantic-view SQL is stricter than ordinary SQL, so validate any DDL against current docs for your account version. Cortex Agent evaluation metrics (answer correctness, tool-selection accuracy, logical consistency) are from Snowflake's Cortex Agent evaluations documentation.
