Whichever interface keeps the most context that never gets written back.
That is not what the architecture diagram says, and it is not a criticism of any particular vendor. It is what happens by default when several interfaces write to shared state and nobody specifies the write path in detail.
Reads are the easy claim
Several doors into one record is a statement about reads: multiple entry points, same underlying data. That part is usually true, genuinely useful, and the part that gets demoed.
The write path settles ownership, and it never gets demoed, partly because it is boring and partly because it is often unfinished.
Every interface accumulates a local trace as exhaust from doing its job. The conversational one holds the exchange that preceded the action, including what the agent proposed first. The workflow tool holds the execution history and the retry that failed twice. The headless API holds the payload the caller actually sent, which is frequently not what lands on the record after validation and defaulting.
Only some of that is written back. The interface retaining the most unwritten context becomes where the real reasoning lives, which makes it the effective system of record by accumulation.
What survives, what does not
| Written back reliably | Usually lost |
|---|---|
| Final state | The reasoning behind the action |
| Timestamp | Alternatives considered and rejected |
| Acting identity | Retries and their failure modes |
| The reversal, and its cause |
The left column is what happened. The right column is why. The record keeps the what; the interface keeps the why.
And the reversal is the row that matters most. An action log without reversals is close to useless for improvement, because every entry reads as a success. The reversal with its cause is the only one carrying a lesson, and it is the most likely to be dropped, because it is an exception path and exception paths get cut when the integration runs long.
The test worth running
Reverse a decision in interface A. An hour later, open interface B.
Three possible outcomes, and they are three different products:
- B shows the corrected value, nothing more. You have windows onto a table. Useful, cheaper, and you should keep your own record.
- B shows a reversal happened, but not why. You have an audit trail. You will be able to count your errors and not learn from them.
- B shows the reversal with reasoning attached. You have what the diagram claimed.
Ask for that demo specifically rather than the logos slide, and ask early, while you still have leverage.
If you own the runtime
Put the trace at a chokepoint calls already pass through for another reason. In my own build, model calls route through a proxy because that is where credentials get injected at call time, so the proxy records the tier and the reasoning reference alongside the action. The trace gets written where the traffic already is instead of being reassembled afterward from whichever interface hosted the conversation.
If you do not own the runtime, you cannot do that, and you are dependent on the vendor's write path being more complete than it probably is.
The one thing to do this week: take the last decision an agent reversed in your stack, and count how many of your interfaces can tell you it happened versus how many can tell you why. The gap is the part of your observation record that is not yours.