Every wave of AI tooling arrives with the same obituary: ETL is dead, pipelines are legacy, just point a model at your raw data and ask. The obituary is wrong, and it is wrong in an interesting way. AI did not kill extract, transform, load. It added a new kind of transformation, inference over unstructured data, and it closed the pipeline into a loop. The stack did not die. It grew a metabolism.
This expands on a post I published on LinkedIn, which was itself a reaction to two pieces worth your time: Seth Rosen's "ETL: now with inference" and Ian Macomber's "The Shape and Feel of the Post-AI Data Stack," about what his team built at Ramp.
Key Takeaways
- ETL is not dead. AI added a new transformation primitive: inference, which turns calls, tickets, emails, and documents into structured, queryable data.
- The stack stopped being a one-way pipeline. What people ask decides what gets extracted next, so the data model evolves by observing its own usage. Rosen calls this "The Stack Becomes Circular."
- I call the circular version token metabolism: ingest, digest, remember. A pipeline moves data downstream and forgets. A metabolism digests continuously and keeps the extracted facts.
- The unglamorous disciplines got promoted, not retired. Definitions need versioning, probabilistic outputs need tests, and every extracted fact needs lineage back to its source.
- Skip the governance and the failure mode is specific: two agents hand your CEO three answers to one question. As Macomber puts it, AI made producing analysis cheap. It did not make agreeing on reality cheap.
- For marketing teams the stakes are concrete: campaign data was already structured, but the why behind performance lives in calls, briefs, and tickets, and that is exactly the data inference unlocks.
Where "ETL Is Dead" Comes From, and What Actually Changed
The argument for the obituary sounds reasonable. Models can read anything, so why maintain pipelines, schemas, and transformation jobs at all? Ask the model, get the answer, skip the plumbing.
What actually changed is narrower and more useful. In August, Seth Rosen, who cofounded the analytics platform TopCoat before Snyk acquired it, published a piece called "ETL: now with inference," building on Ian Macomber's account of the post-AI data stack at Ramp. The core observation: inference is now a transformation primitive. Run a model over a large collection of sales calls and write the loss reasons, objections, and competitor mentions back as structured data. Macomber's team at Ramp does literally this, tracking loss reason, objection type, and mentioned competitor as fields extracted from Gong calls. Meaning becomes a queryable table.
Notice what that is. It is extract, transform, load. The extraction source is a transcript instead of an API, and the transformation contains a model instead of a SQL join, but the shape of the work is the one data teams have run for a decade. Rosen says it plainly: if this sounds a lot like analytics engineering, it is because it is. The output still needs a schema, ownership, versioning, lineage, tests, and changing definitions.
So the "ETL is dead" crowd noticed a real event and misread it. The event was not the death of the pipeline. It was the arrival of a transformation type that works on the data that resisted modeling: conversations, documents, images, support threads. The disciplines around it did not become optional. They became load-bearing for a new class of data.
From Pipeline to Metabolism: What the Circle Is
The best section in Rosen's piece is called "The Stack Becomes Circular." Questions reveal missing concepts. Inference creates candidate structure. Usage shows which structure matters. Corrections improve the model, and the improved model makes the next round of inference cheaper. He is right, and I would give that circle a name, because naming it changes how you build for it.
A pipeline moves data downstream and forgets. Data flows in one direction, from source to warehouse to dashboard, and once a report ships, the pipeline has no memory of whether anyone used it, questioned it, or corrected it.
A metabolism digests continuously. Calls, tickets, SQL, docs go in. Atomic facts come out. The facts get wired into a knowledge graph, and what people ask decides what gets extracted next. That last part is the difference that matters: the system's own usage is an input. Rosen makes the same point from the engineering side, and Macomber from the organizational side. What they extract at Ramp is informed by the questions people actually ask, and recurring questions reveal which pieces of meaning deserve to become durable structure.
That is token metabolism. Not extract, transform, load, running on a schedule and forgetting. Ingest, digest, remember, running continuously and compounding. We run this loop on ourselves at Improvado every day: our own calls, tickets, queries, and documents get digested into one knowledge graph that our agents read, and the questions our team asks reshape what gets extracted next. It is not a metaphor we admired from a distance. It is how our internal system works, and running it is what taught us the second half of this article.
The name matters because the two architectures fail differently. A pipeline fails loudly: a job breaks, a dashboard goes stale, someone files a ticket. A metabolism fails quietly, by digesting the wrong things confidently. Which is why the next section is the important one.
The Unglamorous Parts Got Promoted, Not Retired
Here is the trap in the excitement about inference: probabilistic outputs feel like magic, so teams treat them as exempt from the boring disciplines. The opposite is true. Every discipline that made deterministic pipelines trustworthy got promoted when the transformations became probabilistic.
Definitions get versioned like code. When someone changes what counts as a lost deal, you need to see who changed it, when, and be able to roll it back. Macomber describes sales-call parsing at Ramp running as a versioned prompt on their infrastructure, with a practitioner-defined taxonomy that improves with every correction. The alternative is a definition that drifts silently, and every historical comparison built on it quietly stops meaning anything.
Probabilistic outputs get tested. The model's extractions get checked against human-reviewed examples on a schedule, so drift gets caught before it reaches a dashboard. Rosen frames the expansion precisely: data testing grows from validating values to validating inference. You can test the output, and you can also test its derivation, whether the agent consulted the right definitions and inspected the right evidence.
Lineage runs back to the raw source. Every extracted fact links to the transcript it came from, so anyone can check it. Rosen pushes this further than most teams do today: provenance for an inferred fact includes the prompt, the model, the taxonomy, and the evidence supporting the conclusion, not just the source document.
Skip all that and the failure mode is not an error message. It is two agents handing your CEO three answers to one question, each answer fluent, sourced-sounding, and produced in seconds. The semantic layer used to keep two dashboards from disagreeing about revenue. Now, as Rosen puts it, it has to keep different models, agents, and interfaces from inventing different versions of reality.
Talk to an Improvado expert about giving your agents one governed version of the truth.
What This Means for Marketing Data Teams
Marketing is an instructive place to watch this play out, because marketing teams have lived on both sides of the line for years. Campaign data was always structured: impressions, clicks, spend, conversions, flowing through ETL or ELT into a warehouse. But the why behind the numbers never was. Why deals stall lives in sales calls. Why a campaign brief changed lives in a thread. Why churn spiked lives in support tickets. The structured half told you what happened. The unstructured half, the half you could not query, held the explanation.
Inference as a transformation primitive closes that gap. The same discipline that unified your ad platforms into one schema can now turn calls into loss reasons, briefs into decisions, and tickets into named product objections, sitting in the same warehouse next to spend and revenue. The interesting analytical questions stop being blocked on data entry that never happens.
Two practical warnings from running this loop ourselves.
Budget for the digestion, not just the model. Continuous extraction over every call and ticket is real compute, and it is not free. Macomber is direct about this at Ramp's scale: parsing a hundred thousand raw call transcripts through a model is expensive and slow. The metabolism metaphor cuts both ways, because metabolisms consume energy constantly. Decide what deserves continuous digestion and what can be interpreted on demand.
The single version of truth is the product, not a byproduct. If you wire inference into your stack without the versioned definitions, the tests, and the lineage, you have not built a metabolism. You have built a fluent-answer generator with no way to settle disagreements. The scarce resource in an organization full of agents is not analysis anymore. Analysis got cheap. Agreement on what is true did not, and the whole governance layer exists to manufacture that agreement. This is the same conclusion we reached from the context engineering side: what an agent knows about your business decides its output, and that knowledge has to be governed somewhere.
That is what we build at Improvado: the structured half, with every marketing platform unified into one governed schema, and the agentic layer that reads it, with your definitions applied consistently so every agent answers from the same reality. The metabolism only compounds if what it remembers is true.
Talk to an Improvado expert about wiring your marketing data into one queryable, governed layer.
Frequently Asked Questions
Is ETL dead?
No. AI changed what ETL can extract from, not whether extraction, transformation, and loading are needed. Inference over unstructured data is a new transformation type: a model reads calls, documents, or tickets and writes structured fields back to the warehouse. The output of that transformation still needs a schema, ownership, versioning, lineage, and tests, which is exactly the ETL discipline applied to a new class of source data. What did die is the assumption that the pipeline only runs one way, because usage now feeds back into what gets extracted next.
What is token metabolism?
Token metabolism is my name for what the data stack turns into once inference becomes a routine transformation and usage feeds back into the data model. Instead of a linear pipeline that moves data downstream and forgets, the system digests continuously: calls, tickets, SQL, and documents go in, atomic facts come out, the facts are wired into a knowledge graph, and the questions people ask decide what gets extracted next. The short version is ingest, digest, remember. It describes the same architecture Seth Rosen calls the circular stack and Ian Macomber calls the post-AI data stack, seen from the operating side.
What did AI actually change about the data stack?
One primitive and one direction. The primitive: inference now works as a transformation, so data that resisted modeling, like conversations, briefs, and support threads, can become structured tables. The direction: the stack stopped being one-way. Questions reveal missing concepts, corrections improve the taxonomy, and recurring questions show which extractions deserve to become durable structure, so the data model evolves by observing its own usage. Everything else, warehouses, semantic layers, testing, lineage, remains recognizably the same work.
Do data quality practices still matter when a model does the transformation?
They matter more, because probabilistic transformations fail silently. A broken SQL job throws an error. A drifting extraction prompt just starts classifying loss reasons slightly differently, and every report built on the field degrades without a single alert. That is why the practices got promoted: definitions versioned like code so changes are visible and reversible, extractions tested against human-reviewed examples on a schedule so drift is caught early, and lineage from every extracted fact back to its source so any number can be checked. Without them, adding more agents just produces more confident, incompatible answers.
What is the post-AI data stack?
It is Ian Macomber's term for the architecture his team runs at Ramp: AI runs over large collections of unstructured data, extracts meaning as structured fields, writes the results back to the shared data model, and observes the questions people ask to decide what to promote into that model next. Seth Rosen's "ETL: now with inference" generalizes the engineering pattern behind it. The defining property in both accounts is that the stack is familiar, the same modeling, testing, and semantic-layer work, extended to sources and transformations that did not fit before.
What does this look like in a marketing organization?
Your structured data, spend, impressions, conversions, pipeline, already flows into a warehouse. The metabolism adds the unstructured half: sales calls become loss reasons and competitor mentions, campaign briefs become recorded decisions, support tickets become named objections, all as queryable fields next to your performance data. The result is that questions like which objection costs us the most revenue stop requiring a quarter of manual tagging. The prerequisite is the same governance your structured data needed: one set of definitions, tested extractions, and lineage, so every agent reading the data gives your leadership the same answer.
