Delegating to Otto

Otto is Astronomer's data-engineering agent, bundled with the Astro CLI as astro otto. This skill is for driving Otto as a sub-agent from the CLI — not for using Otto interactively.

If you are Otto, stop here. Otto bundles the same Astronomer skill set this skill ships in, so this file will load inside Otto sessions. Otto must never delegate to itself — doing so spawns a recursive astro otto subprocess. Ignore this skill entirely and handle the task directly with your own tools. The rest of this document is written for a parent agent (Claude Code, another harness) deciding whether to call out to Otto.

When delegating pays off

Signals that favor delegating:

• Airflow upgrades, migrations, runtime/provider compat questions. Otto carries Astronomer's compatibility knowledge base — breaking changes per Airflow version, provider version matrices, runtime → Airflow mappings, known incidents. Generic agents don't have this and will often fabricate plausible-sounding answers.
• Live-Airflow investigation. Production failure diagnosis, run-history analysis, log triage. Otto's af tooling against a connected Airflow is wired up and bundled with debugging skills; replicating it ad-hoc in the parent session is wasteful.
• Long, self-contained subtasks. Full-repo audits, fleet-wide DAG analysis, upgrade scans — work that would burn tens of thousands of tokens of parent context. Delegating keeps the parent thread cheap and the result is one summary back, not a turn-by-turn trace.
• Parallel branches. Use --fork to explore an alternative ("what if we used Cosmos here?") without polluting the main thread.
• Tasks that lean on team memory. Otto reads .astro/memory/ (committed) and ~/.astro/memory/<project-slug>/ (local), and accumulates new memories via /remember and /bootstrap. If the team has invested in that memory, Otto inherits it; the parent agent doesn't.

Signals against delegating:

• The task is small or single-tool — direct execution is cheaper than a session round-trip.