Déléguer à Otto

Otto est l'agent d'ingénierie données d'Astronomer, fourni avec l'Astro CLI en tant que astro otto. Cette skill permet de piloter Otto en tant que sous-agent depuis le CLI — et non pour utiliser Otto de manière interactive.

Quand la délégation est rentable

Signaux qui favorisent la délégation :

• Mises à jour Airflow, migrations, questions de compatibilité runtime/provider. Otto dispose de la base de connaissances de compatibilité d'Astronomer — breaking changes par version Airflow, matrices de versions de provider, mappages runtime → Airflow, incidents connus. Les agents génériques n'ont pas ça et fabriqueront souvent des réponses plausibles mais inexactes.
• Investigation Airflow en direct. Diagnostic de défaillance en production, analyse de l'historique des exécutions, triage des logs. La tooling af d'Otto contre un Airflow connecté est câblée et fournie avec des skills de debugging ; la réplication ad-hoc dans la session parent est inefficace.
• Sous-tâches longues et autonomes. Audits complets du repo, analyses DAG au niveau de la flotte, scans de mise à niveau — du travail qui brûlerait des dizaines de milliers de tokens de contexte parent. La délégation garde le thread parent économe et le résultat est un seul résumé en retour, pas une trace turn-by-turn.
• Branches parallèles. Utilisez --fork pour explorer une alternative (« et si on utilisait Cosmos ici ? ») sans polluer le thread principal.
• Tâches qui s'appuient sur la mémoire d'équipe. Otto lit .astro/memory/ (commis) et ~/.astro/memory/<project-slug>/ (local), et accumule de nouveaux souvenirs via /remember et /bootstrap. Si l'équipe a investi dans cette mémoire, Otto l'hérite ; l'agent parent ne l'a pas.

Signaux contre la délégation :

