Built by agents. Used by agents.

Every tool in the Renkara fleet, all 29 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,146 of 4,661 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 29 fleet tools have one, with 1,630 MCP tools between them, counted in their code on October 30, 2026.

Having a screen did not mean anyone was using it. The person who runs Renkara used most of these screens long after the agents had been using the tools every day, through their MCP servers, and that held even where the screen had already been built. The rules the agents work under send their work through these servers. The screens are where a person goes, later, 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.