Skip to content
Skadi Labs

PRODUCT · HOW SKADI WORKS

A native app that does analysis — and keeps what it learns.

Skadi installs from a listing into your own Snowflake account and runs there as a container service. This page walks the architecture, the learning loop, the memory model, and the console — and ends with exactly where the build stands.

ARCHITECTURE

Everything inside the line.

Skadi ships as a Snowflake Native App with containers. The agent runtime — gateway, control loop, memory manager, skill pipeline, safety hooks — runs on Snowpark Container Services inside your account. It reasons with Claude hosted in-perimeter by Snowflake Cortex, queries through Cortex Analyst and Cortex Search, and writes all of its state — memory, skills, sessions, audit events — to tables in its own application schema. That state survives upgrades and is never shared outside your account.

One thin line crosses the boundary: the Slack messages you ask it to send. Nothing else leaves.

Skadi's architecture: everything runs inside your Snowflake account, with one approved Slack egress.Your Snowflake account contains the Skadi control plane, Cortex AI services, and the state layer where all memory, skills, sessions, and audit events are stored. An External Access Integration governs the one path that leaves the account: a thin, consumer-approved Slack egress connection. Nothing else crosses the boundary.YOUR SNOWFLAKE ACCOUNTSKADI CONTROL PLANEGATEWAY / ROUTER · AGENT ENGINE(CORTEX CODE AGENT SDK)MEMORY MANAGER · SKILL PIPELINESAFETY HOOKS · SCHEDULERWEB CONSOLECORTEX AI SERVICESCORTEX ANALYST · CORTEX SEARCHAGENT SKILLSCLAUDE · IN-PERIMETERSTATE LAYERmemory_core · memory_episodes ·skills · sessions · audit_eventsEXTERNAL ACCESS INTEGRATIONNetwork rule + secret binding —the sanctioned egress gate.EGRESS · *.slack.com:443 ·CONSUMER-APPROVEDSLACK

Your Snowflake account contains the Skadi control plane, Cortex AI services, and the state layer where all memory, skills, sessions, and audit events are stored. An External Access Integration governs the one path that leaves the account: a thin, consumer-approved Slack egress connection. Nothing else crosses the boundary.

  • SKADI CONTROL PLANE: Gateway/router, agent engine, memory manager, skill pipeline, safety hooks, scheduler, and the served web console all run inside your Snowflake account.
  • CORTEX AI SERVICES: Cortex Analyst, Cortex Search, Agent Skills, and Claude hosted in-perimeter by Snowflake Cortex — reasoning and retrieval stay inside the boundary.
  • STATE LAYER: memory_core, memory_episodes, skills, sessions, and audit_events are tables in the app's own schema, inside your account.
  • EXTERNAL ACCESS INTEGRATION: Binds the network rule and credentials that gate the one allowed egress path.
  • EGRESS: Exactly one connector crosses the boundary: a thin Slack egress line to *.slack.com:443, consumer-approved. Nothing else leaves.

THE SKILL LOOP

From one good answer to a reusable skill.

Here's the loop end to end, using the same episode as the homepage. The mechanism is the product; the numbers are illustrative.

  1. EPISODE

    Someone asks in Slack: "Why did Q2 gross margin dip in EMEA?" Skadi plans, runs six tool calls — semantic-view SQL through Cortex Analyst, a memory lookup, an FX-adjusted re-query — and answers with a margin bridge.

    #finance-analytics · slack

    d.reyes09:41

    Why did Q2 gross margin dip in EMEA?

    skadi09:43

    EMEA gross margin fell 240 bps in Q2. Three drivers: FX (−130 bps), freight (−80 bps), one distributor rebate (−30 bps). Full bridge below.

    6 tool calls · 94 s · view trace
    1 skill_search    "margin bridge emea" → no match
    2 memory_search   d.reyes · margin preferences
    3 cortex_analyst  sql · finance margin semantic view
    4 cortex_analyst  re-query · fx-adjusted · emea only
    5 memory_write    tier-3 · "fx-adjust before comparing regions"
    6 learn_skill     episode flagged learnable → skill drafted
  2. DETECT

    The session trips the learnable-episode heuristics: multiple tool calls, a user correction absorbed. Skadi drafts `margin_bridge.skill` — a `SKILL.md` plus parameterized SQL. A proposal, not live code.

  3. VERIFY

    The draft runs the verification gate: executable dry-run checks against the semantic view — does it parse, does it run, does it return the declared shape. Not an LLM grading its own homework.

  4. APPROVE ●

    The skill lands in the console's approval queue with a mono diff and the scanner's results. A human approves, revises, or rejects. High-blast-radius skills always wait for a person.

  5. PROMOTE

    Approved skills are versioned into the skill store with full provenance and indexed for retrieval. Next time a similar question arrives, Skadi finds the skill by intent and runs it — six calls become one.

  6. CURATE

    On a schedule, the store gets tended: duplicates merged, stale skills archived, regressions checked.

    Curation is the least-built stage today — see §3.6.

MEMORY

Three tiers, no hidden state.

Memory lives in Snowflake tables, per user, isolated per user. Tier 1 is a small frozen core block injected at session start and edited only via audited tool calls. Tier 2 is full session history, searchable by hybrid retrieval. Tier 3 is a synthesized model of how you work, ranked by recency, importance, and relevance. High-signal items are promoted upward by a scheduled consolidation process. Every write carries provenance — and the whole thing renders as files (`USER.md`, `MEMORY.md`) you can open in the console.

USER.md · tier-1 core · 1,204 tokens · frozen

role:
revenue ops lead · emea
prefers:
margin in bps · quarters not months
corrections:
fx-adjust before comparing regions
(2026-06-12 · d.reyes)
last_edit:
2026-07-02 · audited tool call

PER-USER · PROVENANCE LOGGED · INSPECTABLE

THE CONSOLE

Built to be watched.

The web console runs inside the app. Four views tell the story:

Skadi console screenshot: the Cortex agent loop streaming intake, tool calls, and query results in monospace during a live session.

Chat / agent loop

The loop, live: intake → tool → result → propose → reply, streamed in monospace as it happens.

Skadi console screenshot: the skill approval queue showing a proposed skill's scanner results and mono diff, with Approve, Revise, and Reject actions.

Skills — approval queue

Every self-written skill waits here: scanner results, a mono diff, and Approve / Revise / Reject.

Skadi console screenshot: the core memory panel rendering USER.md and MEMORY.md as plain, readable files.

Memory

`USER.md` and `MEMORY.md`, rendered raw. What Skadi knows about you is a file, not a feeling.

Skadi console screenshot: the audit log view's honest v1 state, noting that every governed action is recorded server-side.

Audit log

Every action, attributed and timestamped, backed by Snowflake-native audit.

STATUS · 2026-07

Where the build actually is.

Skadi is in research and build. A working end-to-end demo — Slack and web chat, skill learning with approval, tiered memory, audit — shipped in June 2026 and runs in a live Snowflake account. We're now building toward a Snowflake Marketplace listing.

What's honestly not done:

  • Per-user least privilege via Restricted Caller's Rights is designed but not yet demonstrated — the current demo runs single-user, under owner's rights.
  • The curation back-half of the skill loop (dedup, regression suite) is deferred.
  • Some Cortex features we depend on are in preview from Snowflake.
  • Always-on container compute costs real money while idle; the design mitigates with wake-on-schedule patterns, and this is an active engineering area.

No customers yet, no GA date to announce. That's what design partners are for.