Ken's Agent Editor — an editor whose only user is an AI agent.
kaed is a Rust daemon that exposes reading, searching, and editing files as an HTTP MCP server: versioned reads, atomic multi-file edit transactions, structured conflicts instead of silent corruption, and a durable attributed journal. It exists first for remote editing — an agent on one machine editing files on another, where ssh-piping and network mounts fail in quiet, expensive ways — with a long-shot second act as a local power tool.
There is no human UI, and there is not going to be one. Every design decision optimizes for the agent as the sole user: no cursor, no viewport, no undo stack — but every response carries the exact information an agent needs to act on it without a verification round-trip.
kaed is a network service that writes to your filesystem, gated by a bearer token. It is at an early beta level of maturity:
- It is dogfooded daily by its author, on a handful of machines on a private network. It has been run by essentially nobody else, and it has not been audited.
- Expect breaking changes — to the config format, the MCP tool contract, and the on-disk journal schema. Version numbers track sprints, not a stable API.
- Do not expose it to an untrusted network. It binds loopback and expects to sit behind something that handles transport security and access control (the reference deployment uses
tailscale serve).- Its safety features are blast-radius reduction, not an access-control boundary. Any agent with a shell can read what kaed refuses to serve. Read SECURITY.md before deploying it anywhere you care about — it says plainly what kaed does and does not defend against.
If you run this and it eats something you needed, that is a risk you took.
Six tools over streamable HTTP with per-agent bearer auth:
| tool | what it does |
|---|---|
roots |
list the configured workspace roots |
stat |
metadata + content version — the cheap staleness probe |
list |
directory entries, gitignore-aware, paginated |
read |
whole file, a line range, or a window around a line or unique anchor |
search |
ripgrep-grade, every hit carrying its file's version |
edit |
anchor/range replace + create; multi-file, atomic, dry_run |
The bet underneath them is verified writes:
- Every response carrying file content also carries a
version— the BLAKE3 hash of the bytes served. - Every mutation declares the version of each file it touches. If the file
moved on, you get a structured
version_conflictcarrying a diff of what changed since you looked — never a wrong edit. - The response to a successful edit contains the unified diff that was applied. That diff is the proof. No verification read.
A version is a content address, not a session handle, so it never expires: an agent resuming after a crash or a context compaction can edit straight from a version it recorded an hour ago and either succeed or get a precise conflict.
Every applied transaction — and every failed attempt — is journaled with the
identity that made it and an optional intent note.
Deliberately absent: no exec/shell tool, and no git tool. An agent that can already run commands does not need kaed to run them, and keeping them out is what lets the security story be stated in one paragraph. See docs/overview.md for the reasoning.
- docs/overview.md — why kaed exists, how it works, what is deliberately excluded, where it's going.
- docs/setup.md — deploying it yourself: build, config, token, systemd unit, remote access, client wiring, rotation. Includes a section you can hand to your own agent to do the install.
- deploy/ — the install itself: an idempotent
install.sh(re-running it is the upgrade path), the systemd unit, a config template, and token mint/rotate. It never overwrites a config and never touches a token. - docs/kaed-explained.html — a single-page visual explainer (rendered preview). Self-contained; it renders offline straight from a checkout too.
- SECURITY.md — threat model, stated honestly.
- sprints/ — the development history: planning docs, the MCP contract, and one record per sprint.
Worth stating up front, because it explains the shape of everything else in this repo.
Ken and an AI agent have a design conversation — sometimes long, sometimes adversarial — until the shape of the work is clear. Then Ken hands implementation over. The agent makes the design and implementation calls, writes the code and the tests, deploys it, verifies it against the live service, and writes the sprint record explaining what it decided and why. Ken advises and reviews; he is not the one typing.
So:
- The sprint records are primary sources, not summaries written after the
fact.
sprints/NNN-name/holds the reasoning as it happened, including options that were rejected and the occasional place where the plan turned out to be wrong.decisions.mdfiles exist where a call was genuinely contested. - Commits are co-authored by the model that wrote them.
- The docs are written for an agent as much as for you. The MCP tool descriptions and the server instructions are part of the product, and get reviewed as carefully as the code.
This is an experiment in giving an agent real ownership of a tool that agents themselves use. The thing being built and the way it's being built are the same bet.
Uses the kproject minimal harness.
just # list recipes
just check # CI gates: fmt --check, clippy -D warnings, tests
cargo run -- check-config # validate config, print roots + deny rules
cargo run -- serve # run the daemonkaed lives alongside the other homelab MCP services it was built next to (klams for memory, korg for work items): same transport conventions, same per-agent bearer-token auth.
MIT — see LICENSE.