Since October 21, an AI agent has always been in charge of our open-source libraries. Day and night, weekends too. That’s about two weeks now.
It isn’t one agent that never stopped. It works more like shift changes: when one agent’s shift ends, it leaves a note, and the next one reads it and carries on.
So “non-stop” means the work is never left without someone in charge. It doesn’t mean every agent is busy every minute. Sometimes a job is waiting on CI, or on Kurtis. But something is always watching, so a problem at 3 a.m. gets noticed at 3 a.m.
It all runs on Alera, the engine we build on. But most of what made it work is plain team structure.
Who does what
There are three layers.
- A project manager agent decides what to build next, answers the hard questions, and approves releases. One manager runs most of our libraries. A second runs the game engine and its audio and shader libraries.
- An orchestrator agent for each library splits the work into small units and hands them out.
- Builder agents each take one unit and report back.
The website has its own team.
Kurtis is the one human. The managers bring him only what is genuinely his: product direction, money, accounts, and real blockers.
Every agent has exactly one principal, and writes down who that is.
Changing shifts
An agent’s context window (how much it can hold in mind) is limited, and agents get slower and sloppier as it fills. So we don’t wait for that.
- A monitor fires when an agent’s context passes a set size.
- The agent writes a handoff note: where things stand, who is working on what, what’s next, and what’s still open. The note lives in a file in the project, not in the conversation.
- The agent starts its own successor, points it at the note, and stops.
The successor reads the note first, then tells each child agent it is their principal now, so nobody reports to an agent that has stopped.
A manager’s shift lasts from a couple of hours to about a day. Most of the time nobody notices the change. That’s the point.
Three monitors
Every agent that starts another one watches it with three monitors:
- Context: the child is getting full, so tell it to hand off.
- Finished: collect the result. If the child handed off, start watching its successor.
- Elapsed time: usually about two hours. When it fires, look at what the child is doing, but don’t kill it. Usually it’s just busy. Sometimes it’s stuck.
Write down who decided
Agents answer each other’s questions all day. Soon it’s hard to tell which decisions were Kurtis’s. So every decision gets a label: the owner’s, or an agent default.
An agent default is a proposal. Any agent can revisit it on evidence. The owner’s decisions stand. Once, a library team followed a rule it believed was his. It turned out an earlier manager had set it, just to be careful. When Kurtis said otherwise, we fixed the label and followed him.
And Kurtis’s latest word always beats older notes.
Don’t ask for the same yes twice
Every approval request slows things down. So routine work gets a standing go. When one of our libraries ships a new version, the website team updates the site right away and reports afterward. It asks first only when the release raises a question about wording, security or scope.
Check, don’t just trust
Agents sound confident. When a builder says “done”, that’s a claim, and the manager checks the ones that matter. Before a release it reads the CI results itself. Afterward it looks the packages up on NuGet itself.
Sharing the machines
Agents share hardware, and they aren’t always tidy about it.
- Only two of the main manager’s libraries build at a time. Kurtis set that limit to keep costs down. The rest wait their turn.
- Disks fill up. More than once, all the way. Now the manager checks disk space every time its timer fires, with a list of what is safe to delete.
- Builds spoil benchmarks. Our libraries publish speed comparisons, and those need a quiet machine. Agents kept starting builds in the middle of benchmark runs. Kurtis asked for a job queue, and an agent built it that same afternoon.
- Agents clean up too much. One cleanup wiped other teams’ job records. Another killed other teams’ builds. Now each agent may only delete or stop its own things.
The website team tries everything
This is the part we’d recommend most. When a library ships a release, the website team updates the docs, runs every sample, and tries the new features for real. Anything that doesn’t match the docs goes back to that library’s team. Two finds from this week:
OneLite, our database library, added BEGIN CONCURRENT, so several writers can run their transactions at the same time instead of waiting for each other. That was meant to be opt-in. The website team found the happy-path defaults had switched it on, so new rowids could commit out of order and a poller reading new rows by rowid could miss some. The OneLite team switched it back off the same night.
OneMedia, our video library, has a strip command that removes location and device data. OneMedia’s own tests and docs show that on one camera, the DJI Osmo Pocket 3, strip leaves the location and the serial number in. The website team ran strip on that camera’s footage and got back an unchanged file. It also found guides that still mentioned only the serial number, and the OneMedia team fixed them. Strip still doesn’t clean that camera’s files, so the site warns about it right next to the strip docs.
It works because the website team takes the docs literally.
What goes wrong
Agents add process. Each new check or step sounds responsible. Together they made one library’s benchmarks take five hours or more, until Kurtis asked why. The manager cut them back. Now every agent is told that a step has to earn its place.
Agents escalate what they could do themselves. When a builder says a job needs Kurtis, the manager treats that like “done”: a claim to check. Often the agent can do it.
Docs drift. Library docs drifted from what the code did, and the website team caught it. Our own handoff note keeps getting longer, because every agent adds to it and few trim it. So far it has only grown, and it uses up a big part of the next agent’s context before it starts. Trimming it is on our list.
We released too often. Kurtis wants releases on NuGet only at milestones, like the first public version or 1.0. In the past few days we slipped: each website find led to another small release. So he said it again, more firmly. Now fixes wait for the next milestone. If a serious bug turns up in the meantime (data loss, security or privacy), we unlist the broken version and add a note to the README. Only a library nobody is actively working on gets a patch release. The OneLite fix shipped just before this rule.
If you want to try this
- Put one agent in charge, and give every agent one principal.
- Keep state in files, not in conversations, and keep it short.
- Hand off before the context window fills. Let the outgoing agent start its own successor.
- Put a time check on every child agent. When it fires, look before you kill anything.
- Write down who made each decision. The owner’s latest word wins.
- Have a second team really use what the first team ships, and send back what breaks.
What the library teams have made is on our libraries page: twenty open-source libraries so far, with docs and samples the website team has run. If you try something like this and it goes differently for you, we’d like to hear about it at [email protected].