Building a Production-Grade Coding Agent on Snowflake: From Trial Account to Enterprise Deployment

Deploy Snowflake’s CoCo runtime as a managed agent, with a Groq-powered fallback that works today on any account — including read-only SQL guardrails and a Streamlit chat UI. What is the Coding Agent? At Snowflake Summit 2026, Snowflake announced a game-changing capability: the same runtime that powers CoCo (Cortex Code — Snowflake’s AI coding assistant) is now deployable as a managed agent via the Cortex Agents REST API. This means you can: Build a coding agent with code_toolset_all Deploy it in any application (web apps, CLI tools, pipelines) Get the full CoCo sandbox: Bash, Python, SQL, file I/O, web search Run it inside Snowflake’s governance boundary The agent is defined declaratively — a single CREATE AGENT statement — and invoked via a REST API. Snowflake handles model routing, tool invocation, and result assembly. What code_toolset_all Provides | Tool | Capability | | --------------- | ------------------------------------- | | Bash | Execute shell commands | | Read/Write/Edit | File operations on mounted workspaces | | Grep/Glob | Search files and patterns | | SQL Exec | Query Snowflake directly | | Python 3.12 | Full sandbox with pip access (PyPI) | | Web Search | Find documentation and references | | Skills Engine | Extend with custom domain skills | All running inside a managed sandbox — no infrastructure to maintain, no data leaving your governance boundary. The Reality: Not Every Account Can Run It Yet Here’s what the announcement didn’t address: code_toolset_all execution (via DATA_AGENT_RUN) requires the Cortex Code entitlement. Trial accounts get error 399504: { "message": "Cortex Code CLI is not enabled or the usage limit has been reached.", "code": "399504" } But here’s the insight: the agent object can be created on any account . Only execution is gated. This means you can deploy the entire architecture today and activate it instantly when the entitlement becomes available. Architecture: Three Paths to Production Implementation: End-to-End Step 1: Infrastructure Foundation -- Dedicated database for all agent objects CREATE DATABASE IF NOT EXISTS CORTEX_AGENTS; CREATE SCHEMA IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT; -- XS warehouse - compute happens inside the managed sandbox CREATE WAREHOUSE IF NOT EXISTS CODING_AGENT_WH WAREHOUSE_SIZE = 'X-SMALL' AUTO_SUSPEND = 60 AUTO_RESUME = TRUE; -- Stage for custom skills CREATE STAGE IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT.SKILL_STAGE DIRECTORY = (ENABLE = TRUE); -- PyPI access for the sandbox GRANT DATABASE ROLE SNOWFLAKE.PYPI_REPOSITORY_USER TO ROLE ACCOUNTADMIN; Step 2: Three-Tier RBAC ACCOUNTADMIN └── CODING_AGENT_ADMIN (manages lifecycle, versions, skills) └── CODING_AGENT_DEVELOPER (modifies spec, deploys candidates) └── CODING_AGENT_CONSUMER (invokes agent only) CREATE ROLE IF NOT EXISTS CODING_AGENT_ADMIN; CREATE ROLE IF NOT EXISTS CODING_AGENT_DEVELOPER; CREATE ROLE IF NOT EXISTS CODING_AGENT_CONSUMER; GRANT ROLE CODING_AGENT_CONSUMER TO ROLE CODING_AGENT_DEVELOPER; GRANT ROLE CODING_AGENT_DEVELOPER TO ROLE CODING_AGENT_ADMIN; GRANT ROLE CODING_AGENT_ADMIN TO ROLE ACCOUNTADMIN; -- Consumer can invoke but never modify GRANT CREATE AGENT ON SCHEMA CORTEX_AGENTS.CODING_AGENT TO ROLE CODING_AGENT_ADMIN; Step 3: Workspace Mounts Workspaces provide persistent file storage that the agent sandbox can mount: CREATE WORKSPACE IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT.AGENT_WORKSPACE COMMENT = 'Persistent workspace for agent file operations'; CREATE WORKSPACE IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT.SHARED_DATA COMMENT = 'Shared reference data'; The agent sees these as /workspace and /data — standard filesystem paths. Step 4: Create the Agent CREATE OR REPLACE AGENT CORTEX_AGENTS.CODING_AGENT.PRODUCTION_CODING_AGENT COMMENT = 'Production Coding Agent - full CoCo runtime' FROM SPECIFICATION $$ models: orchestration: claude-sonnet-4-5 instructions: system: | You are a production data engineering assistant deployed inside Snowflake. Safety Rules (NEVER violate): - NEVER execute DROP, TRUNCATE, or DELETE without explicit confirmation - NEVER modify user credentials (ALTER USER, GRANT, REVOKE) - NEVER access databases/schemas outside authorized scope - NEVER output raw credentials or secrets Operational Rules: - Always validate SQL before executing - Write outputs to /workspace for persistence - Use LIMIT clauses on exploratory queries - When errors occur, explain root cause and suggest fix tools: - tool_spec: type: code_toolset_all name: code_toolset_all tool_resources: code_toolset_all: permission_policy: type: always_allow workspace_mounts: - name: "CORTEX_AGENTS.CODING_AGENT.AGENT_WORKSPACE" type: workspace mount_path: "/workspace" - name: "CORTEX_AGENTS.CODING_AGENT.SHARED_DATA" type: workspace mount_path: "/data" artifact_repositories: - SNOWFLAKE.SNOWPARK.PYPI_SHARED_REPOSITORY $$; Key configuration choices: | Parameter | Choice | Rationale | | --------------------- | ----------------- | ---------------------------------------------- | | orchestration | claude-sonnet-4-5 | Best speed/quality for coding tasks | | permission_policy | always_allow | No human gate for automated workflows | | workspace_mounts | 2 mounts | Separate working directory from read-only data | | artifact_repositories | PyPI shared | Enables `pip install` in the sandbox | For interactive use, create a second variant with always_ask that requests permission before state changes. Step 5: The Execution Layer (7 Procedures) These Snowpark procedures are the foundation. They work on ALL accounts: EXECUTE_PYTHON — Run arbitrary Python CREATE OR REPLACE PROCEDURE EXECUTE_PYTHON(code VARCHAR) RETURNS VARCHAR LANGUAGE PYTHON RUNTIME_VERSION = '3.11' PACKAGES = ('snowflake-snowpark-python') HANDLER = 'execute' AS $$ import sys from io import StringIO def execute(session, code): old_stdout = sys.stdout sys.stdout = buffer = StringIO() local_vars = {'session': session} try: exec(code, {}, local_vars) output = buffer.getvalue() if not output and 'result' in local_vars: output = str(local_vars['result']) return output if output else "(no output)" except Exception as e: return f"ERROR [{type(e).__name__}]: {str(e)}" finally: sys.stdout = old_stdout $$; PROFILE_TABLE — Comprehensive data profiling CREATE OR REPLACE PROCEDURE PROFILE_TABLE(table_fqn VARCHAR) RETURNS VARCHAR LANGUAGE PYTHON RUNTIME_VERSION = '3.11' PACKAGES = ('snowflake-snowpark-python') HANDLER = 'profile' AS $$ def profile(session, table_fqn): df = session.table(table_fqn) row_count = df.count() fields = df.schema.fields # Returns: row count, column types, null rates, # cardinality, and sample data (first 5 rows) ... $$; VALIDATE_SQL — Read-only guardrails CREATE OR REPLACE PROCEDURE VALIDATE_SQL(sql_text VARCHAR) RETURNS VARCHAR LANGUAGE PYTHON RUNTIME_VERSION = '3.11' PACKAGES = ('snowflake-snowpark-python') HANDLER = 'validate' AS $$ import re BLOCKED_PATTERNS = [ (r"\bINSERT\b", "INSERT blocked - read-only mode"), (r"\bUPDATE\b", "UPDATE blocked - read-only mode"), (r"\bDELETE\b", "DELETE blocked - read-only mode"), (r"\bCREATE\b", "CREATE blocked - read-only mode"), (r"\bALTER\b", "ALTER blocked - read-only mode"), (r"\bDROP\b", "DROP blocked - read-only mode"), (r"\bGRANT\b", "GRANT blocked - read-only mode"), (r"\bREVOKE\b", "REVOKE blocked - read-only mode"), (r"\bCOPY\s+INTO\b", "COPY INTO blocked - read-only mode"), (r"\bEXECUTE\b", "EXECUTE blocked - read-only mode"), (r"\bSYSTEM\$", "System functions blocked - read-only mode"), (r"\bUSE\s+ROLE\b", "USE ROLE blocked - read-only mode"), # ... more patterns ] def validate(session, sql_text): for pattern, msg in BLOCKED_PATTERNS: if re.search(pattern, sql_text.upper(), re.IGNORECASE): return f"BLOCKED: {msg}" return "PASS" $$; Full procedure inventory: | # | Procedure | Purpose | Verified | | -: | ------------------------------------- | -------------------------------------- | -------- | | 1 | EXECUTE_PYTHON(code) | Run arbitrary Python | Yes | | 2 | PROFILE_TABLE(table) | Schema, nulls, cardinality, and sample | Yes | | 3 | EXECUTE_SQL(sql, max_rows) | Formatted tabular output | Yes | | 4 | TRANSFORM_AND_LOAD(sql, target, mode) | ETL pipeline | Yes | | 5 | EXPORT_TO_STAGE(sql, path, format) | Export CSV/JSON to stage | Yes | | 6 | COMPARE_TABLES(table_list) | Multi-table comparison | Yes | | 7 | VALIDATE_SQL(sql) | Read-only guardrails | Yes | The Groq Hybrid Agent: Full LLM Reasoning on Any Account Since trial accounts block all Snowflake LLM functions (CORTEX.COMPLETE, DATA_AGENT_RUN), we use Groq's free API for reasoning and Snowflake for execution. How It Works User: "What are the top 5 customers by order value?" │ ▼ Groq LLM (Llama 3.3 70B) reasons and plans │ Returns: {"action": "execute_sql", "sql": "SELECT C_NAME..."} │ ▼ Client-side guardrails check (read-only patterns) │ ▼ Snowflake executes: CALL EXECUTE_SQL('SELECT C_NAME...') │ Returns: formatted results │ ▼ Groq LLM analyzes results │ Needs more data? → loop back. Has answer? → respond. │ ▼ Final answer to user Production Hardening The hybrid agent isn’t a toy. It includes: class HybridCodingAgent: def __init__(self, groq_api_key, snowflake_config): self.audit = AuditLogger() # Structured event trail self.reasoner = GroqReasoner(...) # Token tracking + pruning self.executor = SnowflakeExecutor(...) # Retry + health check | Feature | Implementation | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Retry with backoff | 3 retries with exponential backoff (2s, 4s, 8s) for both Groq and Snowflake | | Conversation pruning | Caps conversation at 20 messages while retaining the system prompt and latest messages | | Token budget | 50K tokens per session; blocks further API calls when the limit is exceeded | | SQL guardrails | Development mode allows `CREATE`, `INSERT`, `UPDATE`, and `DELETE` (with `WHERE` clause); blocks destructive operations such as `DROP`, `TRUNCATE`, and unrestricted `DELETE`/`UPDATE` | | Connection health check | Verifies Snowflake connectivity and required stored procedures during application startup | | Audit logger | Logs every action, error, and guardrail event with timestamps | | Rate limit handling | Detects Groq HTTP 429 responses, waits using exponential backoff, and retries automatically | | Graceful degradation | Handles partial failures gracefully without terminating the user session | Why Groq? | Attribute | Value | | --------- | -------------------------------------------------------------- | | Free tier | 30 requests/minute, no credit card required | | Speed | Less than 500 ms response time (custom LPU hardware) | | Model | Llama 3.3 70B – versatile and code-aware | | API Key | [https://console.groq.com/keys](https://console.groq.com/keys) | Running the CLI Agent pip install groq snowflake-connector-python export GROQ_API_KEY='gsk_...' export SNOWFLAKE_ACCOUNT='FQDRZOE-SD47007' # org-account format export SNOWFLAKE_USER='SATISH' export SNOWFLAKE_PASSWORD='...' python groq_hybrid_agent.py ============================================================ HYBRID CODING AGENT (Production) Groq LLM (reasoning) + Snowflake (execution) Type 'quit' to exit, 'reset' to clear, 'audit' for stats ============================================================ Snowflake: connected (CZ04821, ACCOUNTADMIN) Procedures: available Groq model: llama-3.3-70b-versatile Token budget: 50,000 > Profile the ORDERS table --- Iteration 1 [tokens: 1,247/50,000] --- AGENT: {"action": "profile_table", "table": "SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS"} RESULT: Total Rows: 1,500,000 | Columns: 9 | ... --- Iteration 2 [tokens: 3,891/50,000] --- FINAL ANSWER: The ORDERS table has 1,500,000 rows with 9 columns: - O_ORDERKEY: 1.5M distinct (primary key) - O_CUSTKEY: 99,996 distinct customers - O_ORDERSTATUS: 3 values (F, O, P) - O_TOTALPRICE: range $857 to $555,285 - O_ORDERDATE: 2,406 distinct dates (1992-2998) ... Streamlit Chat UI A full-featured chat interface that brings it all together: Features | Feature | Description | | ------------------- | ------------------------------------------------------------------------------- | | Chat interface | `st.chat_input` and `st.chat_message` with full conversation history | | Agent trace | Expandable execution steps showing action, parameters, result, and duration | | Guardrail banners | Warning banner displayed when SQL execution is blocked | | Token budget meter | Visual progress bar with threshold warnings | | Quick actions | One-click buttons to trigger predefined agent actions | | Health indicators | Status indicators for Groq and Snowflake connectivity | | Export session | Download complete conversation history and execution traces as JSON | | Auto-reconnect | Automatically retries Snowflake connection failures | | Rate limit handling | Displays a waiting message and automatically retries on Groq HTTP 429 responses | Cortex Coding Agent — UI Feature Map Running It pip install streamlit groq snowflake-connector-python export GROQ_API_KEY='gsk_...' export SNOWFLAKE_ACCOUNT='FQDRZOE-SD47007' export SNOWFLAKE_USER='SATISH' export SNOWFLAKE_PASSWORD='...' streamlit run streamlit_groq_app.py Open http://localhost:8501 — you'll see the chat interface with sidebar controls. Quick Actions (Instant Trigger) The sidebar has quick action buttons that execute immediately on click — no second step needed: if st.button("📊 Profile ORDERS", use_container_width=True): st.session_state.messages.append({"role": "user", "content": "Profile ORDERS"}) st.session_state.trigger_agent = True st.rerun() # Immediately triggers agent execution DEV Environment Guardrails: Defense in Depth Since this is a coding agent for developers , the guardrails are tuned for a DEV environment — allowing developers to build and iterate while preventing destructive or privilege-escalation operations. Design Philosophy A coding agent needs to create things . Blocking all DML/DDL would make it useless for development. Instead, we protect against: Dropping entire databases/schemas (catastrophic) Bulk deletes without WHERE (data loss) Privilege escalation (GRANT/REVOKE/ALTER USER) Data exfiltration to external clouds Modifications to production reference data Layer 1: Client-Side (Python, before Snowflake call) DANGEROUS_SQL_PATTERNS = [ # --- DESTRUCTIVE OPS (blocked even in dev) --- (r"\bDROP\s+(DATABASE|SCHEMA)\b", "DROP DATABASE/SCHEMA blocked — too destructive"), (r"\bTRUNCATE\b", "TRUNCATE blocked — use DELETE WHERE instead"), (r"\bDELETE\b(?!.*\bWHERE\b)", "DELETE without WHERE blocked"), (r"\bUPDATE\b(?!.*\bWHERE\b)", "UPDATE without WHERE blocked"), # --- PRIVILEGE ESCALATION (never allowed) --- (r"\bGRANT\b", "GRANT blocked - request via admin role"), (r"\bREVOKE\b", "REVOKE blocked - request via admin role"), (r"\bCREATE\s+USER\b", "CREATE USER blocked - admin only"), (r"\bALTER\s+USER\b", "ALTER USER blocked - admin only"), (r"\bCREATE\s+ROLE\b", "CREATE ROLE blocked - admin only"), (r"\bALTER\s+ROLE\b", "ALTER ROLE blocked - admin only"), # --- ACCOUNT/ORG LEVEL (never allowed) --- (r"\bALTER\s+ACCOUNT\b", "ALTER ACCOUNT blocked - org admin only"), (r"\bALTER\s+WAREHOUSE\b.*\b(SUSPEND|RESUME)\b", "Warehouse SUSPEND/RESUME blocked"), # --- DATA EXFILTRATION (never allowed) --- (r"\bCOPY\s+INTO\b.*'s3://", "COPY to external S3 blocked"), (r"\bCOPY\s+INTO\b.*'gcs://", "COPY to external GCS blocked"), (r"\bCOPY\s+INTO\b.*'azure://", "COPY to external Azure blocked"), # --- SECURITY/NETWORK (never allowed) --- (r"\bCREATE\s+.*\bNETWORK\s+RULE\b", "Network rule creation blocked"), (r"\bCREATE\s+.*\bSECRET\b", "Secret creation blocked"), # --- PRODUCTION SCHEMA PROTECTION --- (r"\b(INSERT|UPDATE|DELETE|DROP|ALTER|CREATE)\b.*\bSNOWFLAKE_SAMPLE_DATA\b", "SNOWFLAKE_SAMPLE_DATA is read-only - use CORTEX_AGENTS schema"), ] Layer 2: Server-Side (Snowflake procedure) CALL CORTEX_AGENTS.CODING_AGENT.VALIDATE_SQL('DROP DATABASE PRODUCTION'); -- Returns: BLOCKED: DROP DATABASE/SCHEMA blocked CALL CORTEX_AGENTS.CODING_AGENT.VALIDATE_SQL('CREATE TABLE CORTEX_AGENTS.CODING_AGENT.MY_TEST AS SELECT 1'); -- Returns: PASS CALL CORTEX_AGENTS.CODING_AGENT.VALIDATE_SQL('DELETE FROM MY_TABLE'); -- Returns: BLOCKED: DELETE without WHERE blocked DEV Permission Matrix | Operation | Allowed | Rationale | |-----------|---------|-----------| | `SELECT`, `SHOW`, `DESCRIBE` | Yes | Read-only operations | | `CREATE TABLE`, `CREATE VIEW` | Yes | Create development objects | | `CREATE OR REPLACE` | Yes | Iterate on object definitions | | `INSERT INTO` | Yes | Load test or development data | | `UPDATE ... WHERE ...` | Yes | Modify specific rows only | | `DELETE ... WHERE ...` | Yes | Remove specific rows only | | `DROP TABLE`, `DROP VIEW` | Yes | Clean up development objects | | `USE DATABASE`, `USE SCHEMA` | Yes | Navigate databases and schemas | | `CREATE TABLE AS SELECT (CTAS)` | Yes | Materialize query results | | `COPY INTO @internal_stage` | Yes | Export data to internal Snowflake stages | | `DROP DATABASE`, `DROP SCHEMA` | No | Too destructive, even in development | | `TRUNCATE` | No | Use `DELETE ... WHERE ...` instead | | `DELETE` (without `WHERE`) | No | Requires a `WHERE` clause | | `UPDATE` (without `WHERE`) | No | Requires a `WHERE` clause | | `GRANT`, `REVOKE` | No | Prevent privilege escalation | | `ALTER USER`, `ALTER ROLE` | No | Administrative operations only | | `COPY` to Amazon S3, Google Cloud Storage, or Azure Blob Storage | No | Prevent data exfiltration | | Modify `SNOWFLAKE_SAMPLE_DATA` | No | Protect reference datasets | | Network rules, secrets, and security integrations | No | Infrastructure team responsibility | Even if the LLM generates a blocked operation, it shows a clear warning explaining why it was blocked and what to do instead . Version Management Agent specs evolve. Use ALTER AGENT to deploy updates: ALTER AGENT PRODUCTION_CODING_AGENT MODIFY LIVE VERSION SET SPECIFICATION $$ models: orchestration: claude-opus-4-6 -- Upgraded model ... $$; The Versioning UI (Public Preview) in Snowsight lets you compare versions side-by-side, rollback with one click, and promote candidates. Operational Monitoring -- Procedure usage by type SELECT CASE WHEN query_text ILIKE '%EXECUTE_PYTHON%' THEN 'EXECUTE_PYTHON' WHEN query_text ILIKE '%PROFILE_TABLE%' THEN 'PROFILE_TABLE' WHEN query_text ILIKE '%EXECUTE_SQL%' THEN 'EXECUTE_SQL' WHEN query_text ILIKE '%VALIDATE_SQL%' THEN 'VALIDATE_SQL' ELSE 'OTHER' END AS procedure_name, COUNT(*) AS calls, AVG(DATEDIFF('second', start_time, end_time)) AS avg_sec FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE query_text ILIKE '%CORTEX_AGENTS.CODING_AGENT.%' AND start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY calls DESC; -- Guardrail block rate SELECT DATE_TRUNC('day', start_time) AS day, COUNT(*) AS total_validate_calls, COUNT_IF(query_text ILIKE '%BLOCKED%') AS blocked_count, ROUND(blocked_count / NULLIF(total_validate_calls, 0) * 100, 2) AS block_rate_pct FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE query_text ILIKE '%VALIDATE_SQL%' AND start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY 1 DESC; Account Tier Reality ┌─────────────────────────────────────────────────────────┐ │ TRIAL ACCOUNT (what works today): │ │ ✅ Agent objects (created, versioned, ready) │ │ ✅ 7 Snowpark procedures (full execution layer) │ │ ✅ VALIDATE_SQL guardrail (server-side) │ │ ✅ Groq Hybrid Agent (CLI + Streamlit UI) │ │ ✅ Workspaces, stages, RBAC, cost controls │ │ ❌ DATA_AGENT_RUN (error 399504) │ │ ❌ CORTEX.COMPLETE (blocked) │ │ ❌ External access integrations │ ├─────────────────────────────────────────────────────────┤ │ PAID ACCOUNT (after upgrade): │ │ ✅ Everything above, PLUS: │ │ ✅ DATA_AGENT_RUN (full managed CoCo runtime) │ │ ✅ REST API + SDK + Async execution │ │ ✅ External access (GitHub, etc.) │ │ ✅ Streaming responses, multi-turn sessions │ │ │ │ UPGRADE REQUIRES: ZERO REDEPLOYMENT │ │ Agents are already created and waiting. │ └─────────────────────────────────────────────────────────┘ Upgrade Path (Trial → Paid) When your account gets the Cortex Code entitlement: No infrastructure changes — everything is deployed Enable external access (one statement): CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION github_integration ALLOWED_NETWORK_RULES = (CORTEX_AGENTS.CODING_AGENT.github_access_rule) ENABLED = TRUE; 3. Verify agent runtime : SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN('CORTEX_AGENTS.CODING_AGENT.PRODUCTION_CODING_AGENT', '{"messages": [{"role": "user", "content": [{"type": "text", "text": "Reply: AGENT_OK"}]}]}' ); -- Should return "AGENT_OK" instead of error 399504 4. Switch clients from Groq hybrid to native REST API/SDK 5. Fallback procedures remain as backup What’s Coming Next (Summit 2026 Announcements) | Feature | Status | Impact on This Architecture | |---------|--------|-----------------------------| | Skills Package | Preview Soon | Package custom skills as a single reusable URI | | Agent Toolset | Preview Soon | Reuse tools across multiple agents without duplication | | Tool Search | Preview Soon | Progressive tool discovery instead of loading all tools upfront | | Async Agent API | GA Soon | Enable background execution for long-running tasks | | Code Execution Tool | Preview Soon | Sandboxed Python execution with PDF and chart generation | | Interrupt and Resume | GA Soon | Pause, modify, and continue agent workflows | | Partial Access | Preview Soon | Support multiple permission levels for a single agent based on role | | Versioning UI | Public Preview | Visual comparison of skill and agent versions in Snowsight | ``` Our architecture supports all of these. The foundation is ready. Key Takeaways 1. Deploy Everything on Day One Agent objects, RBAC, workspaces, procedures — all deployed on trial. When the entitlement activates: zero redeployment. 2. Read-Only by Default The agent should NEVER modify production data without explicit override. 25+ regex patterns at two layers ensure this. 3. Groq is the Perfect Bridge Free, fast, no credit card. The hybrid pattern keeps data inside Snowflake while reasoning happens externally. 4. Audit Everything Every action, every blocked query, every token spent — logged and queryable. In production: “What did the agent do at 3am?” 5. Budget Your Tokens Track usage, prune conversations, cap sessions. A runaway agent loop can burn through limits fast. 6. One-Click UX Matters Quick actions should trigger immediately. Users expect instant feedback from AI interfaces. Project Structure cortex-coding-agent/ 22 files, ~4,500 lines ├── 01-infrastructure/ Database, RBAC, network ├── 02-agent/ CREATE AGENT + workspaces + versioning ├── 03-skills/ Custom skill templates ├── 04-client-integration/ │ ├── groq_hybrid_agent.py ★ Production CLI agent (555 lines) │ ├── streamlit_groq_app.py ★ Chat UI with trace (431 lines) │ ├── rest_api_example.py REST client (paid accounts) │ ├── sdk_example.py SDK client (paid accounts) │ └── async_example.py Async pattern (paid accounts) ├── 05-operations/ Monitoring + guardrail tracking ├── 06-deployment/ Checklist + CI/CD └── 07-fallback-trial/ 7 procedures + full test suite Try It Yourself # 1. Run infrastructure SQL in Snowflake (5 min) # 2. Deploy procedures (2 min) # 3. Set up locally: pip install groq snowflake-connector-python streamlit export GROQ_API_KEY='gsk_...' # Free from console.groq.com/keys export SNOWFLAKE_ACCOUNT='YOUR_ORG-YOUR_ACCOUNT' export SNOWFLAKE_USER='YOUR_USER' export SNOWFLAKE_PASSWORD='YOUR_PASSWORD' # 4. Run Streamlit UI: streamlit run streamlit_groq_app.py # 5. Or CLI mode: python groq_hybrid_agent.py "Profile the ORDERS table" The agent reasons, executes, and answers — all within your data governance boundary. No data leaves Snowflake. The LLM only sees query results, never raw data. Youtube Demo : https://medium.com/media/d4eaa4921058f2df6a7200ab07a67657/href Implementation verified on Snowflake account FQDRZOE-SD47007 (July 22, 2026). Groq hybrid agent tested with Llama 3.3 70B. All procedures and guardrails passing. Full source code in the Github cortex-coding-agent project. This article represents the author’s personal views and experience, not those of any employer. 👏 Clap if it added value 🔗 Share it with your team ➕ Follow for more 📘 Medium: Satish Kumar 🔗 LinkedIn: satishkumar-snowflake Stay tuned for the next one! 👋 Building a Production-Grade Coding Agent on Snowflake: From Trial Account to Enterprise Deployment was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.