Agent server
A mini PC and a private network that run many coding agents at once.
private networkone agent turn, in its own process and its own copy of the repo
Many coding agents, one phone, my own computers. From my phone I start work, watch agents, answer their questions and catch up, on any of my machines. Work keeps going through restarts, crashes and usage limits, and no laptop has to stay open.
I give a goal. A lead agent plans and starts helpers. I come back to a summary and a short list of decisions that wait on me.
How it came to be
first methodsecond method
The first method: I turn my own coding-agent setup into a system.
The first method at full speed: a lead agent talks to me, and background builders each work on one slice in their own copy of the repo.
A friend's multi-agent system, a different kind of design, appears beside it. For about a week I run both.
The switch. I adapt the friend's system to my own computers and keep it in step with their version.
An always-on mini PC takes over the shared role from the laptop, and the laptop becomes a second worker.
The first method
The first method is my own. It made one agent tool behave like a small team, from inside that tool. Rules and helper scripts sat around the agent, and a project moved from an idea to docs, from docs to a plan, and from a plan to small slices that agents built one by one.
Every session started with a short rundown of the project's stage, the state of the code and the next step, so a fresh session needed no memory of the last one.
- One lead agent per project talked to me and wrote the plans. A guard kept it from editing code.
- The lead started a builder per ready slice. Each had its own branch and working copy, and merged its own work once the checks passed.
- Plain code, not a model, made the routine calls: which slice was ready, when to start the next one, when to tell me.
- A loop recorded friction, like failed commands and retries. An agent planned a fix for the worst issue, and a fix stayed only if it helped.
What it showed: parallel builders were really faster, at about the same tokens per slice. A branch per agent kept the main line working at that speed. And every rule was tested with and without its extra lines, graded blind, and cut if it did not help.
The second method
Two limits made me switch, and one step removed both. The first method ran one coding-agent harness per repository, so every project needed its own setup, and I moved between accounts by hand. The second method runs everything from one always-on mini PC, on a private network that reaches all my machines and accounts. It also starts and owns the agents itself, so it knows each one's state.
| First method | Second method |
|---|---|
| inside one agent tool, as add-ons | a server that starts and owns every agent |
| one laptop | all my machines, around an always-on mini PC |
| one harness per repository | one box for every repository |
| accounts switched by hand | every account, and a session at its limit moves to one with room |
| driven at the keyboard | driven from my phone, with push notices and approval cards |
| each agent's state read from the outside | each agent's state known, because the server runs each turn |
The second method is a friend's system. I adapted it to my own computers, and I keep it in step with their version. My part is the adaptation: my computers, my rules, my choices on access and identity, and the move of the shared role to an always-on box. The ideas came with me, not the code: an agent per branch, a lead that waits for my go before anything writes code, plain code for routine calls, small plans in slices.
What it does every day
Work survives a server restart, a crash, a dropped network or a usage limit, and carries on by itself.
Most of this comes built into the friend's design. I run it every day, on my machines and under my rules.
- Restarts
- Each agent turn runs in its own process, apart from the server. A restarted server finds the live turns again, and a turn that was cut off carries on with a note that says so.
- Usage limits
- A session that hits a limit moves to an account with room, or parks and resumes when the limit resets.
- My decisions
- Spending money, new accounts and steps that cannot be undone are requests I answer from my phone. A pasted key goes to a locked store before an agent sees it.
- Quiet leads
- A lead gets its news in batches, and asks to be woken later instead of checking again and again.
- Alerts
- Only for a decision, an approval or a failure, plus a short catch-up summary.
- Updates
- Both computers update themselves, and a web-only change ships without a restart.
Results
With the first method
- ~500 commits in 12 days
- 100+ commits on the busiest day
- <½ the time for three slices built side by side
With the second method
- ~10 agents working at once, at peak
- 300+ agent sessions in the always-on box's first week
- 0 laptops that have to stay open
The code, data and models are private.