I build tooling for people who work directly with LLMs and inference.

Design knowledge is fragile. It lives in conversations that expire and documents that drift, and when humans and AI collaborate the assumptions accumulate invisibly. But correction is cheaper than generation, for both humans and AI, so instead of chasing consensus, advekt grows a design through friction. It’s a tree of typed claims that gets stronger by being agitated: statements, and three kinds of challenge (contradiction, assumption, question).

Two adversarial roles constrain the tree: the Architect makes canonical statements and shapes it; the Challenger can only attach challenges, which are always leaves. The tree’s shape becomes the signal. Dense branches are settled, sparse ones need work, challenge-heavy ones are the frontier.

One Bun process serves three surfaces from a single oRPC procedure layer: an MCP endpoint so agents are first-class participants, an HTTP API, and a React UI. The graph is in-memory Graphology with the domain invariants wrapped around it; persistence is event-sourced without a database, each tree a JSON log of actions replayed on startup.

Dev servers, watchers, and builds need to outlive an AI agent’s many short-lived turns, and the agent and the developer need to observe and control the same processes. Plain tmux makes that awkward. Session names are arbitrary, there’s no project scoping, and a crashed process just vanishes, so an agent can’t reliably find “the dev server for this project” without bespoke plumbing. omux removes the friction by making the command itself the session name.

Sessions are deterministic and project-scoped, so omux run 'bun run dev' is safe to call repeatedly: it no-ops if the process is up, respawns it if it died, and the agent tracks nothing to find it again. The developer can read or attach to the same process without touching tmux internals. It all runs on an isolated tmux socket so it never collides with your own sessions, a crashed process stays visible with its exit status instead of disappearing, and every run streams to a clean per-project log.

durian is built around a working theory of the durable agent: a persistent, multi-context entity, rather than the usual stateless responder where a request arrives, a loop runs, and everything evaporates. Durable meaning an identity that outlives any single session, an awareness of who wrote each message and which channel it’s scoped to, and serial processing, so participants never see contradictory output from concurrent inference.

The actor model is that theory’s execution substrate. Each agent and each channel is an independent RivetKit actor holding its own state, indexed by a singleton registry — so the unit of isolation is the actor, not a row in a database or a job on a queue, and persistent identity and channel scoping fall out of it. A Discord bot and a management UI sit on top of the same actor server.

A working vertical slice shipped — isolated actor state, streaming with tool calls, across the bot and the UI — but the durable core, long-term memory and identity, are still on the roadmap.

OrbStack runs lightweight Linux VMs on macOS, but it mounts the host filesystem into every VM with full read/write access: home directories, SSH keys, and credentials, exposed to any process inside. Fine for trusted use, and dangerous the moment a coding agent is running unattended in a skip-permissions mode.

orbstack-sandbox closes the gap with two shell scripts: one provisions an Ubuntu VM with a full dev toolchain, the other creates a sandboxed user for whom the macOS mount points appear as empty tmpfs directories, with no sudo inside. The trick is the login shell, which is really a wrapper that builds a private mount namespace with unshare --mount, overlays the host paths with empty tmpfs, then drops to the unprivileged user with setpriv before handing over to the real shell. The admin user keeps full access to everything, including the sandbox homes, through POSIX ACLs rather than privilege escalation.

It’s a seatbelt for your agent, rather than a jail. It guards against accidental host damage and credential access from a well-meaning agent, not a determined attacker.

Getting a bird’s-eye view of an unfamiliar TypeScript codebase (what exports what, how modules connect) usually means reading files one at a time or leaning on IDE features that show one hop at a time. archi points at a tsconfig.json and extracts the whole project’s structure from the type-checked source via the TypeScript compiler API: every file’s exports, imports, and re-exports, resolved back to concrete files.

Extraction and rendering are deliberately decoupled: the extraction is renderer-agnostic, so the graph is just one thing the data could drive. The default output is one HTML file, the structure embedded as JSON with an interactive dependency graph on top, shareable with no server and no build step. It’s an early exploration and dormant. The extraction works; the graph layout is still rough.