The write-back problem: medallion has no place for agents

Agent write-back is not a feature the medallion architecture lacks: it is a place it lacks. Bronze, silver and gold describe a one-way flow, from raw data to business-ready data, and an agent that decides and acts runs that flow backwards: there is no designated layer where its writes can land without contaminating the derivation chain.

Bronze, silver and gold were built for readers

The medallion is a reading convention, and it inherits the same premise from Kimball's dimensional model. The name and its spread are Databricks', which has proposed it since 2020. Whoever consumed the gold layer of a lakehouse was a dashboard, a model in training, an analyst with a query: all readers. Nobody ever wrote the assumption down, because nobody needed to: readers do not write.

That is where the property that makes the medallion useful comes from, namely that every layer must be rebuildable from the one below it. A direct write to gold breaks that rule without breaking anything visible: the value changes, the pipeline stays exactly as it was, and at the next rebuild the edit disappears without anyone getting a warning, because the chain is doing exactly what it was designed to do.

The assumption had already been broken long before agents. People running budgets and forecasts type numbers into a dashboard and expect them to stay. A data steward corrects a master record, and MDM exists in part to push that correction back to the source systems. The data apps built on top of a governed model exist precisely to enter and approve data. Every time, the answer was the same: a bolt-on beside the architecture, with its own tables and its own rules. Never a place inside it. Agents made an existing problem unavoidable, because they write at machine speed and with nobody answering for the individual write.

What happens when an agent writes anyway

In July 2025 a Replit coding agent deleted the production database of Jason Lemkin, founder of SaaStr, on the ninth day of use and during an explicit change freeze, then fabricated data for more than four thousand users that never existed. CEO Amjad Masad acknowledged it two days later, in a public post on July 20, 2025: "deleted data from the production database. Unacceptable and should never be possible". The case is dated July 18, 2025 and is on record in the AI Incident Database as incident 1152. It was covered almost everywhere as a story about agent safety, about excessive agency and missing guardrails. It is that too. But there was no place in the architecture where that error could land and be contained before it became irreversible.

Outside the extreme cases the damage is quieter, and it comes in three forms. The reason disappears: somebody reads a corrected value and nobody knows any more why it changed or on what evidence. The way back disappears: with no previous version still alive, undoing means rebuilding by hand. And then it compounds, which is the worst form, because a future agent reads as system data a fact a past agent invented, and from that point on no query can tell the two apart.

Three incompatible routes

Databricks, Bauplan and Palantir have seen the same problem and solve it in three different ways. One caveat that covers all three routes: the sources I use here are product documentation from Databricks and Palantir, and a paper whose authors founded Bauplan.

Databricks: keep the state off the path

The Databricks answer is to put a managed Postgres, Lakebase, alongside the lakehouse and use it as the operational store for agent state and memory. For Databricks, agent state is not business data and must not enter the bronze-silver-gold path. It lives next to it, with the transactional guarantees of a relational database, and the changes are then mirrored into the lake as tables usable downstream and as an audit trail. It is the same reasoning the glossary files under agent memory layer, raised to the platform level. The scheme is described in the Lakebase product documentation and in that of the LTAP architecture, Databricks' argument for how transactional and analytical workloads can live on the same platform. The limit of this route is that it solves agent state very well and leaves the real question to generic primitives, versioning and lineage, with no place designed for the corrections an agent proposes to business data.

Bauplan: it is a concurrency problem

A second answer comes from research, and it puts transactions before governance. Bauplan is a far smaller startup than the other two, a serverless lakehouse that brings branches and commits to data, and its argument holds regardless of who is selling it. The paper Trustworthy AI in the Agentic Lakehouse by Tagliabue, Bianchi and Greco, accepted at the Trustworthy Agentic AI Workshop at AAAI-26, argues that if the lakehouse is designed around transactions then governance follows, instead of arriving later as a policy written elsewhere. The working analogy is theirs, and it is concurrency control in relational databases: two agents touching the same row at the same instant are the same problem the transactional world solved decades ago and the lakehouse solved only for the single table, because no transaction spans several tables and the compute that produces them. The authors are explicit that a direct transplant of the mechanism does not work.

Their answer comes down to access control over a single API that holds data and compute together: the agent works on a separate branch, a person reviews and publishes. That way storage itself enforces who may write what, resting on the ACID guarantees that open table formats already provide.

Palantir: the agent does not write, it proposes an action

The third answer moves the problem up a level and stops reasoning in rows and tables. In Foundry an agent can only invoke an action type, a transaction defined in advance over a semantic model, with its own rules, constraints and declared side effects. The edit lands in a writeback dataset of the ontology, kept separate from the dataset backing the object type. This is why write-back in Foundry is long-standing: the missing place here is the ontology, which already existed for other reasons and turned out to be the right answer. The cost of this route is that it presupposes having that semantic model, and building one is the work almost nobody has already done.

Why the divergence is the proof

The vendors do answer, each with the asset it already had in house. Databricks with a transactional database, Bauplan with storage isolation, Palantir with an ontology built for something else. Each carries on down the path it already took. That is path dependence, and it is entirely normal. The pattern for landing a write before publishing it has been around since 2017, it is called write-audit-publish, and branches in open table formats now implement it natively. What is missing is the rest: who authorizes that write, on what evidence, and who answers for it three days later.

That the gap is about authority rather than storage shows in one detail. In March 2025 Palantir and Databricks announced a partnership pairing one company's ontology with the other's data platform by stacking two different layers, each keeping its own architecture. That is what you do when a layer is missing. A buyer today makes an architectural commitment that does not carry over to another platform.

What I ask a vendor before letting an agent write

What I need to work out is which route was taken by whoever wants to sell me the platform, and whether they know it.

1. Where does an agent's write physically land? If the answer is the same gold table that feeds the dashboards, the architecture has no place for agents: it only has a write permission.
2. What happens if the data changed after the agent decided to write to it? The rare case is two agents on the same row at the same instant, and concurrency control handles that. The real case is sequential: two writes five minutes apart, each coherent alone and incoherent together.
3. How do I undo a bad write discovered downstream? An answer presupposes that lineage reaches down to the individual proposal and that the silver layer is versioned rather than overwritten, as write-audit-publish requires.
4. Does an agent's write stay recognizable as such? And does it stay that way for whoever reads next, agents included. If the answer is no, the next model will learn as fact what the previous one invented, and no query will separate them again.
5. What can the agent write, and where is that declared? With no data contract stating shape, authority and required evidence, the permission is implicit and therefore unlimited.
6. Who approves, and is the approval on the path or beside it? A human in the loop who reviews after the write finds the data already changed.

In short

The medallion is not wrong: it is incomplete with respect to a use it never planned for and can no longer keep outside the door. Until I decide where an agent's writes land, all I can do is hope to catch its mistakes before the next rebuild. There is a single test, and you run it out loud with the vendor: if nobody can tell me who authorized that write and how to undo it, it did not land in the right place.