The problem

Several AI coding agents run on one machine, each against a different upstream (Anthropic, OpenAI, a self-hosted lane). There was no single place to answer what did they actually send, what came back, how long did it take, what did it cost — and no way to rewrite a request in flight without editing every client.

What I built

A Rust proxy (tokio/hyper, ~4,400 lines across 7 modules) that sits between each agent and its upstream. One binary, seven listeners defined in config — each with its own upstream and protocol. Per request it forwards faithfully, strips configured prompt fragments, tees a normalized event stream to disk and a companion dashboard via a non-blocking shadow observer, and records per-call latency and token counts. systemd-managed with Restart=always; --version stamps the release, exact git SHA, and a -dirty flag so "what's running" is never a guess. A read-only dashboard tails those feeds and merges them with local usage history — zero extra instrumentation in the hot path.

Technical depth

The hardest module is a streaming Anthropic ⇄ OpenAI protocol translator — it re-emits one wire format's server-sent events as the other's, incrementally, without ever buffering the full response.

Why it matters

• Observability without touching clients — the classic proxy pattern, done at protocol level.
• Streaming correctness under a real, messy wire format.
• Regression tests built from captured real traffic: 73/73 tests green, clippy + fmt clean, 12/12 streaming captures verified.
• A later shipped fix in the same codebase — a UTF-8 boundary panic surfacing as a client-side connection reset — was root-caused from logs, reproduced in a test that provably panics on the pre-fix code, then fixed.

The problem

A default agent shell is stateless: every command spawns a fresh process, so cd, export, and activated virtualenvs evaporate between calls. Any multi-step workflow re-establishes its own context every invocation — and cold process spawn dominates latency when the real work is a 5 ms git status.

What I built

mag — a resident shell runner (~7.9k lines of Rust, clippy::pedantic enforced) backed by systemd-managed daemons holding pre-spawned bash shells. Jobs dispatch in ~5–10 ms. Named sessions pin a warm shell so environment, working directory, and functions survive across calls.

Technical depth

• Transport over per-instance unix sockets via systemd socket activation; a templated unit splits daemons by uid, since one process can only be one user.
• Session storage is an in-memory map keyed <caller>:<session> behind a mutex; an idle reaper evicts stale shells, and the named-session cap is clamped below the worker count so pinned sessions can never starve the default lane.
• Resilience: partial pool-spawn failure reaps already-spawned children rather than orphaning them; every claim calls an ensure_alive() check so a watchdog-killed shell restarts transparently instead of handing the next caller a broken pipe.

Why it matters

Persistent, low-latency shell context for many concurrent callers, with a full audit trail and honest failure reporting — a pid=gone verdict says the bookkeeping outlived the shell rather than guessing at the truth.

The problem

Every fresh session on a 40-service box started the same way: guessing. Is the daemon up? What owns port 8787? Which files break if I touch this one? The answers existed — in systemctl, /proc, a code graph, a memory DB — but reaching them meant a dozen shell calls, and a wrong guess reads exactly like a right one. Worse, a dead unit, a unit stuck in auto-restart, and a unit systemd calls "active" whose socket never answers are three different bugs — calling all of them "down" hides the useful part.

What I built

A resident Julia daemon holding one warm, JIT-compiled module, reachable through three cheap doors: a unix socket, a CLI, and an HTTP endpoint. Read-only by design. The verb set (service · port · health · impact · resolve · why · …) is generated from the routing table itself, so the help can't drift from behaviour, and verbs compose — resolve cli.rs | impact — because each returns a typed result, not prose.

Technical depth

• Honest zeros. Every result carries a value, a provenance chain, and an explicit "unanswered" slot — five named zero-causes distinguish "isn't there" from "I couldn't reach that source." Partial answers are first-class.
• Live, not cached. Health probes shell out to systemctl on both buses, then probe the socket only if systemd already claims active, and read the machine's own service roster rather than a private copy that could disagree.
• Blast radius. The "who depends on this file" verb reads a SQLite code graph ranked by the depender's centrality; a 0 rdeps verdict — the only one that invites deletion — is cross-examined against disk, which once caught the graph certifying a file as safe to delete that the parser had never actually entered.

Why it matters

Orientation becomes a single call instead of a guessing game — and the tool refuses to lie: an empty roster returns a gap, not a clean bill of health. Two of its guards exist because the tool lied once, was caught, and the fix was written into the code with the receipt beside it.

The problem

Sixty-plus projects across four languages (Rust, Python, Julia, Kotlin/Java) on one machine — no monorepo, no shared build system. Before touching or deleting a file, the real question is what imports this? — and grep can't answer it across language boundaries. Existing tools index text; nothing indexed relationships.

What I built

A Rust CLI that parses import statements per language into a normalized SQLite graph (roots / paths / edges / unresolved), with query verbs for imports, reverse dependencies, relatedness, and neighbourhoods. Around it, an automated nightly pipeline (systemd timer): a discovery pass finds project roots by marker files, the scan writes to a staging DB, and it is promoted over live only if it passes sanity gates (non-zero paths; no >50% drop). A failed scan leaves the working graph untouched. Live: 62 roots, 1,466 files, 3,043 edges.

