Your AI Agent Shouldn't Have to Read Python to Understand Your Pipelines

Watch what a coding agent does when you ask it why a table is stale. It opens the DAG repository, reads some Python, greps for table names, follows a few imports, and produces a fluent explanation of what it thinks the pipelines do. The prose is confident. The structure underneath it is guessed — and orchestration is one of the worst places in your stack to guess.

Here is why. The facts an agent needs about pipelines are, by their nature, not in the files it can read. Cross-DAG dependencies do not live in any single DAG file; they chain through the datasets pipelines exchange, so no amount of reading one file reveals them. Ownership frequently lives in a default value — the literal string airflow — that tells the agent nothing. And whether a DAG is paused is not in the code at all; it is runtime state. An agent reasoning from source alone will miss the one fact that explains the stale table: every producer of that file is paused while its consumers keep running. Language models fill such gaps with plausibility, and plausible-but-wrong is the most expensive kind of answer an agent can give.

Grounding beats guessing

The alternative is to give agents the same thing you give people: governed facts, queryable on demand. When an Airflow estate is imported into CoreModels, every DAG and every data-aware scheduling asset becomes a governed type; tasks become elements with their operator classes recorded; owners, schedules, and paused state ride along as queryable metadata; and the producing and consuming relationships form an explicit dependency graph — asset to producing DAG, consuming DAG to asset, chained across the whole deployment.

CoreModels serves that model to agents over MCP — the open protocol AI assistants already speak — from a standard endpoint at /mcp, secured with OAuth. An agent connects, lists the projects it can see, pulls a project summary, and searches the graph with the same read-only tools a human's tooling would use. The stale-table investigation stops being an inference exercise: find the asset, walk the lineage to its producers, read the paused state. The answer is a traversal over facts a human governed, not a guess over code — and the agent can cite exactly which governed facts it used.

Agents can run the audit, not just read the graph

Consultation goes further than lookup. The same audit that gates your pull requests is exposed as an MCP tool, audit_vendor_project: an agent hands it fresh Airflow artifacts — inline, or by URL when payloads are large — and gets back the full report. Because findings come back as stable machine-readable codes with severities and named subjects, not paragraphs, the agent can reason over them structurally: notice that dag-no-owner findings cluster in one team's DAGs, or that a paused-producer warning names the exact producers and active consumers involved, and propose the fix with the evidence attached.

There is also get_vendor_integration_status, which tells an agent which vendor estates a project governs and the last-import state — so an agent can orient itself before it starts answering, instead of assuming.

Two properties make this safe to hand to an autonomous system. The audit is strictly read-only, which is why it is available on the public MCP endpoint at viewer level — an agent running it can learn things but cannot break things. And every tool declares what it is: read-only tools are marked as such in their MCP annotations, so even the agent's harness knows the difference between looking and touching.

The write path stays earned

Looking is open; touching is not. Importing an estate into the governed model is an admin-level operation that lives only on the admin MCP endpoint, behind project membership. The default posture for agents is therefore exactly the one you would want for a new human teammate: read everything you need, run any analysis you like, and bring changes to someone with the authority to make them. Where a team does grant an agent write access, that grant is explicit, role-checked per project, and scoped — never a side effect of being able to connect.

Why this beats stuffing the context window

You could paste your DAG repository into an agent's context instead. Three reasons that loses. Freshness: a context dump describes the estate at paste time, while the governed model has a maintained drift loop — audits on every pull request, re-audits when the model changes, a recorded history — so an agent consulting it inherits a maintained picture, not a snapshot of unknown age. Semantics: the graph gives the agent meaning — governed types, ownership, explicit lineage — where raw code gives it text to interpret. And authority: the governed model is the version of reality your organization actually signed off on, which means an agent grounded in it gives answers consistent with what your stewards decided, not with whatever the code happens to imply this week.

One honest limit: the governed graph reflects the estate as of the last import, and CoreModels never holds live Airflow credentials by design. For the current-second operational picture, the agent audits fresh artifacts; for meaning, ownership, and structure, it consults the graph. That division — live state from your systems, governed truth from the model — is the right one for agents and humans alike.

Agents are exactly as good as what they can consult. Give them prose and they will give you plausible fiction; give them a governed, queryable model of your orchestration estate and they give you answers you can act on at 3 a.m.

The Apache Airflow quickstart in the CoreModels docs includes the MCP tool calls agents use alongside the human-facing API.