The governance layer between AI agents and Snowflake

The AI-oriented business architecture

Airlock sits within your Snowflake environment and is the entrypoint for the AI agents and humans doing the work.

Those agents can be performing work on local devices, on cloud servers, or even inside Snowflake itself—but they all read from and write to your system of record through Airlock.

That enables an agent-oriented architecture: tools and experiences at the edge can be lightweight, bespoke, or temporary, while what stays durable is governed—output contracts, validations, permissions, workflow state, and centrally retained records in Snowflake.

Execution can be distributed; business truth must be centralized, recognized, and governed. The aim is outcomes, not infrastructure: move fast in the cognition layer without losing control of what becomes official.

• System-of-record layer: Snowflake is the central system-of-record for official records, shared context, and historical outputs.
• Governance layer: Airlock communicates and enforces the rules that define valid submissions, permissions, and workflow policy.
• Cognition layer: humans and AI agents interpret context, make judgments, and produce work.

The key idea is stable across eras: cognition stays flexible, while governance and recordkeeping stay centralized.

This architecture is not new

It may feel new, because we are used to having applications perform governance and system-of-record for us, and to treating Snowflake as a downstream analytics tool rather than the initial system of record. In reality, the split you see in the diagram is an old idea.

Long before computers, businesses understood that systems of record should not live in the sole possession of individual workers. Important records belonged on business premises, under business control, even while employees did their work-in-progress in notebooks, worksheets, drafts, and other personal working surfaces. Later, that same pattern carried into software: official data lived in company-controlled databases, while knowledge workers used local tools like spreadsheets, documents, and notes to iterate toward a final result before submitting it through sanctioned systems.

The AI era needs the same discipline. Modern agent tools make it far too easy for agents to accumulate important business context, intermediate outputs, and even data of record inside their own file systems, memory, or proprietary runtimes. That is convenient in the short term, but dangerous in the long term. Businesses should not have critical records, logic, or workflow state stranded inside any individual human or agent.

Airlock, together with Snowflake and AI agents, is simply an implementation of this age-old pattern for an agent-enabled world. Snowflake serves as the central system-of-record. Airlock communicates and enforces the data and access rules. The specifications, permissions, interfaces, and controls let agents work flexibly while still checking inputs and outputs into a centrally governed environment.

That balance is important because real knowledge work has never been purely standardized. Organizations aim for predictability through standard inputs and outputs, but much of the actual work happens in a messy layer of improvisation, interpretation, and iteration. Historically, that “black box” lived on a worker’s desk in the form of handcrafted spreadsheets, sticky notes, and redrafted documents. In an AI-enabled organization, that same adaptive work happens inside and between agents. Airlock does not pretend to eliminate that reality. It makes it governable. It allows agents to experiment, transform, and adapt to changing context while ensuring that the business retains the durable assets: the data, the finalized outputs, the compliance records, the logs, and the operational continuity.

Workflows: agents can be shut out

Workflows move submitted files through states where agents (and users) can no longer alter or delete what was already submitted—so open collaboration can happen upstream, and the business can lock the record when it’s time.

Governance between agents

Airlock isn’t only a boundary between humans and models. It’s a governance layer between agents too.

For example: one agent, working for an employee, submits project reimbursements through a spec—dates, project codes, amounts, a receipt photo, whatever you require. Another agent, working for you, reads that submission, compares it against the financial, employee, and project data you choose to expose to your agent and carries processing forward—all on a controlled, auditable surface instead of ad hoc file drops or table sprawl.

That pattern is one of an open-ended set of flows you can build today with AI agents (including OpenClaw-style setups), Snowflake, and Airlock.

From off-the-shelf to bespoke

When governance moves into Airlock and the system of record lives in Snowflake, apps no longer need to carry every rule, approval path, and edge case forever. Teams can build focused experiences for the moment while still submitting governed outputs into a durable business-owned environment.

This is why the spec matters so much: it is orientation and enforcement at once. It teaches workers and agents what to produce, and it blocks submissions that do not satisfy the contract.

Prescribe the spec, not the app

You mandate the specification, not someone else’s product roadmap. Proposals, leads, reimbursements—each is a contract you define. You don’t need another formal app for every workflow: nail the spec, then meet it with whatever tool you and your agents can build and vibe-code together. Your AI agent can help you draft and tighten that spec, too.

Under the hood, Airlock handles schemas, validation, attachments, guest access where allowed, retention, and events—exposed through airlock.admin.* and airlock.user.* with Snowflake application roles and in-app roles at the boundary.

Why Snowflake and Native Apps matter

Snowflake gives the business a secure, enterprise-ready center for governed data and operational history. Native Apps keep the operating surface inside Snowflake, reducing extra SaaS overhead: fewer separate auth flows, fewer integration boundaries, fewer moving parts, and less operational drag.

With Airlock, Snowflake can be more than a downstream analytics destination. It can serve directly as the governed system of record for workflows carried out by humans and AI agents.

Design principles

• The system of record belongs to the business: durable records should not be stranded in agent-local state.
• Adaptive work is allowed: improvisation at the edge is expected; official state is governed at submission.
• Workers are replaceable, organization is durable: contracts, workflows, and records must outlive any single human, model, or vendor.
• Current and history both matter: preserve latest usable state and the historical trail needed for audit and recovery.

Who it is for

• Leaders hiring AI-fluent builders who move fast, ship purpose-built tools, and still need enterprise-grade storage and policy
• Teams integrating agents (including OpenClaw-ready workflows) against a stable, documented procedure surface
• BI and SQL users who prefer predictable CALL shapes over ad hoc table access
• Admins configuring roles, specs, templates, references, retention, and licensing via airlock.admin.*

Documentation

The Airlock docs include the full Stored Procedure API v1 reference (admin and user schemas, compatibility rules, and common workflow examples). Agents do not need to scrape website docs to work safely with Airlock.

In Snowflake, the installed app can return the bundled contract as UTF-8 markdown (one line per row):

CALL airlock.user.documentation();