Open Data Infrastructure
Agentic Data Compensating Actions for Failed Writes
Why agentic write paths need compensating actions, replay evidence, owner approval, and table-state isolation when writes fail.
Agentic writes need a plan for being half right.
Failed writes are product behavior
An agent that writes data is not only producing an answer. It is changing system state. When that write fails halfway, succeeds against the wrong snapshot, or passes validation before a downstream check fails, the system needs a compensating action.
A compensating action is not a vague rollback wish. It is a defined operation that reverses, repairs, quarantines, or supersedes a failed write while preserving evidence about what happened.
Table-state isolation reduces blast radius
Open table formats help because snapshots, branches, and metadata history can give operators a concrete state boundary. Iceberg branches can isolate experiments. Snapshot history can help with review. Lineage can connect the failed action to downstream effects.
That does not make write failures harmless. It gives the runbook something real to operate on: the proposed action, table snapshot, affected records, validation checks, owner decision, and compensating action.
Core idea: agentic writes need recovery contracts before they need autonomy.
The ODI pattern links action to evidence
Open Data Infrastructure keeps write paths attached to table state, catalog ownership, policy, lineage, and evaluation evidence. That is what makes compensating actions reviewable instead of heroic.
Related articles include agentic data write approval queues, Iceberg branches for agent experiments, and agentic data replay logs. Failed writes are where those patterns meet.
What breaks first
Agentic write failures get expensive when recovery is improvised.
- The write succeeds, but the validation index refresh fails.
- A retry writes the same logical change twice.
- Rollback restores table state but not downstream cached context.
- A compensating action changes data without owner approval.
What the runbook should define
Define the write intent, allowed table state, validation checks, replay key, owner approval path, compensation operation, downstream refresh path, and incident record.
The agent does not need to own the recovery decision. The system needs to make the recovery decision possible.
Sources to start with
These primary sources anchor the technical claims in this guide.
- Apache Iceberg branching and tagging documentation
- Apache Iceberg table specification
- OpenLineage object model documentation
- OpenAI evals guide
Agentic data is not ready for writes until failure has a first-class workflow.