Built by agents. Used by agents.
How agents built Roost, how they use it every day, and why every Renkara fleet tool gets an interface for software as well as one for people.

Software with two kinds of users
Every tool in the Renkara fleet, all 28 of them, was written by AI coding agents, working from short written briefs, with one person deciding what gets built and what ships. That is not a figure of speech. Across their repositories, 4,117 of 4,632 commits, 88 percent, name an AI agent as a co-author in the commit message, and that counts only the commits that say so.
Agents writing code is becoming ordinary. The less ordinary part is who uses the tools once they exist. A lot of the time, it is an agent too.
An interface for agents
Software usually starts with screens, because a person is the user. An agent has no use for a screen. It wants a short list of things it can do, typed inputs, and errors that say what went wrong. That is what an MCP server is: a tool's actions published through the Model Context Protocol, so any agent can call them. 26 of the 28 fleet tools have one, with 1,629 MCP tools between them, counted in their code on October 30, 2026.
Which came first, the MCP server or the screen, depends on the tool, and the git history says so plainly. In 3 tools the MCP server was committed before the user interface. In 10, both arrived in the same commit, or history begins with an import that already held both. In 13, the screen came first, and in 8 of those the MCP server followed within a week. The order matters less than what happens after: the rules the agents work under send their work through these servers, and the screens are where a person goes to check it.
What the agents actually do
On an ordinary day, agents file and close cards in Docket, record decisions in Gavel, post status to Chirp, publish documents to Lectern, and make every change to the cloud through Foundry. They do it through the same tools these sites describe, not through a browser. They reach those MCP servers through one local gateway, Roost, which had 31 servers registered on October 30, 2026, so an agent started anywhere finds all of them in one place.
Some tools are mostly for the machines
A few tools exist mainly so agents can ask them things: Assay, Cortex, Lattice, and Roost. Roost has no user interface at all. The others have screens a person can use, but agents are who they were built for, and each of their sites says how.
What a person still does
Agents are fast, and they are wrong in confident ways, so the work is arranged to catch them. One agent writes and a different one reviews. Tests run before every commit, and every fixed defect gets a test that fails if the defect comes back. A person decides what gets built and what ships, and anything that spends real money or cannot be undone waits for that person. The agents keep the records that make that oversight possible: the card, the decision, the commit, the status post.
Why tell you this
These sites describe tools a small company built for itself, and most of them are not for sale. The idea worth taking from them is not any one tool. It is a habit: give software an interface an agent can use, not just one a person can, and the screen becomes a window onto work that is already happening.
How agents use Roost
Roost is the hub every agent session reaches the fleet's MCP servers through. It has no screen and no tools of its own. Agents never talk to it directly; they just find that every other tool is there, and they run its command line when they change a server.
- User interface
- None
- One local daemon, one path per server
- Each MCP server is served at its own path on a single local daemon over Streamable HTTP. A session holds a plain URL entry instead of a command to spawn, and the
mcp__<server>__*tool names stay the same. - Shared, started when needed
- Roost keeps at most one child process per server, starts it on first use, shares it across sessions, and stops it after idle time. It answers the tool list from a saved snapshot without waking anything.
- Agents keep it in sync
- After changing a server, the agent runs
roostctl refresh <server>. If the code changed, Roost restarts the running child.roostctl verifycompares each server's own tool list with what Roost serves, androostctl doctorchecks the daemon. - Why it exists
- Measured on July 28, 2026, four sessions each running their own copy of 22 servers meant 92 processes and 5.85 GB of memory. One daemon and a handful of children replaced that.
roostctl revertrestores direct spawning if Roost is ever down.