Why should an agent keep two clocks?
In the regulated enterprise, you either build a bitemporal system for agents, like WunderOS, or you waste time building anything else. Let me explain. When change happens, a system with one clock holds the current value and overwrites the old one, and by overwriting it destroys the only evidence of what it believed at the moment it acted on the change. This is medium-bad to awful for systems where the only agents are people.
But in a system where many agents aren’t people, it’s downright unworkable. An agent decided on its sincere belief, on a picture of the world. In systems with one clock, that picture is lost. So when someone asks later why the agent decided as it did, the honest answer, that we believed X at the time and X was later corrected to Y, is gone, because the system threw X away when it wrote Y.
This is not an exotic failure. It happens whenever the world changes faster than the record catches up, which is all the time.
Double-entry bookkeeping made it so first…
A customer’s income changed on the first of the month; the payroll feed reported it on the fifth; the underwriting agent read it on the sixth. Three dates, three different things, and a decision made on the sixth that was correct given what was knowable on the sixth and wrong given what was true on the first. A single-clock system collapses all three into one and can reconstruct none of them.
For people as for agents, life is lived forwards and understood backwards, and a record that means to answer for a decision has to do both. It has to carry what was so as it unfolds, and it has to let you read back what was known at any past instant. One clock can do the first. It cannot do the second, because it overwrites the evidence.
So WunderOS keeps two clocks. A technical fact, to be sure, but one directly compelled by user benefit.
WunderOS is natively bitemporal because agents have weird memories
In WunderOS, every fact is stamped along two independent axes: when it was true in the world, and when the system came to know that it was. A rate was three percent from March to June; the store came to believe that on the fourth of March and still believes it. The two do not coincide, and neither is derivable from the other.
That irreducibility is the point, and the user-benefit it secures is a system that can answer for itself: reconstruct exactly what the agent knew at the moment it acted, not what the record was later corrected to say.
A mortgage lending example
Let’s consider a real-world example. Under the Equal Credit Opportunity Act a denied applicant must receive an adverse-action notice within thirty days of the decision. In WunderOS, an agent arms a clause at the denial, then watches-and-waits:
◇⟦0, 30d⟧(:adverse_action_sent(app_88))
The system reads not yet known the moment the window opens and no notice has gone out. So far, so good. Then it flips to true the instant the notice lands inside the window, which fires the compliance trigger and satisfies the regulation. But it reads false at day thirty if no notice ever arrived, which is the violation the compliance agent is armed to catch.
One WunderOS query covers the early answer and the missed deadline both, and the verdict is pinned to the two axes at once, so a notice backdated in the world but recorded late counts only if it truly lands in the window on both.
The rewards of keeping two clocks
An agentic OS puts agents in the loop at machine speed, which multiplies the number of decisions, which multiplies the number of occasions on which the enterprise will be asked to answer for its choices. The two-clock record is what lets it answer without either guessing or lying. That is not a convenience. It is the precondition of deploying agents into a regulated process at all.
The full account, the query surface that reads the two axes and every operator worked against a single mortgage-underwriting run, is available at PLRN 018. It’s dressed as a “research note”, but it’s really just a description of user benefit and how it’s achieved.