I build experimental infrastructure for AI agents and AI-operated systems: ways to observe what an agent does, evaluate it reproducibly, preserve the evidence, keep authority outside the model, and verify what happened afterwards.
How do increasingly capable agent systems remain inspectable, evidential and governable, without pretending one mechanism solves everything?
Four projects, one job each.
| Job | Project | What it does | Built with |
|---|---|---|---|
| Observe | Endophasia | A development workbench and research toolkit for coding agents. Hand work to an agent, check what it really did, and keep the evidence: recording, replay, controlled experiments and operator-run verification. | TypeScript · Node.js |
| Evidence and standing | Magpie | Local-first, replayable memory for AI systems: signed history, typed evidence, provenance, and explicit policies for what that evidence is allowed to conclude. | Rust · SQLite · Ed25519 |
| Permission | Deadbolt | A permission engine for AI-operated systems. A proposal stays untrusted until a typed route, a policy, an exact lease and a confirmation authorise its effect. Receipts and rollback. | Rust · MCP |
| Verify | Cogitator | A tamper-evident recorder and verifier for agent runs. Prove what an agent did, tried to do, and was blocked from doing, with deterministic replay and recomputable witness roots. | Rust · BLAKE3 |
Each project stands alone. Together they are a division of responsibility, not a dependency graph: observation is not authority, and a successful evaluation is not permission to replace a running system.
November 2026. Most of my time is in Endophasia, which has grown from a recording instrument into a workbench for development work with agents. Its newest part closes a common gap: an agent says the work is done, the tests exit 0, and the program is still wrong.
$ node calc.mjs '2+3*4'
20 # wrong: it should be 14, and the exit status is still 0
$ endo attempt evidence --attempt <id>
behaviour [plan: expected; observed] expected exit 0 and 3 byte(s) of output;
observed exit 0, 3 byte(s), output different;
first difference at line 1: expected "14", observed "20"
criterion [plan: precedence] 1. 2+3*4 is 14: A planned check failed at HEADReal output, abridged and re-wrapped. The comment on the second line is added.
You say what a correct result looks like before the work starts, run the checks yourself, and read one ledger of what is established and what is not. Try it in five minutes, with no agent and no model.
From Endophasia's live agent studies. Each links to its design, results and limits.
| Finding | Scale |
|---|---|
| Recorded sessions replay exactly when the model's responses are held fixed, and a changed workspace diverges where expected | 40 replays of 4 real sessions, plus a negative control |
| With the environment pinned and sampling fixed, repeated live runs agree on every judged layer; the unpinned control does not | 20 of 20 trials on every task |
| A path that should not matter changes behaviour: the same steering message was followed at 27 of 30 working-directory paths on one task and 6 of 30 on another | 360 trials across 30 paths |
| On two tasks, most failures were a response cut off by a token cap: doubling it raised success from 10/24 to 19/23 | 192 trials, four arms, four paths |
| One request, four different trajectories, the same answer: attribution from agent traces is distributional, not causal | A feasibility probe on a real model |
The useful outcome is not a prettier benchmark number. It is a better experimental instrument: one that can show where sampling, environment, control flow and harness policy actually change what an agent does.
Research directions
Evaluation-driven adaptation. In Endophasia, EVOLVE treats prompts, cognition policies, harness components, tools, memory, models, environments and inference budgets as explicit candidate changes:
observe → propose → isolate → evaluate → compare → admit → promote
- pluggable evaluation, environment, adaptation and optional training providers
- harness and policy search
- test-time compute allocation and stopping policies
- held-out checks and explicit promotion gates
- trajectory-preserving evidence for candidate comparison
RL is one possible adaptation mechanism. Training can produce a candidate; it does not decide what the evidence establishes, nor whether that candidate may replace anything.
Beyond one harness. The ACP v1 vertical slice exercised a real OMP session through the standard protocol. The ACP v2 conformance study pins a Draft v2 baseline and admits no v2 capability from protocol compatibility alone; it is complete and parked until the draft stabilises upstream.
Longer-horizon alignment research. A separate line of work asks whether alignment-relevant epistemic behaviour can be studied as a developmental property, not only as a post-training correction. The design keeps the claim narrow: separate epistemic-content effects from timing effects, use synthetic microworlds with exact gold outcomes, keep Magpie as a shadow evidence, provenance and standing surface and not a truth oracle, and treat null or reversed results as first-class outcomes.
A second question is measurement: whether developmental state can be described more precisely than training step alone. What Do Language Models Learn and When? The Implicit Curriculum Hypothesis and its open ElementalTask tooling provide useful emergence-order and trajectory baselines. I treat those as instrumentation, not as evidence that an early epistemic curriculum is causally better.
Developmental epistemic training v0 is the substrate-side research contract and preregistration draft. developmental-epistemics is the concept-only, longer-horizon repository.
Engineering surface
| Languages | Rust · TypeScript/Node.js · Python · Bash/PowerShell |
| Agents and runtimes | Pi · MCP · ACP · OpenAI-compatible APIs · local agent harnesses |
| Inference | llama.cpp · vLLM · SGLang · TensorRT-LLM · CUDA · GGUF · quantisation · long-context serving |
| Systems | Linux · Arch · Nix · systemd · containers and virtualisation · networking · low-level debugging |
| Delivery | GitHub Actions · reproducible environments · conformance testing · golden fixtures · cargo-dist · release verification |
I use frontier and local models as a structured engineering workforce: architecture-first decomposition, bounded implementation briefs, maker/checker separation, adversarial review and human-controlled promotion.
observation != inference
evidence != standing
proposal != permission
evaluation != promotion
simulation != real execution
These projects are experimental research software. I try to keep claims narrow, make failure states visible, test hostile cases, and document what each system does not establish.
Make capability legible before making it larger.