Tool Use Is the New ETL

ETL has been the same conceptual thing for fifty years. Get data out of system A, transform it, load it into system B. The tools change – Informatica, then Talend, then dbt – but the shape is constant. A pipeline runs on a schedule, processes some data, produces some output. Static. Predictable. Auditable.

The shape that’s emerging now is different enough that calling it ETL is misleading. An LLM with tool access reads a question, decides which tools to call, calls them, reads the results, decides what to do next, calls more tools, eventually returns an answer. The path through the data is constructed at run time, not designed at compile time. The pipeline is a trace, not a graph.

What “tool use” means here

A tool, in the LLM sense, is a function the model can call with structured inputs and get structured outputs back. Read a table. Run a query. Look up a record. Fetch a document. Send an email. Each tool is a small, well-defined operation with a schema. The model is the orchestrator, picking which tools to call in what order based on the current situation.

The tools are not new. The orchestration is. For most of the history of software, orchestrating tools was a developer’s job: write the code that decides what to call when. Now the LLM is doing the orchestration, and the developer is defining the tools.

Why this is more like ETL than people realise

The work an LLM-with-tools does is recognisably the same work an ETL pipeline does: extract data, transform it, route it somewhere. What changes is who decides the path.

An ETL job extracts customer records from Postgres, joins them to orders from MongoDB, enriches with currency rates from an API, lands them in Snowflake. The path is fixed in code. Every run takes the same path.

An LLM with tool access reads a question (“summarise this customer’s spending pattern”), calls the customer-lookup tool, reads what it returns, decides it needs order data, calls the order-lookup tool, possibly notices an outlier and calls the currency-rate tool to verify, then summarises. The path is decided at run time. Different questions produce different paths. The same question can produce different paths on different runs.

Same operations. Different governor.

What this changes

The implications take a while to land.

Pipelines stop being scheduled jobs and start being request handlers. The unit of work isn’t “the 2am batch.” It’s “this question, asked just now.” The infrastructure has to be sized for request volume, not for batch throughput.

The tools become the API surface of your data estate. What an LLM can do with your data is exactly the set of tools you’ve exposed. Tools you haven’t exposed don’t exist for the agent. The data engineering work shifts from writing pipelines to designing tools: what should the catalog tool look like, what should the metric query tool return, what arguments does the lineage tool take.

Observability changes shape. You don’t observe a static DAG; you observe a series of run-time traces, each different. Tooling for tracing tool calls (LangSmith, LangFuse, Helicone, native vendor tracing) becomes as important as the workflow orchestrator was to ETL.

Determinism becomes a design choice rather than a default. Most ETL jobs were deterministic by construction. Tool-using LLMs are probabilistic. The same question might call different tools or produce slightly different outputs. For some applications that’s fine; for others, you need to constrain the run-time path with explicit policy.

MCP and the protocol layer

The Model Context Protocol (MCP), which Anthropic introduced and most others have adopted, is to tool use what HTTP was to web pages. A standard for exposing tools to LLMs over a wire protocol, with schemas, authentication, capability discovery. By 2026 the major LLM vendors all speak MCP and so do most of the data platforms (Snowflake, Databricks, dbt Labs).

The practical effect is that “tools” become reusable infrastructure. A well-built MCP server for your catalog can be consumed by any LLM. The tool isn’t tied to a specific model. The investment in tools compounds across whatever LLMs you use, the way HTTP services compound across whatever browsers your users have.

What survives from ETL

Not everything is new. The things ETL teams learned the hard way over fifty years still apply:

• Idempotence. Tools should be safe to call repeatedly with the same arguments.
• Auditability. Every tool call should be logged with its arguments and outputs.
• Schema discipline. Tool inputs and outputs need types and contracts.
• Error handling. Tools fail. The orchestrator needs to know how to recover.
• Cost awareness. Every tool call has a cost. Loose orchestration can blow budgets fast.
• Quality testing. The tool itself needs tests; the orchestration needs evaluation.

The mistake is to think tool use is fundamentally new engineering. The patterns are old. The orchestrator is new. The discipline carries over.

The shape of the work

If you’re building this in 2026, the work isn’t “build an AI agent.” The work is:

1. Identify the operations the agent will need. Catalog lookup, semantic query, lineage trace, etc.
2. Design tools with clean schemas. Inputs, outputs, errors, contracts.
3. Implement the tools as MCP servers or equivalent.
4. Wire the LLM up with access to the tools.
5. Trace what the LLM does. Iterate on the tool design.
6. Constrain where determinism matters. Allow run-time choice where it doesn’t.
7. Evaluate end-to-end on a real question set. Iterate.

None of this requires a new degree. Most of it is recognisably data engineering work, applied to a slightly different abstraction. The teams that get this right will look like data platform teams, not AI teams.

That’s April done. May moves to the cost layer – evaluating agents, hallucinations on structured data, what a petabyte actually costs, and the FinOps maturity curve nobody’s talking about.