Moving from insight to execution — inside Snowflake

Snowflake can now generate decisions.

With Cortex and internal models, systems are starting to produce outputs that look like actions — not just insights.

The question is no longer whether Snowflake can decide.

It is what governs execution when it does.

---

Acting on decisions inside Snowflake

The moment you try to act on those decisions inside Snowflake, something becomes obvious.

You can generate a result that clearly represents an action.

But turning that into something real — something that updates a system, changes a budget, or triggers a workflow — requires stepping outside.

Once you step outside, you lose the structure that Snowflake gives you:

• There is no clear boundary where the action is evaluated.
• There is no consistent way to require approval.
• There is no shared record of what was allowed or why.

Execution becomes ad hoc again.

This is where most teams stop trusting the system.

---

When the decision lives as data

You now have a row in Snowflake that effectively represents an action.

At that point, teams typically:

• call an API directly
• wire up a script
• or route it through Slack

All of which work.

But none of which feel like they belong in the system that produced the decision.

If you are doing this today, it probably looks like:

• a query produces a result
• it gets wired to an API or script
• approvals happen outside the system

---

The gap

Snowflake recently described the idea of an agentic control plane.

Cortex can now generate actions.

But something still needs to sit between that decision and real-world execution.

---

Where Tessra sits

Tessra sits between the decision generated inside Snowflake and the external system where execution happens.

This is the role of a SQL-native execution layer: request actions from the data system, govern them before they run, and record the outcome where the decision began.

An action is requested from Snowflake.

From there:

• it is evaluated against policy
• it may require approval (email or Slack)
• it executes against an external system
• and the result is recorded back in Snowflake

Everything is visible in one place — not only what happened, but what was intended, what was allowed, and what was approved.

You trigger an action from Snowflake, approve it via email, and see the result reflected back in the same environment.

---

Extension of the data system

This behaves like a natural extension of the data system:

• initiated from Snowflake
• governed with structured rules
• observable after execution

---

See it work end-to-end inside Snowflake

Same three-minute walkthrough as on the tessra.ai homepage.

---

When this shows up

Teams hit this boundary almost immediately.

If you are using Snowflake and starting to:

• connect model outputs to workflows
• push decisions into external systems
• think about write-backs or automation

you need a deliberate answer for execution.

If you're using Snowflake and want to run one real action through this (refund, spend change, workflow), I'm opening this up to a small set of teams right now.

Reach out: [email protected]

Try it: Quickstart (run your first action)

This is not about adding another service.

It is about restoring a boundary that should exist in the system.