7 Things to Know About Snowflake Support Partners

The first two episodes of True North showed Snowflake Intelligence from the front: plain-English questions, instant charts, and a contract workflow completed in a single conversation. Impressive, but if you are a developer or architect, the question that matters is different. Can I build with this, or am I locked into a chat window?

Episode 3 answers that. Everything you see in the chat interface is available programmatically through Snowflake's Cortex REST API. That means you can embed the same intelligence in your own products, internal tools, and automated workflows, with full visibility into how every answer is produced.

A note on naming: at Snowflake Summit 2026, Snowflake Intelligence was renamed CoWork. The demo was recorded under the original name. The API patterns shown apply to CoWork and the Cortex Agents it runs on. For what changed at Summit, read why your Snowflake agents give wrong answers on good data.

Key takeaways

• Every capability in the Snowflake Intelligence (now CoWork) interface is accessible through the Cortex REST API.
• Conversation threads are first-class API objects, so multi-turn context works in your own applications.
• Agent requests are structured JSON, including which tools the agent may use, which lets you enforce boundaries in code.
• Responses expose the full reasoning trace: generated SQL, the thinking chain, the chart specification, and the final answer.
• The Agents panel in Snowflake gives admins a live view of every session and execution step.

Watch the demo

From the chat interface to the API

For this episode we used Insomnia, a REST API client, to call Snowflake directly. No custom application, no SDK wrapper, just HTTP requests against your account. That is deliberate: if you can do it in Insomnia, you can do it from any backend, workflow engine, or integration platform your team already runs.

What we demonstrated

1. Listing and creating conversation threads

The chat interface remembers what you asked, what came back, and what actions were taken. At the API level, that memory is a thread. We listed existing threads and created new ones, treating them as first-class objects. For developers, this is the foundation for any multi-turn experience: a patient services portal, an internal operations assistant, or an automated renewal flow that needs context across several steps.

2. Sending agent prompts with tool constraints in structured JSON

A request to the agent is not just a text string. It is a structured JSON payload carrying the prompt, the thread it belongs to, and the tools the agent is allowed to use. That last part matters in healthcare. You might allow read-only analytics in a member-facing tool while reserving write actions, like the contract generation in Episode 2, for an internal workflow with tighter controls. Tool constraints let you express those boundaries in code, on top of the Snowflake roles and policies already governing the data.

3. Inspecting the full reasoning trace

This is the part that resonates most with technical teams. The API response does not just return an answer. It returns the steps behind it: the SQL the agent generated, the thinking chain it followed, the chart specification it built before rendering, and the final answer composed from all of it. That is real observability. You can see not only what the agent said, but how and why. For applications where auditability is non-negotiable, this is a requirement, and it comes natively at the API level with no extra instrumentation.

4. Monitoring sessions from the Agents panel

Finally, we switched to the Agents panel in Snowflake, where every session, prompt, and execution step is visible in one place. When agents run across multiple teams and applications, this is how data and IT leaders keep oversight: what ran, when, under which role, and with what outcome.

What this unlocks for builders

Episodes 1 and 2 made the case for business users. Episode 3 makes the case for builders. Each capability shown in the interface becomes a building block you can compose:

• A patient or member portal that answers coverage questions in plain English, restricted to read-only tools.
• An automated contract renewal flow triggered by expiration events, with a human approval step before any document is issued.
• An internal operations tool that surfaces service gaps weekly and posts ranked recommendations to the teams that own them.
• Evaluation pipelines that replay known questions and compare generated SQL and answers against expected results before each release.

Because everything runs inside Snowflake, you inherit the security, governance, and compliance controls you already rely on. You are extending a platform you trust, not adding a new data path to secure.

Production checklist for healthcare teams

Moving from a demo to production is mostly about the layers around the agent:

• Accurate definitions. A governed semantic layer so every metric means the same thing to every agent and every user. This is the core of AI-Ready Data Governance.
• Scoped identity and tools. Dedicated roles per use case, least-privilege grants, and tool constraints that match each workflow's risk.
• Evaluation before trust. A set of known questions with expected answers, run against every change to the semantic model or agent configuration.
• Ongoing ownership. Someone has to keep definitions, permissions, and quality checks current as the business changes. That is what Platform Team as a Service covers.

Where to start

If you are planning to embed Snowflake agents in a product or workflow, the fastest safe start is a fixed-scope assessment through our Snowflake consulting practice. We review your data, definitions, and access model, identify which use cases are ready, and design the guardrails before you build. If the platform needs groundwork first, we deliver it as an AI-Ready Snowflake Platform. For industry context, see our Healthcare & Pharma page.

The full healthcare series

Episode 1: ask your patient data questions in plain English. Business users get instant, visualized answers with no SQL.

Episode 2: from expired contract to signed PDF in one conversation. The agent executes a real workflow, not just a query.

Episode 3: everything is programmable, with full tool control, reasoning transparency, and operational oversight.

Analytics tells you what is happening. In healthcare operations, the expensive part is what happens next. A contracts manager spots a batch of expired UnitedHealthcare contracts. Someone pulls the patient records. Someone else reviews the service breakdown. A third person drafts a new contract in a separate system, cross-checks the coverage, formats the document, and routes it for approval. One simple insight turns into a multi-day, multi-team process.

Episode 2 of True North, Snowstack's healthcare series on Snowflake Intelligence, asks a different question: what if everything after the insight happened in the same conversation that surfaced it?

A note on naming: at Snowflake Summit 2026, Snowflake Intelligence was renamed CoWork. The demo was recorded under the original name. Everything shown applies to CoWork, and existing deployments migrated automatically.

Key takeaways

• Snowflake Intelligence (now CoWork) can execute workflows, not just answer questions, when it is given the right tools.
• In the demo, one conversation moved from expired contracts, to a single patient's coverage, to 14 unsubscribed services ranked by copay, to a newly generated contract PDF.
• The unsubscribed-services list is effectively a ready-made coverage opportunity list for revenue cycle teams.
• Write actions raise the bar on governance: accurate definitions, scoped permissions, and an audit trail are prerequisites, not extras.
• Humans stay in the loop. The agent removes the mechanical work, not the decision.

Watch the demo

From insight to execution

Episode 1 showed that plain-English questions on governed healthcare data return accurate, visualized answers in seconds. That alone removes a lot of friction. But the bigger gap in most organizations is not between a question and an answer. It is between an answer and the action it should trigger. Analytics happens in one tool, execution in another, and the space in between is filled with emails, spreadsheets, and manual re-keying.

This episode closes that gap end to end.

The demo, step by step

1. Filtering expired UnitedHealthcare contracts by tier and expiration date

The workflow starts with one instruction: show expired UnitedHealthcare contracts, filtered by tier and expiration date. The agent queried the contracts data, applied the filters, and returned a clean list. Normally that is a filtered SQL query or a report that may or may not exist. Here it is a sentence, and it is only the starting point.

2. Reviewing one patient's full active contract and services

From the expired list, we drilled into a single patient: show this patient's full active contract and service breakdown. The agent returned coverage tier, active services, copay values, and contract terms in one readable response. This mirrors how a contracts manager actually thinks: find the problem at the population level, then investigate at the individual level, without switching systems or rewriting a query.

3. Identifying 14 unsubscribed services, ranked by copay

Next, we asked which services this patient was not subscribed to, ranked by copay. The answer: 14 services, highest value first. That is a prioritized coverage opportunity list, showing the services most worth adding to a renewed contract, ordered by revenue impact. A revenue cycle team would usually commission this as separate analysis. Here it emerged mid-conversation as the natural next step.

4. One instruction: create the contract, add services, generate the PDF

Then the step that changes the category. We issued a single instruction to create a new contract for the patient, add the selected services, and generate the legal document. The agent created the contract record, attached the services, and produced a PDF ready for review and signature. From expired contract to new document, without leaving the conversation.