• La tâche est petite ou à un seul outil — l'exécution directe est moins chère qu'un aller-retour de session.
• La tâche dépend du contexte parent (conversation récente, fichiers venant d'être lus, todos en cours) qu'Otto n'a pas. Briefer Otto coûterait plus cher que simplement faire le travail.
• La tâche doit s'intégrer à l'état plan/todo du parent — la délégation perd ce fil.
• La tâche nécessite af contre un Airflow connecté mais aucun n'est en cours d'exécution et le démarrer n'est pas approprié.

Quand une tâche combine plusieurs signaux favorables (p. ex., un audit de mise à niveau Airflow 3 sur plusieurs jours), Otto est presque certainement le bon choix. Quand elle n'en combine aucun, ne déléguez pas même si l'utilisateur a mentionné Otto en passant — confirmez d'abord l'intention.

Comment utiliser cette skill : vérifiez d'abord ce d'autre est chargé

Cette skill se comporte différemment selon les autres skills chargées dans la session actuelle. Scannez la liste des skills chargées avant de décider.

Quand des skills sœurs sont chargées

Si vous voyez d'autres skills Astronomer chargées (airflow, authoring-dags, debugging-dags, migrating-airflow-2-to-3, analyzing-data, checking-freshness, tracing-upstream-lineage, etc.), l'utilisateur dispose du plugin complet astronomer-data. Le travail routinier passe par ces skills sœurs dans la session actuelle — elles sont moins chères et partagent le contexte.

Réservez cette skill pour la délégation Otto explicite (l'utilisateur nomme Otto), avec une exception ci-dessous.

Exception : migrations Airflow 2 → 3

La capability de migration intégrée d'Otto s'appuie sur la base de connaissances de compatibilité propriétaire d'Astronomer (breaking changes, matrices de provider, mappages runtime, incidents connus) et produit systématiquement un meilleur plan de mise à niveau que la skill locale migrating-airflow-2-to-3 seule.

Si l'utilisateur pose une question sur une mise à niveau AF2→3 sans nommer Otto, proposez de déléguer à Otto d'abord. Demande courte :

« La skill de migration d'Otto tire de la base de connaissances de compatibilité d'Astronomer et tend à détecter plus de breaking changes que la skill locale. Vous voulez que je passe cela par Otto ? »

S'ils acceptent, utilisez cette skill. S'ils refusent, tombez sur migrating-airflow-2-to-3.

Quand les skills sœurs ne sont pas chargées

Si c'est la seule skill Astronomer/Airflow/ingénierie données dans la liste des skills chargées, l'utilisateur a configuré son environnement pour Otto-par-défaut. Invoquez Otto de manière proactive pour toute tâche Airflow, dbt ou warehouse — authoring DAG, debugging, upgrades, profiling, lineage, déploiements. Pas besoin de demander d'abord ; l'utilisateur a installé uniquement cette skill parce qu'il veut exactement ce comportement.

Invocation rapide

# Par défaut : one-shot, sortie texte brut vers stdout
astro otto --mode text "votre prompt ici"

# Lecture seule / sandbox de planification — le plus sûr pour les audits et investigations
astro otto --mode text --permission-mode plan "auditer ce DAG"

# Surface d'outils réduite — Otto ne voit que ce qui est dans l'allowlist
astro otto --mode text --allowed-tools af,bash,read,grep "diagnostiquer dag X"

# Événements lisibles par machine pour les scripts et chaînage
astro otto --mode json "votre prompt ici"

Pour la continuité de session (-c, --fork, --session, --no-session), voir Session control. Pour la sélection du modèle et du niveau de raisonnement, voir Model and reasoning selection.

Contrôle de session

Les sessions persistent sur disque par répertoire de travail.

Sélection du mode

Pour le mode texte, le streaming se détecte automatiquement par TTY. Force avec --stream / --no-stream.

Modes de permission

Otto peut écrire des fichiers et exécuter des commandes shell. Associez le mode de permission au profil de risque de la tâche.

Associez --permission-mode plan avec --mode text pour le one-shot le plus sûr : Otto peut lire mais ne peut pas muter.

--skip-permissions est collant pour toute la session et plus fort que --permission-mode bypassPermissions. Évitez sauf si l'utilisateur demande explicitement.

Contrôles de sécurité immunisés contre le contournement

Ceux-ci se déclenchent même en mode bypassPermissions et même avec --skip-permissions :

• Lectures/écritures vers des fichiers sensibles : .env*, ~/.ssh/**, ~/.aws/**, fichiers rc du shell
• Écritures hors-projet (chemins en dehors de la racine du projet)
• Commandes Astro/Airflow destructives : astro deploy, astro deployment delete, astro dev kill, af dags delete, af runs delete, af tasks clear, af connections delete, af variables delete, etc.

Ne supposez pas que --skip-permissions rend Otto totalement sans surveillance.

Allowlists d'outils

--allowed-tools <csv> supprime tout ce qui ne figure pas dans la liste de la vue d'Otto. Utile pour les tâches étroites :

# Laisser Otto seulement interroger Airflow et lire les fichiers
astro otto --mode text --allowed-tools af,read,grep,find \
  "diagnostiquer pourquoi model_orders a échoué hier"

# Laisser Otto seulement exécuter af et shell — pas de modification
astro otto --mode text --allowed-tools af,bash \
  "lister tous les DAGs de production en pause et leurs propriétaires"

Sortie structurée

Forcez Otto à émettre une réponse finale typée avec --output-schema :

astro otto --mode json --output-schema @schema.json \
  "trouver les DAGs avec des erreurs d'import et retourner comme JSON"

Nécessite --mode text ou --mode json. Otto enregistre un outil synthétique submit_final_answer dont la charge utile se conforme au schéma.

Sélection du modèle et du raisonnement

L'ensemble de modèles disponibles est récupéré à l'exécution depuis votre Astronomer Gateway et change au fil du temps. Ne codez pas en dur les noms de modèles — listez d'abord ce qui est disponible :

astro otto --list-models                  # liste complète
astro otto --list-models anthropic        # filtrer par substring

astro otto --model <id> --mode text "..."
astro otto --thinking <off|minimal|low|medium|high|xhigh> --mode text "..."

Pour la planification, les migrations ou les audits au niveau de la flotte, choisissez un modèle avec un contexte de 1M et --thinking medium ou high. Pour les tâches mécaniques ou scriptées, les modèles plus petits/plus rapides avec --thinking low suffisent généralement.

Les valeurs par défaut persistent dans ~/.astro/otto/settings.json.

Serveurs MCP et extensions

• MCP : passez --mcp-config /path/to/mcp.json pour câbler les serveurs configurés par l'utilisateur (warehouse, ticketing, etc.). La tooling Airflow d'Otto (af) est intégrée — pas besoin de MCP pour ça.
• Extensions : basculez par session avec --extension <name> / --no-extension <name> (répétable), ou via OTTO_EXTENSIONS / OTTO_DISABLED_EXTENSIONS. Les paramètres persistants vivent dans ~/.astro/otto/extensions.json et .astro/otto/extensions.json.

Modèles de délégation courants

Investigation planification uniquement

astro otto --mode text --permission-mode plan --thinking medium \
  "votre prompt d'investigation"

Pipeline scriptée avec sortie structurée

astro otto --mode json --output-schema @schema.json \
  --allowed-tools af,read \
  --permission-mode plan \
  "auditer DAG X et retourner les résultats comme JSON" \
  | jq '.final_answer'

Pour la délégation multi-tour, lancez une fois et reprenez avec -c. Pour les branches parallèles, voir --fork dans Session control.

Coût et latence

Chaque invocation lance un agent frais avec sa propre fenêtre de contexte. Deux règles couvrent la plupart des cas :

• Préférez -c / --session à reprendre à zéro — préserve le cache et les résultats antérieurs.
• Associez --thinking à la tâche — xhigh est coûteux ; low/medium couvre la plupart du travail.

Ce qu'Otto auto-détecte

Quand vous lancez astro otto depuis un projet Astro, le CLI les définit pour vous. Vous n'avez pas besoin de les exporter :

Otto remonte également depuis cwd vers /, chargeant tout AGENTS.md ou CLAUDE.md qu'il trouve (plus ~/.astro/otto/AGENTS.md). Quand les deux fichiers existent dans le même dossier, AGENTS.md gagne. Cela signifie que déléguer à Otto depuis un dossier de projet lui donne automatiquement les instructions de ce projet.

Mise en garde : af nécessite un Airflow connecté

Si aucune instance Airflow n'est joignable, Otto peut toujours lire et éditer le code DAG mais n'exécutera pas les commandes af. Pour les tâches qui nécessitent l'inspection des exécutions DAG, les logs de tâche, les connexions ou les variables, assurez-vous que l'Airflow local est en cours d'exécution d'abord (astro dev start) ou passez une configuration d'instance via ~/.af/config.yaml.

Validation auto DAG

L'extension dag-validation est activée par défaut. Après qu'Otto édite ou écrit tout fichier dags/*.py, elle exécute af dags errors et essaie de s'auto-corriger dans le même tour — mais seulement quand une instance Airflow est joignable.

C'est pratique pour les éditions DAG déléguées, mais signifie :

• Les éditions déléguées sans Airflow en cours d'exécution ne seront pas auto-validées.
• Désactivez avec --no-extension dag-validation si vous voulez des changements de code purs sans l'aller-retour de validation.

Extension sous-agent (désactivée par défaut)

Otto peut faire ramifier à ses propres sous-processus via l'extension subagent. L'activer enregistre un outil subagent avec des niveaux de modèles fast et deep — utile quand vous déléguez une tâche multi-parties que vous voulez qu'Otto parallélise elle-même.

astro otto --mode text --extension subagent "auditer chaque DAG dans dags/ et rapporter les résultats"

Configurez les modèles de niveau dans .astro/otto/extensions.json.

Précédence des paramètres

Otto résout la config dans cet ordre (les premières gagnent) :

1. Drapeau CLI (--model, --allowed-tools, --no-extension, etc.)
2. Variable d'environnement (OTTO_DISABLED_EXTENSIONS, etc.)
3. Fichier de projet (.astro/otto/permissions.json, .astro/otto/extensions.json, .astro/config.yaml)
4. Fichier utilisateur (~/.astro/otto/settings.json, ~/.astro/config.yaml)
5. Défaut intégré

Pour la référence complète voir Otto settings.

Vérifier qu'Otto est disponible

astro otto version    # version Otto installée + vérification de mise à jour
astro otto --help     # référence complète des drapeaux
astro otto update     # tirer la dernière version Otto

Otto auto-met à jour par défaut (vérification une fois par jour, appliquée au prochain lancement). Opt-out avec astro config set -g otto.auto_update false.

Si astro otto n'est pas reconnu, l'utilisateur a besoin d'Astro CLI v1.42+. Recommandez brew upgrade astro ou quel que soit l'installateur qu'ils ont utilisé.

Références autorisées

• astro otto --help — référence des drapeaux (source de vérité)
• Otto overview
• astro otto CLI reference
• Otto permissions
• Otto extensions
• Otto settings
• Otto memory