Snowflake Cortex Code (CoCo) is an AI-powered coding agent built natively into Snowflake that plans tasks, calls tools, and executes code directly against your live account. It works as a full orchestration layer for agentic applications.
phData built a production NFIP claims adjudication app using CoCo as the orchestrator, running two feedback loops: one that converts freeform adjuster corrections into codified, auditable decision rules, and one that lets CoCo validate newly ingested policy documents for adjudication readiness.
The Cortex Code Agent SDK moves this pattern from subprocess CLI calls to a programmable library interface, making it significantly easier to wrap CoCo in a production backend with retry logic, observability frameworks like TruLens, and a clean normalized output schema.
CoCo-as-orchestrator works best in policy-heavy domains with active subject-matter experts and UAT workflows where user feedback should generate structured instructions and ground-truth training data.
Snowflake’s new Cortex Code Agent SDK is a first-class orchestration layer for your agents and AI applications.
We already saw the potential of using CoCo as an orchestrator at phData, and we’ve been doing it the “hard way” by wiring Cortex Code’s CLI into our own applications to be the primary agentic brain that coordinates agent tools, tasks, knowledge bases, and feedback loops. The Agent SDK is the natural next step to give teams a cleaner way to implement those same patterns directly in code.
This post walks through how we’ve been using CoCo as an agentic orchestration service today, why that pattern works so well for feedback‑heavy workloads and UAT, and how the Agent SDK makes it easier to adopt the same approach in your own Snowflake environment.
Why Snowflake Cortex Code wants to orchestrate your agents
Most teams exploring agents on Snowflake today are experimenting with:
Cortex Agents in Snowflake Intelligence
Open-source frameworks like CrewAI and LangGraph
Custom orchestration layers in Python with ReAct frameworks (Reasoning + Acting)Â
Those tools are powerful, but they are constrained since the tool layer is usually static. You define classes or schemas for tools up front, wire them into an agent loop, and then iterate cautiously as your app matures.
Cortex Code is different:
It is already an agentic developer that plans, calls tools, and iterates against your real Snowflake account and data stack.
It ships with Snowflake‑native skills (semantic view creation, Cortex Agents, and more) and lets you extend those skills with your own project‑specific logic.
It runs either inside Snowsight or via a CLI you can embed directly into your delivery workflows.
With that feature set, CoCo already looks like an orchestration service:
It understands your schemas, roles, and account configuration.
It can execute arbitrary CLI commands and Snowflake workloads on your behalf.
It can be instructed to rewrite its own tools: SQL, dbt, skills, even downstream agents, and validate them in real time.
The Agent SDK moves that orchestration capability from “call out to a CLI” to “invoke directly as a library,” while preserving the same mental model, with CoCo as the orchestration layer, your agents and tools as the execution layer, and Snowflake as the system of record.
Building a claims adjudication application with CoCo as orchestrator
As a proof of concept, we built a demo application that uses Cortex Code as an adaptive orchestrator for NFIP flood insurance claims. At a glance:
A Next.js frontend presents a three‑panel UI: claims, CoCo’s decision, and human feedback.
A FastAPI backend runs inside Docker and owns all business logic.
The knowledge base is comprised of claims processing manuals and lives in Snowflake:
EVAL_POLICY_SNIPPETStable holds chunked NFIP policy text.A Cortex Search service provides semantic retrieval over those chunks.
Cortex Code CLI is installed in the backend container and invoked as our orchestrator agent.
Figure 1 shows the high‑level architecture and the two feedback loops we’ll walk through in detail.
We wrapped CoCo in a CocoClaimOrchestrator service that:
Builds a five‑step adjudication prompt (item‑by‑item coverage, mandatory checks, self‑check, injected instructions, decision + JSON output).
Calls the
cortex -c agent_eval --bypassCLI with--output-format stream-jsonand robust retry/timeout logic.Parses CoCo’s stream‑json output with multiple strategies (direct JSON,
resultlines, assistant messages, accumulated deltas) to recover a clean decision payload.Normalizes that payload into our
PipelineResultschema for the UI and metrics engine.
Pulling in claims + evidence and pushing out a structured decision is the core orchestration loop.
We layered two adaptive feedback mechanisms on top that make this interesting for the Agent SDK, and for agentic apps generally.
Feedback loop 1: Freeform adjuster feedback as first‑class skills
In production insurance systems, the most valuable signal is how an experienced adjuster would have decided instead.
We wanted to capture that same loop, so the current app works like this:
A user (acting as a senior adjuster) runs a claim through the app.
CoCo returns an
APPROVE/DENY/PARTIALdecision plus item‑level payouts and reasoning.If CoCo is wrong, the adjuster types freeform feedback in plain language, for example:
Food freezers are a named basement exception in Section 4.B.
Apply the $2,500 valuables cap instead of denying valuables entirely.
Evaluate physical items separately from excluded financial losses.
Clicking Ask CoCo to Plan sends that text, along with claim context and CoCo’s prior result, to a dedicated
feedback_planner.pyservice.CoCo enters planning mode: it analyzes the feedback, proposes a structured instruction, and returns JSON with fields such as:
reasoning: why this change makes senseinstruction_type: e.g.,decision_rule,scoping_rule, orexplanation_ruletext: a human‑readable instruction to show in the UIstructured_rule: a concise, machine‑readable rule string
The app surfaces that proposal back to the user in a confirmation card. The user can accept or reject it.
On accept, we persist the proposed
UserInstructioninto an instruction store used by the pipeline so the next evaluation will include it.
Under the hood, feedback_planner.py prompts CoCo as an instruction editor rather than as the primary decision maker:
It builds a planning prompt with:
The claim summary and key fields (items, basement type, limits, etc.)
CoCo’s previous decision and reasoning
The raw feedback text from the adjuster
It asks CoCo to respond with JSON only, containing a short explanation plus a concrete, enforceable rule.
A small parser tries several strategies (direct JSON, fenced code blocks, substring extraction) to recover a
structured_rule. If everything fails, we still fall back to turning the user’s feedback into a defaultdecision_ruleinstruction so it’s not lost.
Once confirmed, these instructions flow through an injection pipeline as a new rule:
On the next evaluation, the backend loads all active instructions for that claim context.
CocoClaimOrchestratorinjects them into a dedicated Adjuster Instructions (MUST be applied) section between the self‑check and decision steps of the prompt.CoCo re‑runs the entire reasoning chain with those instructions applied, typically correcting the decision.
From an orchestration perspective, this pattern is exactly what the Agent SDK is designed to make easier:
Treat per‑user and per‑profile instructions as dynamic skills, learned directly from real feedback.
Keep the core agent loop unchanged, but let CoCo help design, validate, and structure those skills on demand.
Persist those rules for audit and governance, the same way you track model versions or feature definitions.
phData is letting CoCo rewrite its own decision rules safely at the edge, using human feedback as the source of truth, while the underlying application and Snowflake schema remain stable.
Feedback loop 2: Live knowledge‑base ingestion with CoCo watching
The second feedback loop is about the knowledge base itself.
Our claims app doesn’t just point at a fixed copy of the NFIP manual. It also lets users:
Switch between ingested policy versions (e.g., 2024‑10 vs. 2025‑06).
Upload a new PDF (e.g., an updated carrier manual), which is:
Chunked.
Inserted into Snowflake.
Used to rebuild the Cortex Search service.
Analyzed by Cortex Code for quality or failure diagnosis.
The heavy lifting happens in ingestion_manager.py:
Chunking
The manager uses
pdfplumberplus a sliding‑window function to break each page into overlapping text chunks.It records chunk IDs, section titles, manual version labels, and sample text.
Snowflake insertion & search service rebuild
Chunks are batch‑inserted into
EVAL_POLICY_SNIPPETSunder the selectedmanual_version.A
CREATE OR REPLACE CORTEX SEARCH SERVICEstatement rebuilds the semantic index across all chunks, usingchunk_textas the search field andsection_title/manual_versionas attributes.
CoCo‑Powered Validation and Diagnostics
After ingestion, we hand control back to CoCo in two modes:Success path:
_coco_analyze_successasks CoCo to:Review ingestion metadata (chunk counts, version labels).
Read a sample of chunks.
Produce a short, opinionated quality report: is this a valid NFIP manual, what topics it covers, and whether it’s ready for adjudication.
Failure path:
_coco_diagnose_failureasks CoCo to:Inspect failure type (e.g., zero chunks, Snowflake connection issues, exceptions).
See truncated error details and any partial chunks.
Return a 3–5 sentence diagnostic plus a concrete fix (e.g., your PDF contains no text, connection string invalid).
In both cases, CoCo is invoked via the same CLI wrapper (
_invoke_coco) with--output-format stream-json, and we extract just the human‑readable text from the result/assistant messages.
This is the second major pattern the Agent SDK enables:
Treat CoCo as a meta‑agent, not just end‑user queries.
Expose that feedback to users in the app as ingestion health and doc‑quality suggestions, while still keeping all DDL/DML inside Snowflake guardrails.
None of this requires users to edit production code. They can:
Upload new manuals.
See CoCo’s assessment of whether those manuals are fit for purpose.
Iterate on document quality and ingestion configuration.
Your engineering and AI teams can then triage that feedback like model drift to decide if new manual versions need to be promoted, or if updates are required for ingestion rules, or if new decision instructions need to be tied to specific versions.
CoCo as the primary agent (and orchestrator of sub‑agents)
Cortex Code thus plays three roles in our NFIP application, and in similar apps we’re building:
Primary agentic brain
It owns the full reasoning chain from evidence retrieval to decision JSON.
It injects and applies user‑level decision rules.
It validates knowledge‑base quality and failure modes.
Orchestrator of tools and sub‑agents
It calls Cortex Search and Snowflake queries as tools.
It can call additional sub‑agents (Cortex Agents, CrewAI, LangGraph) where appropriate, especially for non‑claims logic.
It rewrites those tools via CLI (and, with the Agent SDK, via an API), validating changes against live data.
Bridge between interactive UIs and Snowflake infrastructure
The Next.js frontend never sees LLMs directly; it only sees structured outputs and suggestions.
The FastAPI backend treats CoCo as another regulated dependency alongside Snowflake, subject to timeouts, retries, logging, and metrics.
This approach goes even further when we introduce sub-agents for CoCo to orchestrate, each equipped with skills optimized for a specific part of the workflow. If those skills can also adapt to user feedback, the pattern starts to look a lot like the skills-first workflows we use to build Cortex Agents with TruLens where we break the lifecycle into discrete steps, treat each step as a skill, and let a router or agent decide what to run next. It also points toward a future where individual users can help shape those workflows within controlled guardrails.
In the NFIP demo, those steps are:
Retrieve evidence for a claim.
Run CoCo’s five-step adjudication.
Translate freeform user feedback into structured instructions through the planner.
Optionally ingest a new manual and have CoCo review its quality and readiness.
Re-adjudicate with updated rules, knowledge, and, over time, skills.
With the Agent SDK, we can move this entire pattern from call a CLI through subprocess into a code‑first agent orchestration service that:
Exposes CoCo’s agentic planning, tools, and skills directly to our backend.
Makes it easier to plug in observability frameworks (e.g., TruLens) around the agent loop.
Reduces friction for integrating sub‑agents and evaluation pipelines.
The underlying architecture doesn’t change since Snowflake stays the system of record and Cortex Code stays the brain, but the ergonomics of building and operating these systems improves significantly.
Where this pattern shines
We’ve found CoCo-as-orchestrator especially useful in two scenarios:
Complex, policy‑heavy domains with strong subject‑matter experts
Claims, underwriting, compliance, and clinical workflows where users routinely spot subtle mistakes.
You want those corrections to become codified instructions and skills, not just one‑off overrides.
UAT and rollout of new AI features
Before code changes ship, you want business testers to:
Try edge cases.
Upload their own documents.
Push on the limits of the knowledge base and rules.
CoCo gives you a way to collect, summarize, and triage that feedback as:
New instructions.
KB versions and ingestion configs.
Candidate sub‑agents or tools.
CoCo creates a stronger path to ground-truth dataset development, since:Â
It logs ingestion quality and improvement recommendations for user-uploaded documents.
It uses planning mode to iterate with users before instruction updates are confirmed, pushing them to identify root causes of misfires rather than apply arbitrary overrides.Â
The combination of cached sessions and profile-specific updates gives developers a high-signal feedback trail that can be translated into curated golden datasets and production-ready improvements.
Figure 3 shows this UAT pattern in practice with a claim that CoCo initially got wrong, but the planning-based feedback loop was able to refine the instruction set and match the golden dataset. It also shows ingestion feedback on a newly uploaded manual that helps improve downstream adjudication quality.
Whether it’s orchestrating complex, policy-heavy workflows or helping teams build ground truth during UAT, the combination of Snowflake and Cortex Code gives you a strong safety story:
CoCo never steps outside Snowflake’s RBAC model.
All persistent states (chunks, instructions, claims, metrics) live in governed Snowflake tables.
You can treat user‑driven changes to rules and knowledge the same way you treat model changes in an MLOps pipeline: monitored, versioned, and rolled forward deliberately.
Looking ahead with the Cortex Code Agent SDK
As Snowflake’s Cortex Code Agent SDK matures, we see a few natural evolutions of this pattern:
First‑class agent orchestration services in our backends that:
Wrap CoCo agents, Cortex Agents, and external frameworks behind a unified interface.
Standardize how we pass feedback (instructions, profiles, ingestion reports) back into agents.
Expose a consistent, observable agent loop to platforms like TruLens.
Profile‑aware orchestration where:
Different user profiles (adjusters, underwriters, QA, UAT testers) map to different instruction sets and tool capabilities.
CoCo uses those profiles to decide which tools to rewrite, which sub‑agents to call, and which suggestions to surface.
Richer triage pipelines that treat things like misclassified claims, ingestion failures and UAT “red flags” as first‑class telemetry, on par with model drift, and route them into backlog, experiment, or rollout workflows accordingly.
We started by installing CoCo into a Docker container, calling the CLI with subprocess, and teaching it to orchestrate claims and ingestion. The Agent SDK takes that same idea treating CoCo as an agentic orchestration service and makes it something any Snowflake team can adopt without writing as much glue.
If you’re already experimenting with Cortex Agents, AWS Bedrock’s AgentCore, CrewAI, or LangGraph, Cortex Code can sit above them as the orchestration layer that can:
Rewrite tools on the fly.
Validate changes in your real Snowflake environment.
Capture user and UAT feedback as structured instructions and skills.
That’s where we’re headed, and where the most interesting agentic architectures on Snowflake are likely to land.
Looking to build production native applications on Snowflake?
phData’s team has built and shipped production agentic systems on Snowflake, including Snowflake Cortex Code, Cortex Agents, and the broader Intelligence Platform.
FAQs
What is Snowflake Cortex Code?​
Snowflake Cortex Code (informally “CoCo”) is an AI-powered coding agent built natively into Snowflake. It plans tasks, calls tools, writes and executes SQL and Python, and operates directly against your live Snowflake account, schemas, and data. The Cortex Code Agent SDK lets developers embed CoCo’s agentic capabilities programmatically in Python or TypeScript rather than invoking it through the CLI.
How does Snowflake Cortex Code differ from Cortex Agents?
Cortex Agents in Snowflake Intelligence are task-specific agents you configure to answer questions or run workflows against structured and unstructured data. Snowflake Cortex Code is a developer-focused agent that can write and modify code, rewrite tools, call sub-agents including Cortex Agents, and act as an orchestration layer above other frameworks. Cortex Agents are the right choice for governed, conversational data access; Snowflake Cortex Code is the right choice when you need an orchestration layer that adapts to user feedback and rewrites its own tools.
How do I use Snowflake Cortex Code as an orchestration service?
The most direct path with the Cortex Code Agent SDK is to wrap CoCo in a service class in your backend, build structured prompts that pass task context and any active user instructions, invoke CoCo via the SDK rather than via subprocess, and parse the stream-json output into a clean payload. phData’s CocoClaimOrchestrator uses this pattern with retry logic, multiple JSON parsing strategies, and a PipelineResult schema as the normalized output.
What workloads are best suited to the CoCo-as-orchestrator pattern?
Feedback-heavy workloads where subject-matter experts need to correct and refine AI decisions over time, and UAT scenarios where business testers push against edge cases and upload their own documents. The pattern works especially well when you want user feedback to become structured, auditable instructions rather than one-off overrides. phData has applied it to NFIP claims adjudication and is building similar patterns for underwriting, compliance, and clinical workflows.
Does CoCo-as-orchestrator require changes to Snowflake RBAC?
No. CoCo operates within your existing Snowflake role-based access control (RBAC) model. All persistent state, including chunks, instructions, claims, and metrics, lives in governed Snowflake tables. You manage access the same way you would any other Snowflake workload.
