An agent is not a DAG with vibes

I have been asked to "just put an agent on the warehouse." That sentence usually means: a loop, a prompt, and hope.

An agent that can call run_sql, retry_dag, and page_oncall is a junior operator with no sleep and a credit card. Treat it like that.

What we actually ship

When Atalaya builds an agentic slice, it is a worker with a closed tool list:

• read a watermark or a failed partition
• propose a remapping or a backfill window
• open a ticket or a pull request
• never write to a mart unless a human or a policy says yes

The model is not the orchestrator. Airflow, Cloud Composer, or a queue still owns the schedule. The agent sits next to a failed task, not instead of it.

Tools are the API

If the model can invent a table name, you will get a table name. Bind tools to the models you already trust: fct_orders, dim_consent, the freshness view. Same grain, same names, same GDPR joins.

An agent that talks to raw JSON in the lake is a prompt injection with extra steps.

Stop conditions

A useful agent has a budget: tokens, tool calls, wall clock. When it hits the budget it stops and leaves a trace a person can read at 2am. Infinite "think harder" is how you burn money and still miss the SLA.

We log every tool call next to the DAG run. If you cannot replay what it did, you do not have an agent. You have a ghost.

Where it pays

Late files with a known schema. Mapping a new dealer extract onto stg_. Drafting a dbt test from a grain sentence. Not "ask the data anything" on a Tuesday close.

If the task already has a boring DAG, keep the DAG. Give the agent the exception path. That is the only agentic work I will put in front of a plant or a hospital.