Agents don't need your data warehouse. They need your definitions.

By Ben Wilson, [TITLE: Principal Consultant at phData?]. Views are my own.

Ask one artificial intelligence (AI) agent the same question twice and you can get two different numbers, both defensible, neither labeled. Connecting agents straight to your source systems is easy now. Agreeing on what your numbers mean is still the hard part.

Say a regional health system (a hypothetical one) gives its leaders an AI agent with connectors into the electronic health record (EHR) and the claims system.

On Monday, the Chief Financial Officer (CFO) asks, "What was our 30-day readmission rate last quarter?" The agent reads the EHR, counts every return admission within 30 days of discharge, and answers 14.8%.

On Thursday, the quality director asks the same agent the same question. This time it reads claims data, drops planned readmissions such as scheduled chemotherapy, and answers 12.1%. (Hypothetical example, invented numbers.)

Neither answer is wrong. The Centers for Medicare & Medicaid Services (CMS) scores hospitals on "condition- or procedure-specific," risk-standardized, unplanned 30-day readmissions. That is one valid definition among several. The problem is that the agent picked a definition on each request, and nobody saw it pick. The CFO and the quality director now walk into the same meeting with two numbers.

[BEN: one or two sentences from your own non-client experience: personal, or a public example. A time you saw two dashboards, two reports, or two prompts disagree on one metric. Nothing from a past client or employer engagement.]

Why connectors are so appealing

The case for skipping the warehouse is real.

Model providers now ship connectors that let an agent reach source systems on demand. Anthropic's Claude, for example, can call remote Model Context Protocol (MCP) servers through its MCP connector (in beta). MCP is the open standard that lets an agent use another system's tools. If the agent can read the EHR, the customer relationship management (CRM) system, and the claims platform directly, why copy that data anywhere? You skip a pipeline and a sync delay, and the data is never copied into a warehouse. (It still passes through the model provider, which matters for patient data.)

For a single lookup ("what's this patient's next appointment?"), that argument wins. For a metric a leader will act on, it breaks in four places.

Where it breaks

1. Consistency. A metric is a decision about numerators, denominators, exclusions, and time windows. When an agent rebuilds that decision on each request, you get one definition per prompt. You want one definition, written down once, that every agent and every dashboard uses.

2. History. Source systems mostly hold current state. "Readmissions by quarter for two years, by discharge unit" needs snapshots of what was true then. A source system often doesn't keep those snapshots, and an application programming interface (API) call can't rebuild them.

3. Cross-system joins. The useful questions cross source systems: claims plus EHR plus CRM in one answer. Doing that through three live API crawls per request is slow, and it puts a join that needs careful patient matching into a prompt.

4. Governance. Who may see what, and what did the agent touch? With protected health information (PHI), this one decides the whole question. A connector that runs on a broad service account can read more than the person asking could.

What to invest in

My read is that the defensible layer is not storage. It is the meaning and the rules on top of it. Three investments come before buying more agents:

• Semantic definitions. Write the metric down as an object the agent uses. On Snowflake, a semantic view stores logical tables, facts, dimensions, metrics, and relationships in the database. Cortex Agents use semantic views to turn a question into Structured Query Language (SQL), so both askers start from one written definition.
• Access policy. Put the rules on the data, so they apply to every caller. Snowflake's Horizon Catalog covers sensitive-data classification, masking policies, row access policies, and access history, all enforced through role-based access control (RBAC).
• Agent identity. Know when an agent is the one asking. Snowflake's agent identity feature handles two cases. When an agent acts on a user's behalf, Snowflake marks the session as agent-driven and the audit trail names both the agent type and the user. An autonomous agent gets its own SERVICE_AGENT user and acts under its own identity. Either way, a masking or row access policy can check whether an agent is the one asking. A connector on an ordinary service account gets neither treatment, which is the gap in point 4. Snowflake also put Cortex AI Gateway in preview on Sep 15, 2026, as one place to grant model access and trace AI activity.

None of this is Snowflake-only as an idea. Any platform should answer three questions: what does this metric mean, who may see it, and which agent asked.

[BEN: what you built or tested for this. For example, a small semantic view over public or synthetic data, two agent prompts, and the before/after. Even one screenshot turns this from opinion into build-in-public.]

The bear case

The strongest objection has two parts. First, the model providers could build the semantic layer themselves, with memory and a shared ontology on their side. Second, a good agent can already state the definition it used and ask which one you meant. Many semantic-layer projects stall in committee, so why not let the agent ask?

Both points are fair. An agent that shows its definition beats one that picks silently, and if your semantic-layer project has stalled, start there. But asking on each request moves the decision to whoever is asking. The CFO and the quality director can still choose differently and still walk in with two numbers. Writing the definition down forces the agreement once. The stall usually comes from trying to define everything, so start with the five metrics leaders act on.

And a definition that lives inside one provider's agent is one your other agents, dashboards, and auditors can't read. For a regulated metric, I want it somewhere I control.

I hold this view with moderate confidence. [BEN: your own confidence level and what evidence would change your mind.]

Your turn

Which metric in your organization has two definitions today, and which one would your agent pick?

If you want the next build note, where I [BEN: name the next thing you're building], subscribe below.

LinkedIn cut (~180 words, link in first comment)

One AI agent. Same question, asked twice. Two answers.

"What was our 30-day readmission rate last quarter?"

Monday, the agent reads the electronic health record (EHR) and counts every return admission: 14.8%. Thursday, it reads claims and drops planned readmissions: 12.1%.

(Hypothetical example, invented numbers.)

Both are defensible. Neither is labeled. The Chief Financial Officer (CFO) and the quality director now bring different numbers to the same meeting.

Connectors that let agents read source systems directly are a real step forward. For one lookup, they're great. For a metric a leader acts on, they break in four places:

1. Consistency: one definition per prompt
2. History: source systems hold current state
3. Cross-system joins: claims + EHR + customer relationship management (CRM) in one answer
4. Governance: with patient data, this decides everything

So before buying more agents, I'd invest in three things: written metric definitions, access policy on the data itself, and an identity for each agent.

Which metric in your org has two definitions today?

Full write-up, including the bear case, in the first comment.

Ben to decide

1. Anecdote slot (hook section): a real moment when two numbers disagreed on one metric. Generic framing only, no client detail.
2. Build slot: what you actually built for this piece. As written, it is a thesis post wearing build-in-public clothes. One small public or synthetic-data demo would fix that and fit the "what I built, what broke, what's next" target.
3. Snowflake density: the "What to invest in" section names five Snowflake features. Keep (signals the Snowflake + AI identity) or trim to one line per bullet so it reads less like product copy.
4. Cortex AI Gateway: it is in preview. Keep the mention, or drop it until general availability.
5. Bear-case confidence line: your own words on how sure you are.
6. Title: keep the v0 title, or test "One agent, two readmission rates" (more concrete, less contrarian).
7. Byline and employer disclosure: confirm the title in the byline ([TITLE: Principal Consultant at phData?], matching your public LinkedIn), and whether phData's social policy needs the "views are my own" line, or different wording, on the site and the post.
8. LinkedIn link placement: the Welsh note cites a vendor claim that link-in-first-comment is also penalized. Alternative: point to the Featured section instead.
9. Closing CTA: subscribe line depends on the Resend list being live at launch.