Bronze Is All You Need
The medallion architecture has become orthodoxy in data engineering. Bronze for raw ingestion, Silver for cleaned and conformed, Gold for business-ready. Three layers, clean separation, everyone gets a diagram on their architecture slide.
Here is the problem: two of those layers exist because humans cannot eat raw data.
The digestive system argument
Silver and Gold are pre-chewed data. They exist because a human analyst cannot look at a Bronze table with 400 columns of raw API output and answer a revenue question. So we denormalize, aggregate, rename, and reshape until the data fits inside a human head. Then we call that layer Gold and act like it was an architectural decision rather than a cognitive accommodation.
An agent does not have this limitation. Give it the Bronze schema, the source metadata, and the lineage graph, and it derives whatever view it needs on demand. Silver and Gold do not disappear. They become cached materializations: performance optimizations, not architectural commitments. The distinction matters. An architectural commitment is a decision you defend in design reviews. A cache is something you invalidate when the cost calculus changes.
Silver is sifted flour
The immediate objection I recently got while floating this idea in a thread: what about PII masking, deduplication, data quality? You cannot skip those. Correct. But those are operations, not layers.
PII masking can and arguably should happen at ingestion. Dedup across sources is cheapest once all the data is in one place, which means it runs on Bronze after landing. Data curation is a policy you enforce wherever you need it. None of these require a separate persistent copy of the data with a different metal name.
Silver is processed Bronze. That is the entire argument. The medallion architecture took a processing stage and promoted it to an architectural layer, which is how we ended up with teams maintaining two copies of the same data and calling it good design. You do not call flour a different ingredient after you sift it. You call it sifted flour. Giving processed Bronze a different name made people think it was a different thing rather than the same thing with operations applied.
For humans, this naming created useful organizational clarity. It gave teams handoff points and made lineage legible at a glance. For agents, it is pure overhead. The agent does not need a named waypoint to know what operations have been applied. It has the processing log.
Static ETL is the ICE fleet
In Norway, internal combustion cars are not banned. They are just the legacy fleet with a known depreciation curve. No one is designing new fueling infrastructure around them. The transition was not a single policy event. It was a compounding stack of incentives, infrastructure investment, and shifting defaults until the old technology became the thing you explain rather than the thing you assume.
Static ETL is in the same position. Nobody is going to rip out the SSIS packages from 2014. They will run for years. But no one should be making new architectural bets on hardcoded transforms that break when a source system adds a column.
Metadata-driven ETL is the equivalent of Norway's EV mandate moment. You describe sources and schemas declaratively. Transforms are generated, not written. This is table stakes for any new build. If you are still handwriting transformation logic for known patterns, you are designing a gas station in Oslo.
Token economics as the new cost function
The old design question for Silver and Gold layers was: "What can a human understand?" The new design question is: "What is cheaper to store than to recompute in tokens?"
An agent re-deriving a complex join from Bronze on every query might burn 50,000 tokens each time. If the underlying data only changes daily, materializing that view and reading it for 500 tokens is obviously better. Same logic as caching, different cost function. The optimization pressure shifts from human comprehension to token economics.
This means the medallion architecture becomes dynamic. Layers materialize when the token cost of repeated derivation exceeds the storage cost. They dematerialize when query patterns shift or the underlying Bronze schema changes enough that the cached view is stale more often than it is useful. No human has to decide when to build or tear down a Silver table. The economics decide.
The feedback loop
Here is the interesting part. An agent that observes repeated expensive derivations from Bronze can do something a traditional ETL pipeline cannot: propose schema changes upstream.
If every consumer query requires inferring a customer segment from five different fields, the agent can surface a recommendation: capture that segment at ingestion. Add it to Bronze. This is not a new idea. SQL Server has recommended missing indexes for twenty years. But extending that pattern from query optimization to schema-level suggestions on the raw layer is a qualitative shift.
Think of it as a database query optimizer that does not just pick better execution plans but proposes DDL changes. The agent sees the gap between what Bronze contains and what consumers repeatedly need, and closes it.
The obvious objection: changing Bronze means changing source contracts. An agent can recommend "capture this field at ingestion," but someone still has to negotiate that with the source system owner.
This objection holds only if the agent's knowledge stops at the Bronze boundary. It does not have to.
The source metadata layer
Imagine the agent has access not just to what Bronze contains, but to what Bronze could contain. A catalog of every source system's full schema, update frequency, access pattern, and API surface. The source metadata is the menu. Bronze is what you ordered.
Now the feedback loop changes fundamentally. The agent sees a repeated expensive derivation. It checks the source catalog: does the upstream system already have this field? If yes, the agent proposes a Bronze schema extension. Not a negotiation with a human. A pull request against your ingestion layer, complete with the cost-benefit case: how often the field is needed, what the incremental API load looks like, what token cost it eliminates downstream. If the field does not exist in the current source but exists in a different source in the catalog, the agent proposes a new ingestion pipeline with the same justification attached.
The human-in-the-loop bottleneck collapses from "negotiate with the source system owner about adding a column" to "approve the agent's pull request against Bronze." That is a fundamentally different organizational cost.
This means the Bronze layer itself becomes adaptive. It is no longer a snapshot of what a data engineer decided to capture during the initial onboarding of a source. It evolves based on what consumers actually need, informed by what sources actually offer. The agent is not just optimizing queries downstream. It is reshaping the raw material upstream.
What this means for the medallion
The medallion architecture does not die. It stops being static. Instead of three fixed layers designed at whiteboard time and defended in architecture reviews, you get:
A durable Bronze layer. This is the only real architectural decision: what do you preserve at ingestion. Get this wrong and nothing downstream can fix it. But "wrong" is no longer permanent, because the agent can extend Bronze when it discovers gaps. Put differently: Bronze is an evolving subset of the source metadata catalog, not a fixed schema.
A source metadata catalog that tells the agent what is available beyond what Bronze currently captures. Bronze without this catalog is a fixed menu. Bronze with it is a kitchen that can cook anything the suppliers stock.
A dynamic set of derived views that materialize and dematerialize based on token economics and query patterns. Call them Silver, call them Gold, call them caches. The label does not matter. The point is that no human is manually deciding which aggregations to maintain.
A feedback mechanism where consumption patterns reshape not just the derived layers but Bronze itself, informed by what sources actually offer.
The medallion was always a human-legibility hack wearing an architecture hat. Agents do not need the hack. They need the metadata. And with the right metadata, they do not even need the Bronze you designed. They build the Bronze they need.
This post started as a reaction to Mimoune Djouallah's comment on the Guy in a Cube Silver vs. Gold debate. His claim that Bronze is the only layer that truly matters is correct, and the reason it is correct tells you something about where data platforms are heading.