Das Warehouse bekommt eine Agent-Steuerungsebene: Snowflakes thinking_effort, stage_mounts und dbts Agents Schema

Am 28. Oktober 2026 hat Snowflake drei neue Kontrollen auf der agent:run-API von Cortex Agents ausgeliefert: thinking_effort, instructions.system und stage_mounts (Snowflake Release Notes). Eine Warehouse-Runtime legt jetzt die drei Dinge offen, die Agenten-Plattformen traditionell für sich behalten — wie intensiv das Modell denkt, welche Hausregeln die Runtime durchsetzt und welche versionierten Artefakte der Agent einhängen darf. Im selben Monat haben Fivetran und dbt Labs ihre Fusion abgeschlossen, um „die Dateninfrastruktur für vertrauenswürdige KI-Agenten zu schaffen", und die zusammengeführte Plattform trägt ein Agents Schema, das Agenten Warehouse-nativen Kontext statt Ad-hoc-Extrakten gibt (Fivetran-Pressemitteilung).

Dieser Artikel kartografiert die drei Snowflake-Kontrollflächen, die daneben angeschlossene Kontextschicht und die Grenze, die sie nicht schließen: Freigaben, systemübergreifende Richtlinien und die Audit-Spur bleiben bei der Orchestrierungsschicht über dem Warehouse. Für ein Lean-Team — ein Snowflake-Account, zwei dbt-Entwickler, Agenten, die anfangen, geplante Arbeit auszuführen — sind das die ersten Stellschrauben, die Sie im Warehouse selbst setzen können, und zu wissen, was sie binden und was nicht, ist der Unterschied zwischen Governance und Theater.

Kernaussagen

• Snowflake lieferte am 28. Oktober 2026 drei Agent-Kontrollen aus — thinking_effort (von minimal bis xhigh, modellspezifische Teilmengen), instructions.system (Systeminstruktionen, die innerhalb der Runtime angehängt werden) und stage_mounts (versionierte Stage-Mounts) auf der agent:run-API von Cortex (Snowflake Release Notes).
• stage_mounts bindet Artefakte an Versionen, nicht an Branches — Notebooks, Streamlit-Apps, Workspaces und Agenten selbst werden als versionierte Stages gemountet; beschreibbare workspace_mounts bleiben unverändert auf Version live (Snowflake Release Notes).
• Die abgeschlossene Fusion von dbt und Fivetran liefert das Agents Schema — der erklärte Zweck der zusammengeführten Plattform ist „die Dateninfrastruktur für vertrauenswürdige KI-Agenten", die governierten Kontextzeilen dorthin bringt, wo Agenten sie konsumieren (Fivetran-Pressemitteilung).
• Das dbt × Amazon Redshift Daten-Sharing (von dbt am 9. Oktober und von AWS im Big-Data-Blog dokumentiert) betreibt Multi-Cluster-Pipelines, ohne ein Byte zu bewegen — governierte Shares plus SVV_*-Metadaten-APIs und eine datasharing-Konfiguration ersetzen Extrahieren-und-Kopieren (dbt-Blog; AWS Big-Data-Blog).
• Die Stellschrauben binden Aufwand, Instruktionen und Mounts — nicht Richtlinien — Freigaben, Widerruf und Audit über Warehouse, NetSuite, HubSpot und den Rest der Agenten-Reichweite bleiben in der Orchestrierungsschicht.

Was am 28. Oktober ausgeliefert wurde — und wo jede Kontrolle sitzt

thinking_effort ist der Knopf für die Denk-Intensität: ein Bereich von minimal bis xhigh, mit modellspezifischen Teilmengen, die einschränken, welche Werte ein bestimmtes Modell akzeptiert. Praktisch ist das der Aufruf, der den Modelleffort von API-seitigem Standard in eine pro-Lauf-Einstellung verschiebt, die das Warehouse protokolliert. Ein geplanter Agent, der eine Freshness-Tabelle liest, braucht nicht dasselbe Aufwandsbudget wie einer, der Rechnungspositionen abgleicht; bis zum 28. Oktober lebte diese Unterscheidung in dem Harness, der das Modell aufrief — jetzt führt das Warehouse sie als deklarierten Parameter des Laufs aus.

