Agents Get Names, and We Stop Doing Something Dumb

Four Features, One Saturday

Some days you build one thing well. Other days you build four things, fix a dozen bugs, and forget to eat lunch. This was the second kind of day.

Agents Sign Their Work

Here's something that seems obvious in hindsight but took us a while to fix.

Every AI agent working on oUTPOSt makes commits to the codebase — that's how their work gets saved. But until today, every commit from every agent looked identical in the git log. Same name, same email. It was like having five carpenters in a workshop, and every piece of furniture just says "Made by: A Carpenter."

Not super helpful when something breaks and you need to know who cut that board.

Now each agent gets its own identity. The git log becomes a readable story:

a1727ca  Kimi (oUTPOSt Agent)    Fix review feedback: guard --dry-run
367a42a  Claude (oUTPOSt Agent)  Add CHANGELOG.md

When the automated review pipeline approves and merges someone's work, the merge commit now says who reviewed it, what they thought of it, and a summary of their findings. Every merge tells a small story.

Tracking What Actually Changed

Related upgrade: we added git activity tracking. Before a task starts, the system takes a snapshot of the repository. When the task finishes, it diffs the two states and records exactly what happened — which files changed, how many lines were added or removed, which commits were made.

This turns task history from "an agent worked on something" into "this agent added 47 lines across 3 files in 2 commits, here are the GitHub links."

It's the difference between a delivery note that says "stuff" and one that lists every item in the box.

We Stop Asking the Server to Do Homework

OK, confession time.

Our frontend uses Tailwind CSS, which is a tool that generates the visual styling for the admin interface. The way it works is: a program called Vite scans every file in the project, finds all the style names we've used, and builds one optimized CSS file.

On a modern laptop, this takes about eight seconds. No big deal.

On our server? Four minutes. Sometimes longer. Sometimes the server's operating system just killed the process for using too much memory — Tailwind v4 happily consumes 3-4 GB of RAM while scanning, and our server had better things to do with that memory. Like, you know, running the actual application.

For months, every single deploy included this four-minute build step. We'd push code, then wait. And wait. And watch a timer. And wonder if this was the deploy where it would crash again.

The fix, when we finally got around to it, was almost embarrassingly simple: just build it on the development machine (where it takes eight seconds because laptops are fast), save the result, and ship the pre-built files to the server. The server never needs to build anything — it just receives the finished product.

Think of it like this: Instead of shipping raw lumber to a client and asking them to build their own table, we now ship the finished table. The client's living room doesn't need a workshop in it.

Deploy went from "five anxious minutes" to "42 boring seconds." Which is exactly what deploys should be: boring.

{
  "type": "bar",
  "title": "Deploy Duration (seconds)",
  "labels": ["Before: Server Builds Everything", "After: Ship the Finished Product"],
  "datasets": [
    { "label": "Seconds", "data": [300, 42] }
  ]
}

We'll take boring.

The Polite Maintenance Page

Previously, deploying meant users would see broken pages or cryptic error messages for a few seconds while the server updated itself. Not a great look.

Now there's a proper waiting room. When a deploy starts, the web server intercepts all incoming traffic and shows a clean status page — which step is running, a progress bar, how long it's been going. No complex backend needed, just a simple page checking a status file.

When the deploy finishes, the page redirects you back automatically. If you were already on the site, you get a live notification that the update is done.

The details were fiddly (they always are), but the result is nice: deploys went from "mysterious downtime" to "polite 42-second intermission."

Agent Workspaces

One more thing: you can now browse each agent's workspace in the code editor — their instructions, personality settings, recent activity. It's the beginning of treating agent behavior as something you configure through editable files rather than buried code.

Think of it as each agent getting their own toolbox with a label on it, instead of everyone rummaging through the same drawer.

Four tasks. Twelve bug fixes. One very boring deploy pipeline. Progress.