The Colony
Around seventeen specialized AI agents on Claude, running across two cloud servers and a local GPU workstation, coordinated through MCP servers and a file-based memory layer I wrote myself. It is mine end to end, and it runs every day.
The shape of it
Seventeen agents is easy to say. Keeping them alive is the hard part. Each has a defined job, and they share one memory and one set of rules. Some run in the cloud on two Hostinger servers; the orchestration host is a local RTX 5080 workstation. They work in parallel, hand off to each other, and run on their own, with me in the loop only for what can't be undone.
What makes it more than a pile of scripts is the memory. Every agent reads and writes durable state through file-based contracts, so a session that ends at midnight is picked up coherently by whatever runs next.
The parts that travel
- 20+ MCP servers integrated, several written from scratch, giving agents the ability to act on databases, APIs, file systems, and the browser.
- 64+ custom Claude Code skills spanning automation, content, DevOps, and system administration.
- A library of production safety gates, reusable across every project: operator-default checks, verification gates, destructive-action guards, backup-integrity verifiers.
- Retrieval over a Qdrant vector database, so agents can pull what they've learned instead of starting cold.
A self-improvement loop
The part I'm proudest of: the agents capture lessons at the end of each session and rewrite their own instructions. The system gets a little better on its own, and I get the receipts. Every change is committed, so I can see exactly what it learned, and roll it back if it learned the wrong thing.
Codifying repeatable patterns and feeding insight back is responsibility four on the FDE list. I've been living it on my own infrastructure for a year.
The decisions that keep it alive.
Seventeen agents running for a year is easy to claim and hard to survive. The interesting part is what you do about the failure modes that only show up at month three. Here are four of those calls, in plain language, with the personalities left out of it.
Why the memory is plain files, not a clever database
An agent's session ends, and another one starts hours later with no memory of what just happened. That gap is where a multi-agent system quietly falls apart. I keep the durable state in plain files with a fixed contract for how each agent reads and writes them, append-only, so nothing already written gets overwritten by a confused later run. A database would have been the obvious reach, but plain files are something I can open and read with my own eyes when an agent does something strange at 2am, and something version control already tracks for free. The test wasn't which store was fastest. It was which one I could still debug and trust six months in.
Why the rules are mechanical gates, not just instructions
You can write 'always verify before you delete' into an agent's instructions, and it will hold right up until the agent is under pressure and reasons its way around it. Soft discipline loses to the model's own confidence. So the load-bearing rules don't live in prose, they live in mechanical gates that run outside the agent and can actually stop it: a destructive action gets blocked at the gate, not reminded against in a paragraph. That lesson cost me a few near-misses to learn. Anything you genuinely cannot afford to have go wrong, you enforce in a layer the agent can't talk itself past.
Why a human is only in the loop for what can't be undone
Ask a person to approve every step and you've built a slow assistant, not an autonomous system, and the friction buys you nothing because nobody reads the hundredth approval. So the agents run on their own for everything reversible, and I'm pulled in only where the action can't be taken back. A commit can be reverted, so they commit freely. A thing that touches the outside world and can't be unsent waits for me. Drawing that line in the right place is the whole difference between automation you trust and automation you have to babysit.
Why the agents rewrite their own instructions, and I still sleep at night
At the end of a session the agents capture what they learned and edit their own rules, which sounds like exactly the thing you're not supposed to let software do. The reason it's safe is that every change is a commit. I can read precisely what it decided to learn, and if it learned the wrong lesson I roll it back like any other bad change. Self-improvement without receipts is just drift you can't see. The version history is what turns it from a black box into a system that gets better in the open.