L'entrepôt gagne une surface de contrôle d'agent : thinking_effort, stage_mounts de Snowflake et Agents Schema de dbt

Le 28 octobre 2026, Snowflake a livré trois nouveaux contrôles sur l'API agent:run de Cortex Agents : thinking_effort, instructions.system et stage_mounts (notes de publication Snowflake). Un runtime d'entrepôt expose désormais les trois choses que les plateformes d'agents gardaient traditionnellement pour elles — à quel point le modèle réfléchit, quelles règles de maison le runtime applique, et quels artefacts versionnés l'agent peut monter. Le même mois, Fivetran et dbt Labs ont achevé leur fusion « pour créer l'infrastructure de données des agents IA de confiance », et la plateforme combinée embarque un Agents Schema qui donne aux agents du contexte natif entrepôt au lieu d'extraits ad hoc (communiqué de presse Fivetran).

Cet article cartographie les trois surfaces de contrôle Snowflake, la couche de contexte qui arrive à leurs côtés, et la frontière qu'elles ne ferment pas : les approbations, la politique inter-outils et la piste d'audit dépendent toujours de la couche d'orchestration située au-dessus de l'entrepôt. Pour une équipe resserrée — un compte Snowflake, deux développeurs dbt, des agents commençant à exécuter du travail planifié — ce sont les premiers boutons que vous pouvez régler à l'intérieur même de l'entrepôt, et savoir ce qu'ils lient et ce qu'ils ne lient pas fait la différence entre la gouvernance et le théâtre.

Points clés

• Snowflake a livré trois contrôles d'agent le 28 octobre 2026 — thinking_effort (de minimal à xhigh, sous-ensembles par modèle), instructions.system (instructions système ajoutées à l'intérieur du runtime) et stage_mounts (montages de stages versionnés) sur l'API agent:run de Cortex (notes de publication Snowflake).
• stage_mounts lie les artefacts par version, pas par branche — notebooks, applications Streamlit, espaces de travail et agents se montent comme des stages versionnés ; les workspace_mounts inscriptibles restent inchangés en version live (notes de publication Snowflake).
• La fusion achevée de dbt et Fivetran livre l'Agents Schema — l'objet énoncé de la plateforme fusionnée est « l'infrastructure de données pour des agents IA de confiance », plaçant des lignes de contexte gouvernées là où les agents les consomment (communiqué de presse Fivetran).
• Le partage de données dbt × Amazon Redshift (documenté par dbt le 9 octobre et par AWS sur son blog big data) fait tourner des pipelines multi-cluster sans déplacer un octet — des parts gouvernées plus les API de métadonnées SVV_* et une config datasharing remplacent le cycle « extraire puis copier » (blog dbt ; blog big data AWS).
• Les boutons lient l'effort, les instructions et les montages — pas la politique — les approbations, la révocation et l'audit à travers l'entrepôt, NetSuite, HubSpot et le reste de la portée de l'agent restent dans la couche d'orchestration.

Ce qui a été livré le 28 octobre, et la couche de chaque contrôle

thinking_effort est le bouton d'effort de raisonnement : une gamme allant de minimal à xhigh, avec des sous-ensembles par modèle qui contraignent les valeurs acceptées par un modèle donné. En pratique, c'est l'appel qui fait passer l'effort du modèle d'un défaut côté API à un réglage par exécution que l'entrepôt enregistre. Un agent planifié qui lit une table de fraîcheur n'a pas besoin du même budget d'effort que celui qui rapproche des lignes de facture ; avant le 28 octobre, cette distinction vivait dans le harnais qui invoquait le modèle, et maintenant l'entrepôt l'exécute comme paramètre déclaré de l'exécution.

instructions.system ajoute des instructions système à l'intérieur du runtime. C'est le logement de la politique de maison : les règles de fonctionnement que votre organisation veut attacher à chaque exécution d'agent — ce que l'agent peut résumer, ce qu'il doit signaler à un humain, comment traiter un contexte manquant — voyagent avec l'invocation au lieu de dormir dans un template de prompt entretenu par qui que ce soit. Le marqueur d'honnêteté compte ici : des instructions ajoutées ne sont pas un système d'autorisations. Elles façonnent le comportement à l'intérieur du runtime ; elles ne révoquent rien.

stage_mounts est la frontière des artefacts. L'API agent:run accepte désormais des montages de stages versionnés — notebooks, applications Streamlit, espaces de travail et les agents eux-mêmes — tandis que les workspace_mounts inscriptibles restent inchangés en version live. Un agent lié à un stage versionné voit un ensemble d'artefacts épinglé, et non ce qui se trouve sur la branche à cet instant. C'est le même instinct que le pinning de pipeline et le pinning de manifeste ailleurs dans la pile d'agents, exprimé à la frontière de l'entrepôt où vivent réellement les artefacts.

Le diagramme ci-dessous confronte les trois surfaces de contrôle aux couches qui les entourent — la couche d'orchestration où la politique reste, et les couches de contexte et de mouvement qui arrivent en dessous.

La couche de contexte est arrivée d'abord

