Which Door Keeps the Receipt

I argued last week that the thing that compounds in enterprise AI is not the data. It is the observation record: which actions ran, which got reversed, by whom, how fast.

Ilja Torski pushed back in the comments, and he was right to:

That observation asset only stays with Salesforce if agents keep writing it back into the same record, and not every door guarantees that.

The whole problem is in that phrase. Writing it back.

The short version

A vendor claiming several interfaces onto one record is making a claim about the read path, which is usually true and is the part that gets demoed. Every interface also accumulates a local trace while doing its job: the conversation before the action, the retries, the payload the caller actually sent. Only some of that is written back, and whichever interface keeps the most unwritten context becomes the effective system of record by accumulation rather than by design. Final state, timestamp, and acting identity get written back reliably because the record cannot function without them. Reasoning, rejected alternatives, retries, and reversals usually do not. The test that separates a real multi-door architecture from four windows onto one table is whether a reversal made in one interface is visible, with its cause, from another.

Reads are easy, writes decide

Any vendor who tells you they have four ways into one record is telling you something about reads. Four entry points, same underlying data. That part is usually true, it is genuinely useful, and it is what the demo shows.

The write path is where ownership actually gets settled, and it never gets demoed, partly because it is boring and partly because it is often not finished.

Here is the mechanism, and it is not anybody's fault, which is what makes it hard to fix.

Every interface accumulates a local trace as a side effect of doing its job. Not as a feature. As exhaust.

The conversational interface has the exchange that preceded the action: what the human asked for, how the agent interpreted it, what it proposed first. The workflow tool has the execution history, including the retry that failed twice before it worked. The headless API has the payload the caller actually sent, which is frequently not the payload that ends up on the record after validation and defaulting.

Some of that gets written back. Most of it does not, because nobody specified it, and specifying it is work with no visible payoff in the quarter you do it.

So the interface that retains the most unwritten context becomes the place where the real reasoning lives. That is your system of record now. Not by decision. By accumulation.

What survives the trip

Three things reliably get written back, because the record does not function without them:

The final state, because that is the point. The timestamp, because everything downstream needs ordering. The acting identity, because compliance asks.

Four things usually do not:

The reasoning that produced the action. The alternatives that were considered and rejected. The retries, and what the failure was each time. And the reversal, with its cause.

Look at those two lists and notice that the first one describes what happened and the second one describes why. The record keeps the what. The interface keeps the why.

And a record of actions without reversals is close to useless for improvement, because every row looks like a success. The reversal is the only entry that carries a lesson, which makes it the most valuable row in the table and, reliably, the one most likely to get dropped in transit. It is an exception path. Exception paths are what get cut when the integration runs long.

This is the same argument I made about written context being rented, pointed at the write path instead of the archive. An imported wiki ports. An earned record of what your agents did and what happened next does not, and it is only earned if somebody wrote it down at the time.

Zero data retention answers a different question

Worth separating, because the two get conflated in every vendor conversation I have had this year.

"Your data is your data, it does not go into the models" is a promise about the model layer. It is the right promise, it is verifiable, and vendors who make it generally mean it.

It says nothing about who keeps the record of what the agents did.

That record is not the data you brought. It is generated by running agents against the data you brought, and it accrues wherever the agents run. You can have an airtight zero-retention agreement and still find that the reasoning behind eighteen months of decisions lives in a vendor's conversation history rather than in your record, because nobody ever asked the second question.

The test

Skip the four-logos slide. Ask for this instead:

Reverse a decision in interface A. An hour later, open interface B. Does it show that the decision was reversed, and does it show why?

Three possible answers, and they are three different products.

If B shows the corrected value but nothing about the correction, you have windows onto a table. Fine, useful, cheaper. Price and trust it accordingly, and keep your own record.

If B shows that a reversal happened but not the cause, you have an audit trail. Better. You will be able to count your errors and not learn from them.

If B shows the reversal with its reasoning attached, you have what the architecture diagram was claiming. In my experience you should ask to see it rather than assume it, and the asking is not rude, it is the only way to find out before you are eighteen months in.

The same question generalizes past any one vendor. Anywhere you have multiple agent entry points onto shared state, one of them is quietly becoming the real one. Worth knowing which.

What I changed

In my own build, model calls already pass through a proxy, because that is where credentials get injected at call time. I wrote about using that chokepoint for routing policy. The same chokepoint is the right place for this, and I had not been using it that way.

The change: the proxy now records the tier and the reasoning reference alongside the action, so the trace is written at the point every call already passes through rather than assembled afterward from whichever interface happened to host the conversation. It is the same principle as enforcement. Put it where the traffic already is, or it does not happen.

If you do not own the runtime, you cannot do that, and the honest version is that you are dependent on the vendor's write path being more complete than it probably is. Which is an argument for asking the reversal question early, while you still have leverage.

Pick one thing this week. Take the last decision an agent reversed anywhere in your stack. Count how many of your interfaces can tell you it happened, and how many can tell you why.

The gap between those two numbers is the part of your observation record that is not yours.

Sources: Ilja Torski, CSO at Pushwoosh, in a LinkedIn comment on the Dreamforce post, 2026-09-19.

This one belongs to the running argument on Enterprise AI Agents: what matters is what each completed outcome costs and what it teaches, and an architecture that keeps the outcome while losing the reasoning has kept the cheaper half.

Related answer: Who owns the observation record when agents run across several interfaces?