Read-only unless you said otherwise
A datasource flagged read-only refuses write-shaped nodes at save time and again at execution, against the live row. The documented pattern pairs it with a SELECT-only database user.
Agent-authored · person-released · every call audited
Agentic data engineering
An AI data pipeline you would let someone else run
An agent writing SQL in a chat window produces an answer. An AI data pipeline has to produce something else: an artefact your team can read, review, version, rerun next month, and explain to whoever asks. Four things make the difference, and none of them is the model.
One
The agent reads your real schema before it writes SQL
Of the 41 tools, the introspection reads exist for exactly this:
datasources_get_schemas, datasources_get_tables,
datasources_get_columns and datasources_preview_rows. The agent grounds its query
in the columns that exist and the values they actually hold, instead of inferring a schema from table names.
Introspection is a read, and it is scoped like everything else — the server builds the statement and quotes every identifier itself; the agent supplies names, never SQL fragments.
Two
What it produces is a JSON contract, not a transcript
A pipeline is declarative JSON: nodes, their dependencies, their parameters, where each one reads and where its output goes. The SQL lives in named templates the pipeline references. Both diff like code in review, because they are code.
Values reach the SQL as bound parameters, never as interpolated strings — the template engine refuses the interpolated form outright. That rule is not there for tidiness; it is what keeps an agent-authored query from becoming an injection surface.
Three
Every change is a version, and a release is immutable
Editing a released pipeline never edits it: the first write copies it into a draft, and the release you were running keeps running. There is one draft per entity at a time, and releasing locks it. What ran last quarter is still exactly what ran last quarter.
Moving a release into a higher environment is a human, UI-triggered action — there is no MCP tool for promotion and no schedule. An agent can author and run; a person promotes.
Four
It runs governed, and the failure is readable
Every call is in the audit log
mcp.tool.called for each call, mcp.tool.write for each mutating one — beside the login, key-issuance and decryption events.
Execution is observable while it runs
Per-milestone events stream over SSE with heartbeats, so the agent — and the human watching — know which node is running rather than waiting on a spinner.
Failures carry stable codes
Every refusal is a catalogued {domain}.{entity}.{failure} code with details, not a stack trace. An agent can branch on the code; a person can search for it.
Results come back as rows
executions_get_result returns the actual data through a paged cursor, so the agent verifies its own work instead of reporting success.
Multi-source joins land nothing
Each source is read in place and staged into an in-memory database created for that one execution, then destroyed. The federated-query story.
What this is not
- Not an ETL tool. Nothing is moved on a schedule into a warehouse you then have to keep in sync. Sources are read where they live.
- Not a no-code builder. The artefact is SQL and JSON, on purpose, because that is what survives review.
- Not a model. Bring your own agent. This is the surface it works against and the governance it works under.
How this compares with a text-to-SQL tool → · vs Airflow → · vs dbt →
Asked before
AI data pipeline questions, answered plainly
What does the agent read before it writes SQL?
Your real schema: datasources_get_schemas, datasources_get_tables, datasources_get_columns and datasources_preview_rows return the columns that exist and the values they actually hold, so the query is grounded rather than inferred from table names. The tool list is docs/mcp-server.md §6.1.
How do parameter values reach the SQL?
As bound parameters: a declared name is translated to a positional parameter on a prepared statement before the driver sees it, so a STRING value is never parsed as SQL — an injected payload matches no row. The binding contract is docs/templates.md §8.4.
Can an agent change a released pipeline?
No. The first write to a released pipeline copies it into a draft, and the released version keeps running until a person releases the new one — one draft at a time, releases immutable. The lifecycle is docs/versioning.md §3.1.
What does the audit log record for agent runs?
Every MCP call is written with the key and the tool — mcp.tool.called, and mcp.tool.write for the mutating ones — beside the login and key-issuance events, and never the SQL text, the rows or the parameter values. The audit log is docs/auth.md §10.1.
Watch an agent build one on the demo
Bring up the demo sources, describe a question in your own words, and read what the agent drafts — then release it, or don't. The artefact either way is a pipeline you can read.