Les contrôles n'ont de sens que par rapport à quelque chose, et ce quelque chose est arrivé côté contexte. Fivetran et dbt Labs ont clos leur fusion avec une thèse explicite : la société combinée existe pour construire « l'infrastructure de données pour des agents IA de confiance » (communiqué de presse Fivetran). L'Agents Schema porte cette thèse dans l'entrepôt — des lignes gouvernées et modélisées que l'agent consomme comme un tableau de bord consomme une table de métriques, plutôt que l'extrait ad hoc qu'un agent assemble à tâtons contre un point de terminaison SQL.

La question du mouvement reçoit le même traitement. dbt prend désormais en charge le partage de données Amazon Redshift, et le blog big data d'AWS documente le modèle multi-cluster — des API de métadonnées SVV_* et une config datasharing qui construisent des pipelines multi-cluster sans copier un octet (blog dbt ; blog big data AWS). Pour un agent, c'est la différence entre un environnement assemblé à partir de parts gouvernées — où la lignée et les règles d'accès tiennent — et un environnement assemblé à partir d'extraits, où chaque copie est une nouvelle question d'accès. Le repositionnement de Dagster autour de la même thèse (« Data your team trusts. AI that runs on it. ») dit la même chose du côté orchestrateur de la clôture (Dagster).

Lus ensemble, les trois surfaces forment un seul motif : le contexte est gouverné là où il est modélisé, le mouvement est gouverné là où il est partagé, et l'effort, les instructions et les montages sont gouvernés là où l'exécution a lieu. C'est une réponse « entrepôt d'abord » à une question que les plateformes d'agents répondaient avec du code sur mesure.

Ce que les boutons laissent ouvert

Ce que les contrôles ne lient pas, c'est la politique entre les systèmes. Un agent qui lit des modèles de prix d'entrepôt, vérifie le stock BigCommerce et reporte les devis approuvés dans NetSuite franchit trois frontières de fournisseurs et une frontière de protocole. Les paramètres Snowflake ne gouvernent qu'une seule d'entre elles ; rien dans les notes de publication ne révoque un token BigCommerce, et rien dans instructions.system ne produit un enregistrement d'audit dans NetSuite. Les approbations, la révocation et la piste d'audit inter-outils unique doivent vivre dans la couche d'orchestration — le motif de module qui emballe chaque système en outils typés avec leur propre authentification et journalisation (standard de code des modules MCP).

Il y a une limite honnête à énoncer clairement : les notes de publication documentent des paramètres, pas des garanties. Le comportement d'audit des appels agent:run — ce qui est journalisé, conservé et interrogeable — n'est pas précisé dans les notes que nous avons examinées, et la prise en charge de sous-ensembles par modèle fait que le xhigh d'une équipe est le réglage indisponible d'une autre. Traitez les trois contrôles comme des entrées déclarées, vérifiez la piste d'audit sur votre compte, et gardez le kill-switch au-dessus de l'entrepôt (liste de contrôle de gouvernance IA).

Lecture pour une équipe resserrée

Pour une équipe du mid-market qui fait tourner ses premiers agents planifiés contre l'entrepôt, le 28 octobre change la conversation de mise en route à cinq endroits. Inventoriez les agents qui touchent l'entrepôt — les planifiés d'abord. Réglez thinking_effort consciemment par charge de travail : un contrôle de fraîcheur en minimal, le rapprochement à un effort plus élevé, et notez quelle tâche a reçu quel budget, car cette correspondance est votre histoire de coût par unité. Placez la politique de maison dans instructions.system une fois, au lieu de la maintenir dans chaque template de prompt. Liez les agents planifiés à des montages de stages versionnés, pour que le tableau de bord Streamlit que l'agent lit soit la version que quelqu'un a testée, pas celle qui a changé ce matin. Et gardez les approbations et la révocation dans le manifeste de l'orchestrateur — l'entrepôt contrôle à quoi ressemble une exécution ; l'orchestrateur contrôle ce qu'une exécution a le droit de faire et laisse derrière elle.

Pour aller plus loin

• Pipelines de données orchestrés par agents : construire la pile Dagster + dbt + MCP — l'équivalent côté construction : emballer Dagster, dbt et Snowflake comme des outils typés que l'agent appelle
• Pannes en cascade : comment un agent réduit le debugging d'astreinte de 75% — la couche de monitoring que ces contrôles alimentent, avec le record d'astreinte 8 heures à 2
• Standard de code des modules MCP — le motif structurel qui garde l'authentification, la journalisation et la politique à l'orchestrateur, sur chaque système

---

Un distributeur d'équipements de 400 personnes avec un compte Snowflake et deux développeurs dbt reliait son agent de devis aux modèles de tarification gouvernés par l'entrepôt. Un module d'orchestrateur déclarait les trois contrôles Snowflake — effort budgété par charge de travail, politique de maison ajoutée à chaque exécution, montages de stages versionnés pour les artefacts que l'agent lit — tandis que les approbations, la révocation et la piste d'audit inter-outils restaient dans le manifeste au-dessus de l'entrepôt. Les coûts de l'agent de devis sont devenus attribuables par tâche, et son environnement de données a cessé de dériver avec la branche.

Demander un cadrage

Une semaine de cadrage. Vous obtenez un inventaire des systèmes, une carte des workflows et un périmètre fixe — que vous construisiez avec nous ou non.