instructions.system hängt Systeminstruktionen innerhalb der Runtime an. Das ist der Slot für die Hausrichtlinien: die Arbeitsregeln, die Ihre Organisation an jeden Agentenlauf anhängen will — was der Agent zusammenfassen darf, was er einem Menschen markieren muss, wie er mit fehlendem Kontext umgehen soll — wandern mit dem Aufruf, statt in einem Prompt-Template zu liegen, das gerade derjenige pflegt, der den Agenten gebaut hat. Der Ehrlichkeitsmarker zählt hier: angehängte Instruktionen sind kein Berechtigungssystem. Sie formen das Verhalten innerhalb der Runtime; sie widerrufen nichts.

stage_mounts ist die Artefakt-Grenze. Die agent:run-API akzeptiert jetzt versionierte Stage-Mounts — Notebooks, Streamlit-Apps, Workspaces und die Agenten selbst — während beschreibbare workspace_mounts unverändert auf Version live bleiben. Ein an eine versionierte Stage gebundener Agent sieht einen angepinnten Artefakt-Satz, nicht das, was gerade auf dem Branch liegt. Das ist derselbe Instinkt wie Pipeline-Pinning und Manifest-Pinning an anderen Stellen des Agenten-Stacks, ausgedrückt an der Warehouse-Grenze, an der die Artefakte tatsächlich leben.

Das Diagramm unten stellt die drei Kontrollflächen den Schichten darüber und darunter gegenüber — der Orchestrierungsschicht, wo die Richtlinie bleibt, und den darunter ankommenden Kontext- und Bewegungsschichten.

Die Kontextschicht kam zuerst

Kontrollen zählen nur gegen etwas, und dieses Etwas kam zuerst auf der Kontextseite an. Fivetran und dbt Labs haben ihre Fusion mit einer expliziten These abgeschlossen: Die kombinierte Firma existiert, um „die Dateninfrastruktur für vertrauenswürdige KI-Agenten" zu bauen (Fivetran-Pressemitteilung). Das Agents Schema trägt diese These ins Warehouse — governierte, modellierte Zeilen, die ein Agent konsumiert wie ein Dashboard eine Metrics-Tabelle konsumiert, statt des Ad-hoc-Extrakts, den ein Agent durch Ausprobieren gegen einen SQL-Endpoint zusammensetzt.

Die Bewegungsfrage wird gleich behandelt. dbt unterstützt jetzt Amazon-Redshift-Daten-Sharing, und AWS' Big-Data-Blog dokumentiert das Multi-Cluster-Muster — SVV_*-Metadaten-APIs und eine datasharing-Konfiguration, die Multi-Cluster-Pipelines bauen, ohne ein Byte zu kopieren (dbt-Blog; AWS Big-Data-Blog). Für einen Agenten ist das der Unterschied zwischen einer Umgebung, die aus governierten Shares — wo Lineage und Zugriffsregeln halten — zusammengesetzt wird, und einer aus Extrakten, wo jede Kopie eine neue Zugriffsfrage ist. Dagsters Neupositionierung um dieselbe These („Data your team trusts. AI that runs on it.") sagt dasselbe von der Orchestrator-Seite des Zauns (Dagster).

Zusammen gelesen bilden die drei Flächen ein Muster: Kontext wird dort governiert, wo er modelliert wird; Bewegung dort, wo sie geteilt wird; und Aufwand, Instruktionen und Mounts dort, wo der Lauf passiert. Das ist eine Warehouse-First-Antwort auf eine Frage, die Agenten-Plattformen bislang mit maßgeschneidertem Code beantwortet haben.

Was die Stellschrauben offen lassen

