Why I’m building WunderOS

Why this. The biggest problem I can do real work on is the reliability of agentic automation in regulated industries.

Why me. I was the founding CEO of Stardog, the first enterprise-grade knowledge graph platform: AI-adjacent from the start, AI-first after Stardog Voicebox.

WunderOS Design Principles

  1. P95 latency obsession. It matters even when the LLM is slow (most of all then), and even when no human is waiting on the result. Latency compounds across every step an agent takes inside one task; the user sees only the sum. The substrate is held to the latencies, and the rigor, of high-frequency trading.
  2. Bias against LLM calls. WunderOS internally prefers jobs-to-be-done aligned SLMs to frontier LLMs; unavoidable LLM calls must be off the hot path and, ideally, asynchronous to callers. WunderOS will intercept Customer Agent calls to LLMs if it can provide (a) provably faster, or (b) pprovably better quality results.
  3. Determinism. Closed-loop subsystems are an axial commitment. An LLM is a plant in the control-theory sense: a source of non-determinism. You do not make a plant deterministic; you put a controller around it. WunderOS is the controller.
  4. Reproducibility. The same query against the same state returns the same result. This is not bolted on. It falls out of determinism: a deterministic system is one whose past you can re-run rather than merely recall.
  5. Audit-grade compliance. Every assertion carries provenance, every classification carries lineage, every plan execution writes back into knowledge. An account of what the system did is therefore available after the fact, and provable, not reconstructed.
  6. Introspectability. Reproducibility, compliance, and audit are one demand seen from three sides. All three require determinism. To replay what happened you must first know what happened, down to which inputs touched which outputs; under audit, you must prove it. A system that cannot inspect itself can do neither.
  7. High concurrency. Latency’s twin, and usually its adversary: improve one and you tend to degrade the other. The scale that matters here is not data but concurrency. How long do agents wait on the substrate, and how many run at once? That is why the runtime sits on the OTP BEAM, the technology beneath WhatsApp and Discord and the telecom industry.
  8. Continuous operation. Agents do not keep office hours. The substrate is built to run without interruption and to be recovered and replayed after a crash without losing what it knew. BEAM OTP’s telecom-grade rigor for the agentic win, including hot code reload.
  9. Temporality. An adequate epistemic infrastructure distinguishes two times: when the system learned a thing is true, and when the thing became true in the world. WunderOS keeps both, so that its resident agents know both. A fact is not merely a fact; it is a fact with a learned history.
  10. Recursive substrate. Every agent action, classifier output, and plan execution writes back to the substrate. Those writes are folds: they compress operational experience into the surface that later cycles read as enriched context. The substrate improves with use, not because the model learns but because its compression of experience does. See PLRN-005 for a definitive treatment.