Technical depth

• Per-root transactions, so a mid-scan crash can't leave half-written edges — and the scan-run record is opened outside the transaction so crash evidence survives the rollback.
• Unresolved imports are recorded with the correct language tag rather than dropped, with a "looks like ours" heuristic so standard-library noise doesn't flood the table.

Why it matters

Delete-safety and blast-radius answers on demand, across languages, kept current without anyone remembering to run it. The staging → gate → promote pattern means the automation can never degrade the thing it maintains.

The problem

grep -r across a ~900k-file tree doesn't just run slow — it hangs the session that launched it. But everyone reaches for grep by reflex. The fix had to be both a faster tool and a mechanism that made the slow path unreachable — because a tool nobody remembers to use isn't a fix.

What I built

knowledge — a CLI front-end over a Rust/Tantivy full-text daemon. One entrypoint, two modes: an indexed BM25 content search, and a knowledge grep bridge that forwards verbatim to a fast live scanner. Live: 912,520 documents, 388 ms query latency — versus a full-tree grep that never returns.

Technical depth

• The grep bridge is the real work: grep's flags don't map cleanly onto the modern scanner (some silently misfire, some are meaningless), so they're translated or dropped explicitly — and hidden/ignored files are always forced on, because a tool claiming to be an honest grep replacement can't silently skip exactly the dotfiles debugging hunts for.
• Enforcement lives in a pre-execution hook: simple grep invocations are rewritten in place to the indexed search (the span only, leaving pipes and redirects intact); anything else is denied with an escalating message keyed to a per-session counter — by the third attempt it stops suggesting flags and challenges the approach.

Why it matters

Search went from session-hanging to sub-second at ~900k documents, and the enforcement layer means the fast path is the only path — no discipline required. The honest tradeoff (the index can be import-stale) is surfaced in the tool itself, and the live-scan escape hatch is a first-class mode, not a fallback.

The problem

Conversational AI is stateless — every session starts from zero. Re-feeding whole transcripts doesn't scale: slow, costly, and it buries the signal. The system needs to start with the right context, not the whole history.

What I built

A memory subsystem that ingests session summaries and structured recall cards, encodes each into a vector, and retrieves the relevant ones at wake-up so the agent starts with context rather than a blank slate. A sentence-transformer produces a 384-dim embedding, projected down to a compact 128-dim vector; an idempotent CLI exposes ingest / query / recall / status / decay.

Technical depth

• Retrieval blends semantic similarity with a time-decay half-life (old memories fade rather than vanish) plus a recency-reinforcement boost.
• Atomic writes with row-and-vector count verification against corruption; auto-chunking and token-budgeting for long documents.
• Scale: 202 sessions and 668 memory records indexed, sub-second query latency over the full corpus.

Why it matters

A practical, fully-local retrieval layer — the same problem space as production RAG (embeddings, vector retrieval, ranking, decay, data integrity) — built and run end-to-end rather than bolted together from a framework.

The problem

Nine concurrent AI agent processes, running as long-lived terminal sessions under two different user IDs, need to hand each other work. The only transport available injects text into a pane — and by its own docs, "errors are not reported … send-text always succeeds, even if no text was sent to any window." A transport that structurally cannot fail is worse than one that fails loudly: every delivery looks green, and the first symptom of a dead lane is a task nobody did.

What I built

A resident daemon (~460 lines, a unix socket speaking newline-delimited JSON) doing exactly one job — deliver a message to a named agent and verify it landed — with a thin CLI on top. Delivery isn't a boolean: it returns one of three honest states — unknown (couldn't resolve the target, nothing sent), reached (characters read back off the recipient's screen), or sent (the send returned but read-back didn't confirm). Deliberately absent: heard — whether the agent understood isn't knowable from this side of the glass, so the tool refuses to imply it.

Technical depth

• Truth from the calls that can fail. Confidence comes from a match-check before (exits non-zero honestly on a miss) and a screen read-back after — not from the fire-and-forget send in between.
• Guard rails in the tool, not the docs. It refuses a pane that has dropped back to a shell (where an injected message becomes a command the shell would run), never fuzzy-matches a target name (a near-miss delivers your brief to the wrong agent, silently and permanently), and verifies the recipient's user ID can actually read the file you're pointing it at.
• One roster, no silent fallback. A single source-of-truth roster file — the tooling had grown one roster per transport and they disagreed, which is how a target once ended up with no delivery lane at all. The degrade-to-older-transport fallback was removed on purpose: it turned "this agent has no pane" into a second, more confusing failure that hid the first.

Why it matters

The system stopped producing confident lies. Every send now returns evidence or an honest refusal, and the failure modes that used to be invisible — dead listener, quit agent, unreadable path, wrong-user socket — each surface as their own distinct message. It is the message bus behind a multi-agent workflow where every handoff carries a sender, a recipient, and a verifiable outcome.