How actions like this work in Snowflake

Querying is only one of the tools an agent can use. In Snowflake, agents can also be given custom tools, such as stored procedures that insert records or render documents, alongside the analytics tooling that turns questions into SQL. The agent decides which tool fits each step, and every tool runs inside your Snowflake account under the role the agent is allowed to use.

That design is what makes write actions safe enough to consider in healthcare. It is also why governance matters more here than anywhere else in the series. An agent that can create a contract must be working from correct coverage data, consistent service definitions, and permissions scoped to exactly what it should touch. That foundation is the work behind AI-Ready Data Governance: source-to-report reconciliation, freshness checks, lineage, and a governed semantic layer, so the agent acts on numbers you would sign off on yourself.

What this means for healthcare operations

• Faster renewals, fewer coverage gaps. Expired contracts are caught and replaced in one sitting instead of drifting for weeks.
• Revenue you can see. Unsubscribed services ranked by copay give revenue cycle teams a concrete, prioritized list to act on.
• Less manual handoff. Querying, cross-referencing, and document generation stop bouncing between teams and tools.
• A clean audit trail. Because every step runs in Snowflake, the queries, actions, and outputs are traceable, which matters for compliance reviews.

None of this removes people from the process. The contracts manager still decides. Clinical and finance teams still review the output. The agent handles the mechanical work that slows them down. For more on how we apply this to providers, payers, and pharma, see our Healthcare & Pharma page.

Where to start

Agents that take action should be scoped carefully: which workflows, which tools, which data, and which approvals. A fixed-scope assessment through our Snowflake consulting practice maps your highest-value workflows, checks whether the underlying data is accurate enough to act on, and defines the guardrails before anything goes live. Once agents are in production, Platform Team as a Service keeps definitions, permissions, and data quality current as your contracts and services change.

The rest of the series

Episode 1: ask your patient data questions in plain English, with automatic charts and no SQL.

Episode 3: building with Snowflake Intelligence through the REST API, with threads, tool constraints, reasoning traces, and admin monitoring.

Every healthcare organization runs on a steady stream of small, operational questions. Which insurance company covers the most patients? Which add-on services carry the highest copay? Which imaging service almost nobody uses, and is that a pricing problem or an access problem? None of these are hard questions. The data to answer them already sits in Snowflake. Yet in most organizations, getting the answer still means writing SQL, hunting for the right dashboard, or opening a ticket and waiting two days.

This post is the written companion to Episode 1 of True North, Snowstack's three-part healthcare series on Snowflake Intelligence. We connected it to a live Patients Management dataset, asked plain-English questions, and recorded exactly what came back.

A note on naming: at Snowflake Summit 2026, Snowflake Intelligence was renamed CoWork. The demo was recorded under the original name. Everything shown applies to CoWork, and existing deployments migrated automatically. For what changed at Summit and why agent accuracy now depends on context, read why your Snowflake agents give wrong answers on good data.

Key takeaways

• Snowflake Intelligence (now CoWork) lets non-technical healthcare teams query governed Snowflake data in plain English, with no SQL and no BI tool in the loop.
• It picks the right visualization on its own: bar charts for comparisons, pie charts for distributions.
• In the demo, insurer coverage, top copay services, and the least-used imaging service were each surfaced in seconds.
• Answer quality depends on the semantic layer underneath. Clean data is not enough; the agent needs consistent business definitions.
• The fastest safe path to production is an assessment of your data, definitions, and governance before rollout.

Watch the demo

What Snowflake Intelligence actually does

It is easy to dismiss this category as a chatbot bolted onto a database. That undersells it. Snowflake Intelligence is an agent that runs inside your Snowflake account. When you ask a question, it works out which data is relevant, generates and runs the query, interprets the result, and decides how to present it: a single number, a ranked list, or a chart.

Three things make it different from a generic AI assistant:

• It runs where the data lives. Queries execute inside Snowflake, under your existing roles and access policies. Nothing is exported to a separate tool.
• It reasons over business meaning, not just tables. When a semantic model describes what your metrics and entities mean, the agent uses those definitions instead of guessing from column names.
• It shows its work. Every answer is backed by generated SQL you can inspect, which matters a great deal in a regulated industry. We go deep on this in Episode 3.

The demo: a live Patients Management dataset

The dataset covers patients, their insurance companies, subscribed services, copay values, and imaging services. It is the kind of operational data that sits at the center of any provider or payer. We asked questions the way an operations manager would, with no schema explanation and no preamble.

1. Insurance companies and patient counts, in seconds

The first question: which insurance companies are in the system, and how many patients does each cover? In a traditional setup, that is a GROUP BY query, trivial for an analyst and out of reach for everyone else. Snowflake Intelligence returned a ranked answer in seconds, along with a bar chart it generated without being asked. It recognized that a ranked comparison across entities is best read visually.

2. Automatic charts, with no prompting

As the conversation continued, the agent kept making sensible visualization choices on its own: bar charts for comparisons, pie charts for distributions. Anyone who has spent an afternoon configuring axes and chart types in a BI tool will appreciate how much friction disappears when the person asking never has to think about the format.

3. The top 5 extra services, ranked by copay

Next, a revenue cycle question: which five additional services carry the highest copay? One sentence produced a ranked list ready to act on. In practice, this is the insight that informs service promotion, payer negotiations, and capacity planning, and it usually arrives days after someone first asks for it.

4. The least popular imaging service, and why it matters

The most useful question in the demo was about what deserves attention. We asked which imaging service had the lowest uptake. The answer itself is a single row, but it turns a vague feeling ("imaging seems to underperform") into a specific lead. Low uptake can point to pricing, scheduling, coverage tiers, or how the service is communicated to patients. Knowing exactly which service to investigate is the difference between data and a decision.

Why the answers were right: the semantic layer

A demo like this looks effortless, and that is exactly why it deserves a closer look. An agent that reads a schema perfectly can still answer confidently and incorrectly if it does not know what the data means. Does "patient count" include inactive members? Is copay stored per visit or per plan year? Which table is the source of truth for coverage?

Those definitions live in a governed semantic layer, alongside data quality checks, freshness monitoring, and lineage. That is the work behind AI-Ready Data Governance, and it is what turns an impressive demo into answers a clinical or finance leader can actually rely on. In healthcare, a wrong number is not just embarrassing. It can drive the wrong coverage or staffing decision.

What this means for healthcare teams

• Faster decisions. Clinical operations, revenue cycle, and service managers answer their own questions in real time instead of waiting in a queue.
• Broader access without weaker governance. The people who most need data are rarely the ones who write SQL. Plain-English access closes that gap while queries still run under Snowflake roles and policies.
• Fewer ad hoc tickets. Every self-served question is one less item in the data team's backlog, freeing engineers for platform work that actually needs them.
• One version of the truth. Answers come from live, governed data, not a stale export or a dashboard built for a different purpose.

It is not a replacement for data engineering, and it does not retire every dashboard. Scheduled executive reporting still benefits from a fixed, shared view. Where conversational analytics shines is exploratory, ad hoc work, which is exactly where most healthcare teams lose the most time. See how we approach this for providers, payers, and pharma on our Healthcare & Pharma page.

Where to start

Most healthcare teams are closer to this than they think. The data is usually already in Snowflake. What is missing is the layer that makes an agent accurate: consistent definitions, quality checks, and access controls tuned for PHI. Our Snowflake consulting engagements start with a fixed-scope assessment that tells you which questions an agent can answer reliably today, what needs fixing first, and what a production rollout looks like. If your platform itself needs groundwork, we build it as an AI-Ready Snowflake Platform.

Next in the series

Episode 2: from expired contract to signed PDF in one conversation. Snowflake Intelligence stops answering questions and starts executing a real workflow.

Episode 3: building with Snowflake Intelligence through the REST API, for developers and architects.

‍

‍