Was die Kontrollen nicht binden, ist die Richtlinie über Systeme hinweg. Ein Agent, der Warehouse-Preismodelle liest, BigCommerce-Bestand prüft und genehmigte Angebote nach NetSuite zurückschreibt, überschreitet drei Anbieter-Grenzen und eine Protokoll-Grenze. Die Snowflake-Parameter governieren genau eine dieser Grenzen; nichts in den Release Notes widerruft ein BigCommerce-Token, und nichts in instructions.system erzeugt einen Audit-Eintrag in NetSuite. Freigaben, Widerruf und die einzige systemübergreifende Audit-Spur müssen bei der Orchestrierungsschicht wohnen — dem Modulmuster, das jedes System als typisierte Tools mit eigener Authentifizierung und Protokollierung verpackt (MCP-Modulcode-Standard).

Es gibt eine ehrliche Grenze, die man klar benennen sollte: Die Release Notes dokumentieren Parameter, keine Garantien. Das Audit-Verhalten von agent:run-Aufrufen — was protokolliert, aufbewahrt und abfragbar wird — spezifizieren die von uns geprüften Notes nicht, und die Unterstützung modellspezifischer Teilmengen bedeutet, dass das xhigh des einen Teams die nicht verfügbare Einstellung des anderen ist. Behandeln Sie die drei Kontrollen als deklarierte Eingaben, verifizieren Sie die Audit-Spur auf Ihrem Account, und lassen Sie den Kill-Switch über dem Warehouse (KI-Governance-Checkliste).

Eine Lean-Team-Lektüre

Für ein Mid-Market-Team, das seine ersten geplanten Agenten gegen das Warehouse laufen lässt, verändert der 28. Oktober das Ausgangsgespräch an fünf Stellen. Inventarisieren Sie, welche Agenten überhaupt das Warehouse berühren — geplante zuerst. Setzen Sie thinking_effort bewusst pro Workload: ein Freshness-Check auf minimal, Abgleiche mit höherer Intensität, und notieren Sie, welche Aufgabe welches Budget bekam — denn diese Zuordnung ist Ihre Story zu den Stückkosten. Legen Sie die Hausrichtlinien einmal in instructions.system ab, statt sie über jedes Prompt-Template hinweg zu pflegen. Binden Sie geplante Agenten an versionierte Stage-Mounts, damit das Streamlit-Dashboard, das der Agent liest, die Version ist, die jemand getestet hat — nicht die, die sich heute Morgen geändert hat. Und halten Sie Freigaben und Widerruf im Manifest des Orchestrators — das Warehouse kontrolliert, wie ein Lauf aussieht; der Orchestrator kontrolliert, was ein Lauf tun darf und was er hinterlässt.

Weiterlesen

• Agentengesteuerte Datenpipelines: Aufbau des Dagster + dbt + MCP-Stacks — das Pendant auf der Build-Seite: Dagster, dbt und Snowflake als typisierte Tools verpacken, die der Agent aufruft
• Kaskadierende Pipeline-Ausfälle: Wie ein Agent den On-Call-Aufwand um 75% senkt — die Monitoring-Schicht, die diese Kontrollen speisen, mit dem 8-Stunden-auf-2-Stunden-Record
• MCP-Modulcode-Standard — das strukturelle Muster, das Authentifizierung, Protokollierung und Richtlinien beim Orchestrator über jedes System hält

---

Ein Ausrüstungsdistributor mit 400 Mitarbeitern, einem Snowflake-Account und zwei dbt-Entwicklern verband gerade seinen Angebotsagenten mit den vom Warehouse governierten Preismodellen. Ein Orchestrator-Modul deklarierte die drei Snowflake-Kontrollen — Aufwand pro Workload budgetiert, Hausrichtlinien bei jedem Lauf angehängt, versionierte Stage-Mounts für die Artefakte, die der Agent liest — während Freigaben, Widerruf und die systemübergreifende Audit-Spur im Manifest über dem Warehouse blieben. Die Kosten des Angebotsagenten wurden pro Aufgabe zuordenbar, und seine Datenumgebung trieb nicht länger mit dem Branch davon.

Scope-gebundenes Build anfragen

Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Scope — ob Sie mit uns bauen oder nicht.