Your Multi-Agent Pipeline Is Already ELT — And Nobody Reviewed the Transform

You're already running ELT — you just didn't name it

Here's the part nobody tells you when you wire an agent up to raw context: the moment it reads a document, an API response, a DB row, and decides on the spot what that data means, you're running ELT. Load first, transform on read. Same pattern as the warehouse. The only thing that changed is the transform used to be a SQL model you could open and read — now it's an LLM call you can't.

Day 2: same split, new address

Day 1 was ETL vs ELT as a data-platform decision — transform before you load, or load raw and figure out the transform later, on read. Today: that exact split is already living inside your agent pipeline. You didn't have to choose it. It showed up anyway.

The structural mapping

Line the two worlds up and they match almost exactly. Raw docs, API responses, tool outputs, DB rows dumped straight into a context window — that's Load. The LLM chewing on that raw blob at query time, deciding what it adds up to — that's transform-on-read. No warehouse needed. The context window is the staging table.

Take a concrete case. An agent gets a raw customer record — last_login, subscription_status, support_tickets, payment_history — and you ask: is this customer churning? The agent invents an answer to a question nobody wrote down. Maybe it weights last_login heavily. Maybe one failed payment reads as a red flag. Maybe support_tickets gets ignored entirely. That guess is the transform. It happened inside the inference call, not in a model file you can open later.

• ▹Load = the raw record, handed to the agent untouched
• ▹Transform-on-read = the agent's in-context reasoning about what "churn" means for this one record
• ▹That reasoning is written down nowhere except the output it produced

Same governance problem, just relocated

This is the exact failure ELT was already infamous for, well before agents existed. Ten analysts, ten dbt models, ten different definitions of "revenue" — gross vs net, before vs after refunds, calendar month vs billing cycle. Multi-agent pipelines reproduce this with less light on it. N agent calls read the same raw customer blob, and N agents silently invent their own definition of churn, revenue, priority — whatever the question asks for. None of those definitions get pinned down, named, or put in front of a reviewer. Each one exists only as a pattern in that single call's output, gone the moment the next call starts fresh.

What makes this worse than old-school ELT

In a dbt stack, the transform is a file. It's checked into git. It shows up in a PR diff. It has a lineage graph. When someone changes what "revenue" means, you can see exactly what changed and who signed off. An agent's transform is a prompt plus a context window plus a temperature setting — none of that is a versioned artifact by default, none of it shows up in a lineage tool. You lose the one mechanism ELT teams built specifically to catch definitions drifting out from under them.

The tell: run it back

Here's the test. Take any agent step that reads raw context and hands back a judgment, and ask: if I ran this again tomorrow on the same input, would I get the same interpretation? If you can't answer that with a straight face — because it hinges on model version, on prompt wording that's since been tweaked, on plain sampling noise — you're looking at ungoverned ELT. You don't need a rewrite. You need a contract.

The fix: pin the transform once, upstream

You don't have to redesign your architecture to escape ELT — classic ELT is fine, as long as it's governed. Treat agent-facing context exactly like a warehouse table your analysts query: define the transform once, upstream, as a contract every agent reads from. Stop letting each agent re-derive meaning on its own.

• ▹A schema for the derived fields — e.g. churn_risk: enum[low, medium, high], computed_at, definition_version
• ▹One extraction/classification prompt, versioned in git, that produces that schema — not N ad hoc prompts scattered across N agents
• ▹A validation step, even a cheap one — a Pydantic model, a JSON schema check — that rejects anything that doesn't match the contract
• ▹Downstream agents consume the derived field, not the raw blob. They don't get a vote on what churn means

# contract.yaml — the one place 'churn' gets defined
field: churn_risk
version: 3
source_fields: [last_login, subscription_status, support_tickets, payment_history]
extraction_prompt_ref: prompts/churn_v3.md   # checked into git, diffable
output_schema:
  churn_risk: enum[low, medium, high]
  confidence: float
  definition_version: 3
validation: pydantic_model.ChurnRisk
# every downstream agent reads churn_risk, never the raw record directly

Where this leaves you

So the transform can happen inside an agent call, invisibly, unless you deliberately pin it down. Next question: given that a transform can live in a prompt, a dbt model, or somewhere in the murky space between — where should it actually sit so it stays observable? That's Day 3.

Extend your knowledge

• ▹Look at how dbt's model-versioning and exposures work — it's the closest existing pattern for what an "agent contract" version history should look like
• ▹Read Pydantic's or Instructor's docs on structured output validation — that's the practical tool for enforcing the output_schema half of the contract above
• ▹Audit one of your own agent pipelines: pick a single derived judgment (priority, sentiment, risk tier) and check whether it comes from one shared prompt or from several agents independently guessing at it
• ▹Revisit Day 1's ETL vs ELT notes with this lesson in mind — the same "where does the transform live" question now applies one layer up, inside the agent call itself