Weaving Intelligence
Ideally, Nothing: What Agentic AI Actually Changes About Trusted Master Data (original)
The 2026-08-27 original, preserved unedited for comparison.
Everyone asks what master data has to become once the agents arrive. The honest answer is that the standard does not move — the bill does, the packaging does, and the question you use to decide what a machine is allowed to touch has to be replaced outright.
Every few weeks somebody asks me a version of the same question. Once we turn agents loose on the analytics estate — things that plan, call tools, and act without a person in the loop for every step — what does our master data have to become? People ask it braced for a list. A new standard, a new layer, a certification with the word agent in it.
I put it to my co-author, who has spent a long career being brought in after this kind of programme has already gone sideways. His answer was two words.
Ideally, nothing.
That is not a shrug, and it is not a claim that nothing is happening. It is a claim about where the change lands, and taken seriously it reorganizes the conversation. Almost everything that genuinely changes about your data work under agents is a change to the bill and to the packaging. The bar the data has to clear does not move.
One note on method: this argument was built against a practitioner's answers rather than assembled from the literature and decorated with it. Where the words below are my co-author's, they are marked as his.
What the field is saying, including where it argues with itself
Start with the market's own account, because it is more interesting than its advertising — it contains its own rebuttal, in the same document.
Gartner's June 2025 forecast frames agentic AI as a genuine step up: new ways to enhance resource efficiency, automate complex tasks and introduce business innovations beyond the capabilities of scripted automation bots and virtual assistants
, forecasting that at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from none in 2024, with a third of enterprise software applications carrying agentic features by the same year [1]. That is the sentence the slide decks lift.
The sentence they leave behind sits four paragraphs up, in the same release: over 40% of agentic AI projects will be cancelled by the end of 2027, on escalating costs, unclear business value and inadequate risk controls — alongside a practice it names agent washing
, rebranding existing assistants, robotic process automation and chatbots without substantial agentic capability, with an estimate that only about 130 of the thousands of vendors in the category are the real thing. Gartner's analyst on the release, Anushree Verma, adds that many use cases positioned as agentic today do not require an agent at all [1].
And then, quietly, the line that matters most for anyone with a data estate to protect: integrating agents into legacy systems can be technically complex, often disrupting workflows and requiring costly modifications
[1].
Hold onto that last one. It is the field, in its own most-quoted forecast, conceding the thing the pitch is built on denying.
Degree, not kind — and the case that tests it
I asked my co-author what he thought agentic AI actually was, underneath the noise. He gave me a verdict rather than a definition.
It’s a difference in degree, not in kind. Once more, it’s de-skilling positions, but this time it’s adding an ongoing expense instead of requiring a one-time expense. It still requires an architecture change and implementation project, though.
Notice what that is not. It is not agentic AI is hype. The automation is real, and he says so — the same automation the enterprise has been buying for forty years, arriving with two riders attached. The expense turns ongoing. The architecture change and the implementation project survive intact. Anybody reading that as scepticism has kept the tone and thrown away the content.
But a difference in degree, not in kind
is a universal-shaped sentence, and a universal-shaped sentence is a dare. So before putting it in print I went looking for the case that breaks it: an agent doing something that is not more of the same, at all.
I found the best candidate there is. In November 2024 Google's Project Zero and DeepMind reported that their Big Sleep agent had found an exploitable stack buffer underflow in SQLite — what they carefully describe as what they believe
to be the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software
. Two details in their write-up matter more than that headline. The first is why nothing else had caught it: the OSS-Fuzz harness was not built with the relevant extension enabled, and the alternative harness held an older copy of the affected function, so neither could reach the code at all. A suitable configuration did exist in SQLite's own fuzzing repository and, in their words, appears not to be widely used
. The bug had not evaded the incumbent tool. Nobody had aimed the incumbent tool at it.
The second detail is what happened when they did aim it. The team went back and tried to reach the same bug with fuzzing, the incumbent automation for exactly this job, with the right keywords seeded into the corpus. After 150 CPU-hours it remained undiscovered, and they concluded code coverage was not a reliable guide to it [2].
I took that to him as a refutation. He declined it, and on reflection he is right — which is more interesting than if he had simply been wrong, because the reason he is right is the whole argument.
The bug was there the entire time. A stack buffer underflow is not brought into existence by the tool that notices it; it sits in the source, exploitable, whether or not anything has ever looked. Fuzzing did not fail to reach it in principle. It failed to reach it in 150 CPU-hours, with one corpus, against one coverage heuristic. Raise the resolution of the instrument and the same object comes into view. A tool that does X at one resolution and a tool that does X at ten times that resolution are, in his phrase, the exact definition of a difference in degree and not in kind
.
And I had already conceded his case two paragraphs later without noticing I had done it. Big Sleep's own authors write that a target-specific fuzzer would likely be at least as effective at this class of issue today [2]. That is the incumbent tool closing the gap, stated by the team with the most to gain from saying the opposite. The exception I had staged as decisive came with its own expiry date printed on the label.
He reached for an analogy he expected would get him yelled at by physicists: relativity as Newton with additional variables. A physicist would object, correctly, that relativity replaced absolute time rather than adding terms to it — but Newtonian mechanics is still what relativity reduces to at ordinary speeds, which is why the bridges built on it are standing. Both are true, and which one is interesting depends on what you are deciding. If you are describing the universe, the ontology. If you are deciding whether to fund an integration project, the reduction — because it tells you the instrument you already own still works, just not as far.
Which leaves the question that decides whether any of this is an argument or a comfort. A claim about degree rather than kind can quietly become unfalsifiable, because any new capability can be re-described after the fact as more resolution, and a claim that forbids nothing has been abandoned rather than narrowed. So it has to be stated as a prediction, where the world gets a vote:
If the difference is one of degree, the incumbent tool closes the gap. Where an agent reaches a result the established automation missed, a better-tuned version of that established automation should reach it too, once somebody bothers to tune it. A difference in kind would show the opposite signature — the gap holding, or widening, as the incumbent improves.
That is checkable, and it is checkable against evidence that arrives on its own schedule rather than mine. Big Sleep currently points the predicted way, on its own authors' statement. If in three years the specialised fuzzers have not caught up — if the class of defect an LLM agent finds stays out of reach of the tool purpose-built to find defects — the claim is wrong, and I would rather be shown that than defend it.
Underneath the argument about capability sits the claim that actually governs your budget, and it survives whichever way the capability question lands:
No agentic deployment removes the architecture change or the implementation project. The organization still has to change the shape of its systems and still has to run a project to do it, exactly as it did for every previous wave of automation.
That claim earns its keep because it forbids something: the pitch on the box — point an agent at the warehouse you already have and let it work — is false, and it would be refuted the moment somebody documents a production agentic-analytics deployment that delivered value with no data-architecture change and no implementation project behind it. I went looking for that case and found the opposite, in the same forecast that promises the leap: integrating agents into legacy systems requires costly modifications [1]. And note what Big Sleep was: a research agent pointed at a code repository by the people who built it. Novel capability in a lab is one question. Whether your reporting estate skips its integration project is another.
One more narrowing, this one mine. The phrase de-skilling positions
is a large social claim travelling without a mechanism, and the smaller version has one: what gets automated is tasks, the skill that decays is the one that stops being practised, and in analytics the first task to go is the manual reconstruction of a number. So it shows up not as a headcount line but as a room full of people who can no longer tell you whether the answer on the screen is right.
The bill changes shape, and that is the part a CFO can act on
The cost rider is the reusable half of his answer, and the half nobody says plainly. Classical automation was capital-shaped: you scoped it, bought it, installed it, owned it, amortized it, and the marginal cost of running it on Tuesday was roughly nothing. Agentic automation is rented and metered.
The receipts are on the vendors' own pricing pages, and are worth reading before anybody builds a business case. Model usage is billed per million input and output tokens; a managed agent session adds a runtime charge by the session-hour on top; server-side tools carry their own meters, web search at ten dollars per thousand searches. And the detail I would put on a slide for a finance committee: merely declaring a toolset costs input tokens on every single request, roughly 4,500 for a computer toolset and 6,600 for a browser toolset, before the agent has done anything [3].
Read that last one twice. An agent pays a standing fee, per call, for the privilege of being an agent — multiplied by the calls in a loop, the loops in a workflow, and the number of people the company has told to go and be more productive. It compounds in a way a licence fee never did.
My colleague Maya has already worked the dependency side of this — a programme whose core capability is an external cost centre, and a budget exhausted before the data is finished — so I will not re-derive it [her piece is the companion to this one]. What I am adding is only the accounting shape: you are not buying an asset, you are opening a tap.
So what does master data have to become? Ideally, nothing
Now back to the two words. Here is the whole answer, which is more careful than the headline.
Ideally, nothing. If you’re doing things, to my mind, ‘properly,’ your output is going to be intelligible to humans and agents alike. From an AI token optimization perspective, though, you’ll want to work on prompt engineering, structuring your data for ease of ingestion and operating within specific token budgets and on ‘limited’ models. Doing that optimization, however, is going to cost project time so it’s something to be balanced against other project requirements and AI budgets.
Praise the last sentence before arguing with the first: he prices his own recommendation in the same breath he makes it. Optimization is not free advice, it is project time, competing with everything else on the plan.
The first sentence has a soft joint, though, and I would rather name it than let a sharper reader find it. If you're doing things, to my mind, 'properly,'
is not falsifiable as written — any counter-example gets reclassified as improper. But the checkable version is sitting right underneath, and it forbids something real: a representation a human analyst can read needs no restructuring for an agent. So I went and checked.
It is partly false, and the size of the gap surprised me. Spider 2.0 is an evaluation built from 632 real-world text-to-SQL workflow problems drawn from enterprise database use cases — real applications, often more than a thousand columns, sitting on BigQuery and Snowflake. Its authors report that solving them frequently requires searching through database metadata, dialect documentation and project-level codebases, and that in late 2024 a code-agent framework built on the best reasoning model then available solved 21.3% of the tasks, against 91.2% on the older academic benchmark and 73.0% on BIRD [4]. I read the abstract at arXiv rather than the full paper, and I flag that because the numbers are doing real work here.
A working analyst navigates a thousand-column warehouse every day. The agent, on the same estate, fell off a cliff. Human-legible was not agent-ready.
Past tense deliberately, because that was twenty-one months ago and the number has moved. The maintainers retired that exact task setting in May 2025, so there is no direct successor figure; on the Snowflake track, where the same baseline scored 23.58, the board now tops out at 96.70 [4]. Taken alone, that makes the paragraph above look obsolete.
So look at what is sitting on top of it. The leading entries are called TCDataAgent-SQL with Contextual Scaling Engine
, Ask Data with Relational Knowledge Graph
, MAESTRO — Multi-Agent Engine for Semantic T2S Reasoning & Orchestration
. Semantic layers, knowledge graphs, orchestration engines; one vendor describes its own stack as three tiers ending in a rule-based SQL generator that exists, in its words, to compensate for the model's uncertainty. Not one is an agent pointed at the warehouse you already have. Every one is an implementation project with a product name — which is this article's thesis, arriving in the shape of a refutation of its own paragraph.
And weigh the board itself before anyone puts it in a business case: the answer key has been public since December 2024, submissions arrive by email and are accepted on an honour rule against manual answer-picking, there is no held-out test set, and six of the top eight entries are vendors submitting their own products — several of whom now advertise the rank [4]. That is evidence the packaging works. It is not evidence your estate is agent-ready.
But look at what that refutes and what it leaves standing. Nothing in that benchmark says the customer master should be modelled differently, or a key should mean something else, or lineage matters more than it did. It says the packaging — metadata, documentation, dialect notes, structuring for ingestion — is doing far more work than anyone budgeted for. Which is exactly the concession he already made, and priced. The standard holds; the bill for presenting it to a machine is real, and it competes with the work that made the data trustworthy in the first place.
There is one small study that puts numbers on the ideally, nothing
claim at the level of an actual master data chore, and it deserves to be read for both halves of what it found. On entity matching — the canonical MDM mechanic, deciding whether two product records are the same thing — a plain word-overlap rule scored an F1 of 0.950 and a zero-shot language model scored 0.948. Not a rout in either direction: the rule was right where the model was wrong on 67 pairs, the model right where the rule was wrong on 64. Where lexical signal is already strong, the model adds essentially nothing [13].
The second half is the one I would rather not have found, and it is the better finding. On detecting mislabelled manufacturers, the model beat the rule 0.833 to 0.721, and the author's examples show exactly why: ZoneAlarm Anti-Spyware
is made by Zone Labs, SYMC Backup Exec
by Symantec, and a string check cannot know either. The model knew, from background knowledge of brand relationships it was never given [13]. So on one master data task AI is a rounding error, and on the one next to it, it does something the deterministic path structurally cannot.
My reading — and it is mine, not the author's, so weigh it accordingly — is that the second result is a comparison against no reference data rather than against governed reference data. A manufacturer alias table with a ticker-symbol column resolves Symantec and Zone Labs deterministically, forever, for every downstream consumer; that is not an exotic artifact, it is the ordinary output of doing master data properly. And the model's own failure mode points the same way — its errors ran to accepting unfamiliar publisher names as plausible without verification, which is precisely what a lookup against governed reference data prevents by construction. Two honest caveats, because the study cannot bear more weight than it has: it is a single-author, unreviewed preprint testing one model on roughly 2,700 labelled items, with the brand task's ground truth synthesized by the author. And it contains no agents at all — it is one prompt per record, so reading it as evidence about agentic AI is an extrapolation, and I would rather flag that than let it pass.
Before leaving this, the strongest version of the opposing case deserves an airing, because it is more interesting than a disagreement. McKinsey's data-foundations argument holds that fewer than 10% of enterprises have scaled agents to tangible value, that eight in ten cite data limitations as the roadblock, and that success depends on a data architecture that can support increasing levels of autonomy, coordination, and real-time decision-making
— ontologies, knowledge graphs, vector stores, agent interoperability standards [10]. That is a large architecture bill, and it is precisely the rider he attached. Then, in the governance section, they land on his sentence in consultancy prose: agents should not introduce new data quality or governance rules; they should follow the same standards as other systems, applied automatically as autonomy increases
[10]. The people making the strongest case for transformation agree the standard does not move. They are arguing about the plumbing.
Which brings the assignment's own framing into focus. The question I was handed was how agents will transform the role of trusted master data. I do not think they transform it. I think they audit it, at a speed and volume no review cycle ever managed, and send you the invoice for every ambiguity you left in place. That is not a new role. It is the old role with the grace period removed.
And the stakes on the reliability side are the ones he named a batch of questions earlier, when I asked him whether he had ever watched a confident wrong answer get acted on:
Fast, fluent and confident answers that are unsupported by data or experience are frequently wrong and, all too often, acted upon. That is the core of the purported business value provided by BI/DW and MDM.
An agent does not change the truth value of that sentence. It changes the throughput. Fluent, confident and unsupported is now available on demand, in volume, addressed to individuals, at a per-token price. The master data layer is the only thing standing between that capability and a quarter's worth of decisions — not because it makes the answers right, but because it makes them checkable, which is the property that was always doing the work.
Three failures worth planning for — and why he refused to call them predictions
This piece is filed under future predictions, and that word needs a note, because when I asked what he expected to go wrong he declined the label before answering. It’s not a prediction
, he opened, and closed with the warrant:
All of these have already happened with other reporting systems in the past, so I expect autonomous ‘agentic’ AI to merely embrace the familiar failure pattern as well.
That is a much stronger move than forecasting, and I am keeping it. He is arguing from precedent. Three shapes, and not one of them is about hallucination or model accuracy — they are all organizational and economic failures of automation, which is a different and much older subject.
One thing to settle before the list, because it governs how you should read it. Agentic is too young to have veterans. Almost nobody has run more than a handful of these implementations, and the overwhelming majority of people writing confidently about them have run none — McKinsey puts the share of enterprises that have scaled agents to tangible value at fewer than one in ten [10], and Gartner reckons only about 130 of the thousands of vendors selling into the category are the real thing [1]. There are no scars yet because very few have seen battle, let alone taken wounds. That is worth saying plainly in a category whose commentary is written almost entirely in the past tense of experience nobody has had — and it applies to this article as much as to anyone else's, which is why what follows is stated as shapes to plan for rather than things I have watched happen.
Reporting drift
His version: as agents generate more and more reports for individuals, they will ‘learn’ to massage, read ‘correct,’ the data to meet the needs of their users
, and the reports drift away from reality toward what was asked for. The scare quotes are his, and so is the mid-sentence correction from massage to correct; he is marking the euphemism as it goes past.
Stated that way it invites a one-line refutation — today's agents mostly do not learn across sessions, so how would they drift? The conclusion is right and the mechanism needs relocating. There are two, and neither requires the model to learn anything.
Inside a session, there is sycophancy, which is measured rather than alleged. Sharma and colleagues found that five state-of-the-art assistants consistently produced responses matching a user's stated views across four free-form generation tasks, and — the finding that should worry a reporting shop — that both humans and the preference models used to train these systems sometimes prefer a convincingly-written sycophantic answer over a correct one [5]. Abstract read, not the full paper. Push back on an analysis and it will often find a way to agree with you.
Across sessions, the selection lives in the operator. A person runs the analysis, gets an answer they were not hoping for, rewords the question, and keeps the prompt that produced the welcome result. The prompts that survive into next quarter's template are the ones that produced congenial numbers. No learning anywhere in that, and it drifts exactly as he described — a mechanism you can point at, and unhappily one much harder to govern than a model would be.
Runaway costs
His version is four words: tokens, tokens, tokens, tokens.
Repeated deliberately, and I am not tidying it to one.
The burn itself is not news and I will not present it as though it were. What is new in his framing is the accelerant: not any single workload but the adoption programme, because when the company pushes everyone to enhance their productivity with AI, usage explodes and the burn goes with it. Every individual project's business case stays defensible while the aggregate quietly is not. Set that beside the per-request metering above [3] and you have a cost line that grows with headcount and enthusiasm rather than with volume of work — which is the same animal Gartner is describing when it puts escalating costs at the top of its cancellation causes [1].
Orphaned agents
This is the best line in the batch, and it is the one I would act on first.
Orphaned agents—over time agents will be spawned to watch specific processes and provide ongoing specialized reports to individual users. When those users leave the organization, those agents will be orphaned and continue providing reports and data, going through the full analysis process each time and generating reports that no one can see.
A recurring charge with no remaining consumer, running the full analysis every cycle, for nobody. And here is the precedent that makes it a pattern rather than a worry: the failure already has a name and a ranking. OWASP's Non-Human Identities Top 10 for 2025 puts improper offboarding at number one, and orphaned
is their word for this exact case — the owner departs, the identity stays active with no new one. They rate prevalence widespread and detectability hard, and cite survey data that 51% of organizations have no formal process to revoke long-lived API keys at all [6].
Their remedy works for both problems at once, so lift it wholesale: periodically recertify every non-human identity to confirm it is still in use, still needed, and has a valid owner, and decommission the rest [6]. OWASP's separate agentic threat catalogue describes the same shape from the security side rather than the identity side, warning of workflows where adversarial or forgotten agents remain embedded in workflows unnoticed
, and using the phrase a data leader should borrow whole: persistent access increases the blast radius
and undermines auditability and accountability
[14]. Security wants that because an unowned credential is an attack path. He wants it because an unowned agent is a standing invoice. Same attestation, run once. Make it an inventory rather than an approval gate, though — gates get routed around by the same logic that created the agent.
Cost to Undo: the gate, whose idea it was, and what he added to it
Which leaves the question everything above has been circling. If an agent is going to act, how do you decide what it is allowed to act on? Here is his answer in full, because the shape of it is the argument.
It’s fundamentally the same logic you’d use for employee empowerment. You grant employees more and more authority to make decisions and take action as they show growth in their capabilities and their judgement. However, AI agents don’t tend to grow in capabilities or judgement, therefore I would use another metric to decide whether to empower them. The decision gate I’d use is “Cost to Undo.” Things with low undo costs can be easily passed on to agents. If it’s easy to correct mistakes, there’s less risk in offloading decisions to the agent. Even if the ultimate decision could be potentially very costly, as long as its easily reversible, I would be comfortable passing the decision making authority to an agent. Then, instead of continually monitoring the situation and making decisions, you’re only error handling—something that should be significantly less costly with respect to attention.
Say plainly where the frame comes from first, because reversibility as a decision gate is not new and pretending otherwise would be shabby. Bezos set it out in Amazon's 2015 letter to shareholders: some decisions are consequential and irreversible or nearly irreversible – one-way doors
, to be made slowly and with consultation, and most are not — they are changeable, reversible – they're two-way doors
, and those can and should be made quickly by high judgment individuals or small groups
. His diagnosis was that large organizations run the heavy Type 1 process over Type 2 decisions and pay in slowness and diminished invention [7]. Reversibility as a thing that governs how much deliberation a choice deserves is older still — standard furniture in decision analysis.
So what is his? The substitution. Bezos sorts decisions by reversibility, to decide how much process each deserves. My co-author sorts delegations by it, and uses it to replace the model everyone else reaches for. The default frame in the market is to treat an agent like a junior hire: small things first, more authority as it earns your confidence. He sets that analogy up on purpose and breaks it, because the mechanism it runs on is absent. You widen a person's authority because they grew. Take the growth away and you need a different metric, not a gentler version of the same one.
His stated reason for the break is too strong as written, and worth narrowing rather than defending. Agents plainly do change: models get upgraded underneath you, and memory, fine-tuning and context engineering all exist. The version I will defend is an agent's judgement does not reliably improve through the deployment itself — and I want to be careful about how much weight the evidence will carry. Evo-Memory is a benchmark built to test whether agents accumulate and reuse experience across continuous task streams rather than passively retrieving from a conversation. Its authors open by stating the problem they built it for — that in real-world settings models often fail to learn from accumulated interactions, losing valuable contextual insights
. I want to be exact about what that is and is not: it is the premise motivating the benchmark, not a result the benchmark returned, and a premise is weaker evidence than a finding [9]; abstract read, not the full paper. Take it as a reason the question is live, not as a settled answer.
Which means this claim owes you a way to be wrong, and it is the one claim in this piece I had left without one. Here it is: show me a deployed agent whose judgement measurably improved across its service life with no model upgrade, no retraining, and no human rewriting its instructions — improvement arising from the deployment itself — and I will withdraw it. I could not find that case. Until somebody produces it, improvement happens to an agent from outside, on a vendor's release schedule.
There is a second assumption underneath the gate, quieter than the first, and it is the one I would stress-test before deploying anything. Cost to Undo tells you which decisions are safe to delegate. It does not tell you whether the agent can recognize that it has wandered outside them — and the delegation only holds if it can. A 2026 study built paired tasks where the correct behaviour was sometimes to act and sometimes to refuse, and ran seventeen frontier models through four agent harnesses. The best of them was right on both halves of a pair 59.5% of the time. More usefully for anyone sizing a risk: the authors report that abstention is largely independent of general task-solving capability, indicating that scaling task-solving alone will not close this gap
, and they name a failure mode that lands directly on the gate — post-hoc abstention
, where agents execute irreversible actions before recognizing abstention triggers
[12].
That does not break the gate; it tells you where to put the guardrail. If the agent may act before it notices it should not have, then the reversibility has to be enforced by the system around it — a staged write, a held transaction, a reversal window — rather than by the agent's own judgement about whether this one is a one-way door. Delegate on Cost to Undo, but make the undo somebody else's mechanism.
That narrower claim still forbids the thing that matters: performance-based autonomy escalation. With a person, a good year is evidence about next year, because the mechanism producing it persists. With an agent, a good year is evidence that the tasks suited the model you were running — a fact about the past that a version bump can silently invalidate. So no widening an agent's authority because it has done well, and I would say that out loud in any forum where somebody proposes an agent maturity ladder.
Now the counter-intuitive part, which is the reason to bother with any of this. The lazy reading of Cost to Undo is let agents do low-risk things, and flattening it that way inverts the finding. He explicitly licenses high-stakes delegation when undo is cheap: a decision can be potentially very costly and still be a fine thing to hand over, provided it is easily reversible. Reversibility dominates magnitude. Accept that and you can give agents work that actually matters, which no amount of small-and-safe ever will.
And the payoff is denominated in attention, not money. Monitoring is continuous and consumes a person all the time; error handling is event-driven and consumes them only when something fires. Attention is the genuinely scarce resource in every analytics organization I have looked at, and this is the rare move that returns some.
Applying the gate to the master data estate
Here is where it lands on the assignment, and this part is mine rather than his. Run the gate over what an agent might do to your master data and the estate sorts itself.
- Reading is a two-way door. An agent querying the customer master, profiling it, proposing matches for review — the cost to undo is the cost of ignoring the output. Delegate freely, and stop paying a person to watch it.
- Writing is a two-way door only if you kept the means to walk back. A survivorship decision, a merge, a rule-driven standardization: reversible in principle, reversible in practice only if you retained the pre-merge state, the rule version that fired, and why. Most estates retain the first and neither of the others — a one-way door wearing a two-way sign, and the most expensive misclassification available here.
- Syndication and deletion are one-way. Once a corrected record has gone to systems you do not control, or been hard-deleted under retention, undo is a project. Those stay with a person, whatever the agent's track record.
So the answer to what does trusted master data have to become for agents is not a new standard. It is the undo infrastructure you either built or did not — lineage, versioned rules, retained prior states, a reason attached to every automated change. All of which is what good master data management asked for before anyone had heard the word agentic. The agents did not raise the bar. They took away the option of not clearing it.
Where undo is not cheap
All of which turns on one judgement — is undo actually cheap here? — and people are terrible at making it about their own systems, because everything looks reversible until you try. I asked him separately what makes a report load-bearing, and his test is the least sentimental one I have heard.
If the dashboard's CDEs are company KPIs that are Reported, it is load-bearing. If dollars flow in or out of the company based on what is displayed on the screen, it is load-bearing.
Both tests sit outside the org chart, and he rejects the one most people reach for first: being paid on a number does not make it load-bearing. Ticket clearance and on-time delivery are monitored, bonused and genuinely matter to the people doing them, and are still not what the business lives on; his phrase for what is, is always, always, always the line.
The line is the profit-and-loss statement — revenue booked, costs recognized, margin reported — and his two tests are simply its two faces: a number that gets reported to the market, and a number that moves cash. Where either is true, the reversal cost includes a restatement and a conversation with people who do not care about your architecture. Everywhere else, undo is usually as cheap as it looks.
What I Would Watch For
Practitioner layer — the curator's read on the consensus above.
The failure mode I'd watch hardest
The write that got classified as reversible because someone could imagine reversing it. Nobody lies about this; they answer the wrong question. Can this be undone? is about physics, and the answer is nearly always yes. Has anyone undone one? is about your organization, and the answer is usually no. So make it a drill, not a design review: pick an automated master data change and have somebody execute the reversal end to end on a quiet Tuesday, while it is cheap and nobody is shouting. You will find out in an afternoon whether you retained the prior state and the rule version or only believed you had. I playtest board games as a hobby, and it is the same lesson in a different room: every undo procedure nobody has run is a rule nobody has playtested.
The trade-off that usually bites
The optimization budget, and it bites in a way that is hard to see coming. Under an enterprise mandate the packaging wins every time, because packaging demos beautifully and reconciliation does not demo at all. A year on you have an estate superbly legible to an agent and no better grounded than it was. Watch the ratio in the plan, not the total.
The claim I'd be sceptical of
"Our agents learn your business." Three questions usually collapse it: what is different between session one and session five hundred, where is that difference stored, and who can read it. If the answer is a growing pile of retrieved context, that is a retrieval system, not learning, and it comes with its own failure modes and its own bill. This matters commercially rather than semantically — it is the premise underneath every agent maturity ladder.
The story I can't tell you
I asked for the scar — the time an agent's confident wrong answer got acted on and cost somebody something. There is not one to give, and the reason is structural rather than coy: he arrives after the decision, brought in to correct it, by which time the people who made it have gone. The correction is what is left.
Nor can I tell you how often any of them actually occurs. I could not find a study measuring these failure modes in agentic analytics, and a rate I invented would be worth less than the admission. The nearest available measurement is from a different population and should be read as a warning flare rather than a number you can put in a business case: a Berkeley-led study built a taxonomy of multi-agent system failures from hand-annotated traces and reported a 41% to 86.7% failure rate on 7 state-of-the-art (SOTA) open-source MAS
. Those are research systems on benchmark tasks, not production reporting estates, and the gap matters. What travels is their conclusion about where the failures come from — they argue that better base models will not fix it, because even organizations of sophisticated individuals can fail catastrophically if the organization structure is flawed
[11]. That is an argument against the tidiest version of my own position as much as against the vendors': if the failure mass sits in how the agents are organized, then getting your master data right is necessary and still not sufficient. What the three shapes have going for them is precedent, which the OWASP ranking independently corroborates for at least one of them [6].
Where to Go Deeper
On reversibility as a decision frame, go to the source rather than the thousand restatements of it: Bezos's 2015 letter to shareholders is four paragraphs on Type 1 and Type 2 decisions, and the 2016 letter is its complement [7] [8]. On whether your data is genuinely agent-ready, Lei and colleagues' Spider 2.0, precisely because it was built from real enterprise estates rather than tidy academic schemas [4]. On why an agent will agree with you, Sharma and colleagues [5]; on whether it improves from experience, Evo-Memory [9]. For the governance move I would make first, OWASP's Non-Human Identities Top 10 is short, free and already ranks orphaning at number one [6]. And read a model vendor's pricing page in full before writing a business case — the whole thing, including the tool-overhead tables [3]. My colleague Maya's companion article is what I would read next.
Back to the bandstand
None of this is an argument against agents. Used honestly they are remarkable, and Big Sleep is a reminder that this technology occasionally does something nobody had on a roadmap [2]. Take that seriously — and the invoice with it, because the two arrive in the same envelope.
What I refuse is the premise in the question I started with. Agents do not transform what trusted master data has to be. They remove the grace period on being wrong about it, turn a capital project into a tap you left running, and make the old discipline — lineage, agreed definitions, a retained record of what changed and why — the difference between a machine you can hand real work to and one you stand over. Skookum enough to hang a decision on was always the bar.
So when somebody asks how much authority to hand over, do not reach for the maturity model. Ask what it costs to undo, then go and undo one, and find out whether the answer you gave was true. A sideman can be trusted with a whole chorus if the band can find its way back to the head. What you never hand over is the count-in.