Healthtech SaaS Series B · ~150 employees Ongoing retainer

An ops agent that answers questions from live warehouse data — without ever seeing a patient record

12 semantic views shipped~4 hrs/week back per analyst0 PHI columns exposed to the modelOngoing retainer

Where they were

Three analysts served a forty-person operations team. Most requests were the same shape: “how many onboardings stalled this week, and where?” Each one was a Slack thread, a query, a screenshot, and forty minutes. The analysts were a queue, and the queue was growing faster than the team.

Leadership had tried a “chat with your data” tool. It wrote plausible SQL against raw tables, got a join wrong on the second day, and the compliance lead shut it down — rightly. This is a healthcare company. Raw tables contain patient data.

What was actually hard

The obvious fix — point a model at the warehouse — is exactly the thing that cannot happen here. The real requirements were:

  • The model must never receive a patient identifier, in a prompt, a result, or an error message.
  • Answers must use the same definitions the analysts use. “Stalled onboarding” has a precise meaning, and a model guessing at it is worse than no answer.
  • Ops people will ask questions nobody anticipated. Hard-coded queries don’t survive contact with a real team.

What we did

We built the governed layer first and the agent second.

  1. Semantic views in Snowflake — twelve of them, one per operational domain (onboardings, tickets, SLAs, staffing, and so on). Each view defines its metrics, dimensions, and joins once; each is built on dbt models that have already removed or tokenised every PHI column. The views are the only objects the agent’s role can read.
  2. An MCP server that exposes the semantic views as tools. The model sees metric names and descriptions, not tables. It composes a question; Snowflake composes the SQL. Row-level access follows the user’s own Snowflake role, so an ops lead and a contractor get different answers to the same question.
  3. Cortex for the last mile — summarising result sets into a sentence and flagging when a question falls outside what the views can answer, instead of improvising.

The compliance review took one meeting. The argument was simple: here is the role, here is everything it can see, and none of it is PHI.

What changed

  • 12 semantic views in production, covering about 80% of the questions the analysts used to field.
  • ~4 hours a week back per analyst, now spent on the questions that actually need a human.
  • 0 PHI columns reachable by the model — enforced by Snowflake grants, not by prompt instructions.

Why it’s a retainer

Every month the ops team asks something the views can’t answer yet. We add the metric, test it, and ship it. The agent gets more useful, and the definitions stay in one place.

Representative engagement — details anonymized and generalised.

Stack used SnowflakeSemantic viewsMCPCortexdbt
Timeline 6 weeks to first agent, then ongoing
// READY TO TALK?

Got a similar problem? Tell us about it.

Email or WhatsApp us. No pitch, no commitment. We'll tell you straight if we can help.