This Week in WunderOS
10 ways agents got more resilient this week
A. J. Ayer's old test for whether a sentence means anything was to ask what observable difference its truth would make. New capability earns its place in WunderOS in the same way. Hence, every item below is focused, first, on user benefit then, second, on details of implementation. And they're all marked honestly where the work is still in flight.
-
§1 Long-running agents stop falling over when their context window fills up.
Lager · context memory manager In flight
Reliability is key to WunderOS value prop, and how it manages an agent's context window is critical. The working context an agent reasons over is now managed the way an OS like Linux manages memory: a bounded resident set of what is needed now, a larger store behind it, and everything else paged in on-demand, across many kinds of content, not just one. And nothing is dropped when it is evicted; rather, it is written out to durable store and paged back verbatim the instant the agent reaches for it, so the working context is effectively unbounded and never silently forgets.
It's an MMU, for tokens instead of memory pages. A per-tenant page table tracks a resident budget sized to the model. Reach for something that got evicted and the reach itself is the fault—classified hit, fault, or drift—and a closed loop pages it back from durable store before your step runs. The page map is a lock-free, zero-copy copy-on-write snapshot, so readers never block the writer, and cross-class max-min floors stop any one page type from starving the rest.
-
§2 Fewer confidently-wrong answers out of memory.
Urteil · adjudication-first read In flight
When WunderOS's agentic memory can answer a question several ways, the system now adjudicates which source to trust instead of averaging them together, and only falls back to a cheaper, riskier path when that path is faithful to the evidence.
It adjudicates; it does not blend. Sharp query, direct resolve. Ambiguous query, fan out and let a residual combiner hand back a MAP estimate with an explicit ambiguity flag. Nothing resolves? Fall through to an RRF floor. The trick is the faithfulness gate: a cheaper arm only gets thawed once its answer measures faithful to the evidence it cited, and every adjudication drops an audit fixture, read side and write side.
-
§3Your agents run inside WunderOS unchanged and replay the same way every time.
QuickBEAM run-place · deterministic tool execution In flight
We expect WunderOS enterprise customers to write most of their agents in either TS/JS or Python. Via Quickbeam integration, agents in TypeScript or JavaScript run in-process—no subprocess, no remote sandbox—and two runs on the same inputs produce the same outputs, every time. That makes an agent's behavior auditable and replayable instead of a black box.
Register an agent with OAS and its TS/JS gets bundled with OXC and compiled to bytecode. At run-time a WunderOS Shadow Agent (i.e., a BEAM supervisory actor) runs that bytecode against a determinism seam:
Date,Math.random, entropy — all swapped for seeded, replayable sources. So a run is a pure function of its inputs, and you can replay it byte-for-byte from the decision log. Every host call goes through the four-outcome PDP, and a bytecode-level interrupt caps runaway loops. Not done yet: the runaway-interrupt and long-await caps. -
§4Agentic Memory is multi-tenant by construction, not by a check someone could forget.
Mandantenbaum · tenant isolation In flight
We landed the first big multi-tenancy epic this week, which puts WunderOS on the road to enterprise-grade capability. A tenant is a sealed subtree of the substrate with its own root for every read. The only way in is the door: a tenant key admitted at the gate scopes every read and write to the subtree it unlocks, and capability leaves as an opaque, tenant-scoped handle.
Isolation is structural, not a check you can forget to run. Each tenant is a subtree with its own root, and the door trades a tenant key for an opaque, tenant-scoped handle that every read and write resolves against. This week: the door (codename: Türsteher) went in front of per-agent ops and ingest; the HNSW index moved off shared
:publicETS into a per-context NIF substrate; and the routing registry became a private wardenDictinstead of a named table anyone could read. No ambient global surface, nothing for one tenant to enumerate in another. Lose the last sub-agent and the subtree gets rewired by single-component replacement, not rebuilt. -
§5When the context is full, you keep the most useful, least-redundant facts for a fraction of the cost.
Facility-Location eviction · what to keep under budget Behind adoption gate
More focus on agentic memory this week, not just the MMU. We also shipped a submodular selector that chooses what to retain so coverage stays high under a tight budget, rather than dropping memory by recency alone. A SIMD kernel made the choice 36.9× faster with byte-identical results.
The objective is facility-location: keep the subset that best covers everything else, not just the newest N. It runs as a lazy-CELF greedy: skip re-scoring any candidate whose marginal gain cannot beat the current best. A cosine-gram SIMD NIF plus a precomputed similarity cache were the keys to unlock that 36.9×, byte-for-byte identical output. The coverage sum is canonicalized over ground order so eviction replays deterministically. It stays off by default until the validation harness clears it on real workloads.
-
§6 An agent can try several approaches over memory and keep only the one that worked.
Gabelung · branch-and-commit over memory Shipped
Copy-on-write forking lets a run explore branches, then commit the one that succeeded or abort cleanly: speculative work that never corrupts the shared record.
Copy-on-write over the multi-reader/single-writer substrate. A branch shares structure with its parent until it writes, so forking N of them is cheap. Commit gates on the durability frontier—the same one crash recovery uses—and abort just drops the branch's private overlay. A GC keyed on a destruct-count reclaims branch resources, so nothing leaks across explore/commit cycles.
-
§7 Plain-language input is understood by who-did-what-to-whom, so recall respects meaning, not just matching words.
kāraka role-assignment · natural language into the graph Shipped
Following Pāṇini's kārakas, text is parsed into semantic roles—agent, patient, instrument, and the rest—before it enters memory, and those roles route into the Pentad's slots. Aspect (context and lineage) is recorded alongside, content-addressed.
Extraction and canonicalization are kept apart on purpose. A deterministic parse pulls the predicate the text actually states—open-vocabulary, ~0.87—a
slot_for(atom)call routes each kāraka to its Pentad slot, and an embedding gate either maps a surface predicate onto a canonical relation or keeps it verbatim. Context and lineage land as a content-addressed aspect record. No frontier model anywhere on the hot path. -
§8 Derived facts, including totals, transitive and recursive relations, stay correct on every ingest, with no manual recompute.
N-ary closure · rules that reach a fixed point In flight
Rules that aggregate (min, max, sum) or refer to their own conclusions now compute to a fixed point over the graph, idempotently, so the answers reconcile themselves each time new facts arrive.
My old RDF friends will recognize this one. I've been determined this time to avoid RDF's lack of n-ary relations, a tedious irritant for years. In WunderOS, n-ary relations and predicates are first-class objects from day one. A higher-arity rule reuses the exact same CSR hop machinery as binary relations; that is,
CsrHopplus role filter and extract, no new kernel, no new plan node. Close the relation, re-materialize the n-ary facts, done: a transitive or recursive relation computes once and gets reused. Min and max are idempotent-lattice aggregates, so they hit a fixed point directly; sum cannot, so it rides a Sum-DAG with non-monotonic retraction. Counts stay right when facts are withdrawn, not just when they are added. -
§9Different parts of your organization can hold conflicting views of the same fact — and the system keeps every one, weighs them, and picks a single answer only when a decision forces it.
Social Memory tier · perspectival truth In flight
This one begs for some context, which is ironic, as you'll see. Agentic AI means lots of new-found concern for things like context, semantics, and data integration. Paying people to do Customer Support without Customer360 is one thing; replacing or supplementing them with agents without Customer360 is another. But what's the easiest way to source those views for agents?
There is no view from nowhere. A bank, a supply chain, a hospital...each has no record of an entity that is true from no perspective; it has many situated views that disagree. WunderOS keeps the views rather than flattening them on arrival, and fuses them only at the moment a decision needs a single frame and, even then, records what it set aside. This is the tier the enterprise actually lives in, and it is where a good deal of this week went.
The machinery earns a paragraph. Every claim is a Subjective Logic opinion—Jøsang's
⟨belief, disbelief, uncertainty, base-rate⟩tuple—so "probably true, but I am not certain" is a first-class value, not a rounding error. Opinions combine with Jøsang cumulative fusion (the kernel issl_ops.fuse), and this week that fusion became order-independent by construction: beliefs map to Beta evidence accumulated in a fixed-point integer quire, so the fold is byte-identical under any permutation. That is not a nicety: in multi-agent scenarios, opinions arrive over a gossip protocol (codename: Gerede) that promises nothing about order and reconciles partitions with Merkle anti-entropy. Order-invariant arithmetic is the only thing that makes gossiped belief safe.How much to trust a source is a computable, objective Glicko-2 rating: its skill μ, its uncertainty φ, its volatility σ, updated like a chess ranking; μ and φ project into the opinion's belief and uncertainty, σ stays out of the payload. Competing opinions on one matter live in a Fallakte, that is, a case file (a typed, versioned Gleam dictionary, if you will) you can hand from one agent to another, whose order-independence is proven, not hoped.
And the frame over all of this is depth-1 S5 epistemic logic: the system reasons about who knows what—"has agent B been told that A finished step k?"—where knowledge is an S5 equivalence class over the gossip group, and depth-1 (no "A knows that B knows") keeps the model-checking linear.
-
§10 An interrupted or crashed agentic run heals itself, resuming from a durable checkpoint instead of losing work or replaying blindly.
Frontier-gated commit · self-healing runs Shipped
I call WunderOS autonomic and it's capability like this that justifies saying it's so. Autonomic means self-healing and these changes contribute to reliability.
Forward progress, crash recovery, and stuck-then-parked Customer Agent runs now resume through one validated frontier, and the known-set survives a restart. This is the reliability lever from Issue 2 made real: a bad run that recovers on its own never costs a human an intervention.
One durability frontier gates all three paths: forward progress, crash recovery, park-and-resume. Commits only advance past a validated frontier. On crash, WAL replay is bounded and routed through the same
recover_gatedseam instead of blindly re-applying. The known-set is durable, so faults survive a supervisor restart, and the write-back journal rejects an empty page before it can commit. The run comes back from a point it can prove, not whatever it happened to be doing when it died.
On the drawing board
Leitstand · Gartenhaus Designed, not yet built
Leitstand (ADR-092) is a human operator's time-travelling debugger: replay a Customer Agent's execution history step by step to see exactly how a decision was reached rather than reconstructing it after the fact; allows precise interventions to working memory, rules, and tools as any decent debugger provides.
Gartenhaus (ADR-094) is a VSA-native institutional-memory tier: what an organization knows as a whole, held distinctly from any one agent's working memory, derived from enterprise lakehouse or data warehouse materialized views. Enterprise context engineering is, first and foremost, an enterprise data silo integration problem.