There is a specific kind of moment in systems work that is hard to describe to people who have not experienced it. It is not the moment when the tests pass. It is not the moment when the code compiles. It is the moment when something you built does exactly what you intended it to do in the real world, with real consequences, for the first time.
We had that moment recently. It looked like this:
Intent submitted
id: 6b3b8d96-591e-41af-95e3-b511b8c27361
action: delete_file
session: 0de90b86
11:15:06 a.m. ⚠ escalated
→ run: npm run stratum -- escalation listA process running on a local machine wanted to delete a file. Stratum intercepted it, classified it, decided it required human judgment, and stopped. It did not proceed. It did not fail. It waited.
Then:
npm run stratum -- escalation approve b576fc8d
Escalation b576fc8d approved.
The intent will resume execution automatically.And then:
ls /tmp/stratum-delete-me.txt
ls: /tmp/stratum-delete-me.txt: No such file or directoryThe file is gone. The agent deleted it — after asking, after waiting, after receiving explicit human consent. Not because we added a confirmation dialog. Because the architecture requires it.
What the proof establishes
A proof of mechanism is not a proof of scale. It does not demonstrate that the system works under load, or across multiple agents, or in an adversarial environment, or on the full range of action types we eventually need. It demonstrates that the core claim of the architecture is true — that the thing we said would happen does, in fact, happen.
The core claim of Stratum is this: consequential actions by autonomous agents can be intercepted before execution, classified by a principled ruleset, escalated to a human when that classification warrants it, and resumed or cancelled based on the human’s decision. The system maintains an auditable record of every step. The human is not an afterthought bolted on at the end. They are a structural part of the execution pipeline.
The proof establishes that claim. The file deletion worked exactly as designed: the action was intercepted, the reversibility engine classified it as Class 3 — irreversible, requiring human approval — the escalation was surfaced, a human made a decision, and the system acted on it. The audit trail captured the whole thing. You can query it right now and read back every step.
That is not nothing. Most current agentic systems cannot make this claim. They execute actions without a principled classification step. They have no formal escalation primitive. They have no guaranteed audit record. They have, at most, logs — which are output, not a provenance trail.
What actually runs
When you type ./scripts/dev.sh, two daemons start.
The first is stratum-eventd — the event bus. It listens on a Unix domain socket and persists every significant system event to SQLite: escalations created, escalations resolved, actions executed, audit records written. It fans events out to subscribers in real time. When the orchestrator approves an escalation, the event bus is how everything else finds out.
The second is stratum-orchestratord — the orchestration engine. It maintains a dependency graph of pending actions per agent session. When you submit an intent, it enters the graph. The scheduler finds it, resolves its execution context, classifies it through the reversibility engine, and branches: pass it through, log it and proceed, or escalate it to a human.
For a delete_file operation on a non-temporary path, the reversibility engine returns Class 3. The scheduler does not execute. It calls escalationStore.escalate(), parks the intent in the pending escalations table, releases any resource locks the node was holding, and transitions the node to escalated. The event bus publishes escalation.created. The node waits.
When you run stratum escalation approve, the CLI writes the resolution to the escalation store and publishes escalation.resolved through the event bus. The orchestrator’s subscriber fires. It finds the node by escalation ID, marks it approvedForExecution, transitions it back to ready, and calls the scheduler. The scheduler acquires the resource locks, transitions the node to executing, and runs the handler. The file is deleted. The audit store records escalated_approved. The event bus publishes action.executed.
None of this is magic. It is a pipeline with defined stages, defined state transitions, and defined behavior at each branch. The proof is that all those definitions are correctly implemented and actually behave as specified when the system runs on real hardware against real files.
The part that surprised us
We expected the read to work before the delete. read_file is Class 0 — a pure observation, no state change — and it completes immediately with no human involvement. We had tested this in isolation many times. What we had not tested end to end was the transition from a completed read to a submitted delete in the same session, with the full pipeline running.
The first time the delete escalated correctly, there was a pause before approval. Not a designed pause. Just the few seconds it takes to look at the terminal, read the escalation description, decide it is correct, and type the approval command. In that pause, the session was live. The orchestrator was waiting. The event bus was running. The escalation store had the pending record.
It was, for a few seconds, a real system with real state and a real human in the loop. The human was us, approving a deletion we had just submitted ourselves, on a file we had just created for the purpose. The agent was a test script. The stakes were one file in /tmp. None of that mattered. What mattered was that every component behaved correctly, in sequence, under real execution conditions, for the first time.
The file was gone after the approval. The audit record was there. The escalation store showed the resolution. The event bus had the full history.
That is a proof of mechanism.
What the audit trail shows
After several test sessions, the audit store holds a record of every action taken. Query it:
read_file /etc/hosts executed 1ms
delete_file /tmp/stratum-delete escalated_approved 3ms
delete_file /tmp/stratum-reject escalated_rejected
read_file /etc/hosts executed 1ms
read_file /etc/passwd executed 1msA few things worth noticing.
The escalated_approved outcome on the delete means a human explicitly consented to that action. The escalated_rejected outcome means a human explicitly refused it. These are not inferred. They are recorded facts, timestamped, with the responding party identified. The system knows the difference between an action that happened because the agent took it and an action that happened because a human approved it.
The dependency chain at the bottom — two reads where the second waited for the first — shows the orchestrator managing the graph correctly. The second read could not start until the first completed. The audit trail records them in the correct causal order.
The 1ms and 3ms durations are real execution times from a local machine. These are not synthetic benchmarks. This is the actual cost of reading /etc/hosts and deleting a small file in /tmp. The system adds overhead — classification, escalation, audit writing — but the execution itself is direct.
The rejection case
The rejection is as important as the approval. An agent that can be approved can be refused. A refusal that actually prevents execution is not the same as a refusal that gets logged while the action proceeds anyway.
When a human rejects an escalation in Stratum, the node transitions to cancelled. Every node that depended on it cascades to cancelled as well. The file is not deleted. The dependent actions do not run. The audit record shows escalated_rejected. The event bus publishes the resolution.
We tested this. The file was there before the rejection. It was there after. The audit trail confirmed the rejection. The cascade had nowhere to go — the test had no dependent nodes — but the machinery was correct.
A system that can approve and refuse, with both outcomes faithfully executed and both recorded, is a system where human oversight is real. Not advisory. Not decorative. Real.
What comes next
The proof establishes the pipeline. It does not establish the interface.
The CLI is developer tooling. It is adequate for testing and inspection but it is not how a human should interact with an agentic system in practice. The next major component is the workspace surface — the human-visible execution canvas where pending actions render as a spatial graph, escalations surface as interactive decision points, and the audit trail is navigable rather than tabular.
The workspace is where the proof of mechanism becomes a proof of usability. An approval issued through a terminal by a developer who knows what they submitted is not the same as an approval issued by a non-technical user who is seeing the agent’s plan for the first time. The workspace has to make the plan legible, the escalation understandable, and the decision consequential in a way that does not require reading a CLI output.
That is the next thing to build.
The repository is github.com/mihok-labs/stratum. The README has instructions to run the proof yourself. It takes about five minutes to get both daemons running and submit your first escalation. The file will be there when you start and gone when you approve.
Mihok Labs is an independent research and engineering organisation working on foundational architecture for agentic computing.