Give your AI a home.

I once had a system that could send a lot of AI agents to work at once. It was impressive to watch. It was also hard to tell who had made a decision, what they had learned, or whether the next run would make the same mistake.

So I stopped building the fleet.

What I have now is a small guild of named assistants. Each has a directory on disk with its instructions, memory, and a record of recent work. They share a task queue. They work in the open, where I can see what happened and correct it. I can change the model or the tool that runs one of them without throwing away its history.

The useful part isn’t the name or the fiction around it. It’s that an assistant can return to work on Tuesday and know why it made a decision on Monday.

The problem was the second session

A capable model can do good work in one sitting. The trouble starts when the session ends. A new session can read the code, but it can’t infer every conversation, failed attempt, constraint, or promise that led there. It may repeat an experiment that already failed. Worse, it may confidently reverse a decision whose reason isn’t visible in the repository.

Long prompts didn’t solve this for me. They became an untidy mixture of permanent rules and yesterday’s events. Chat history helped until it was too large to load, or the assistant moved to another runtime.

I wanted a place for the few things that actually need to survive: who this assistant is meant to help, how it should work, what it has learned, and where it left off.

What a home contains

An assistant’s home is a directory of ordinary text files. Mine has an identity file, an operating manual, individual memory notes, and a short handoff. A shared folder holds the work queue and the rules everyone follows. There is no special database format to rescue if I change tools.

The files do different jobs:

• Instructions say how the assistant should behave every time: what it owns, what it can change, and when it must stop and ask me.
• Memory holds durable lessons. A correction I’ve made belongs here if I don’t want to make it again. A detail the assistant can get from the code does not.
• The handoff says what happened recently and what needs attention next. It is written after meaningful work, not on a timer.
• The work queue owns task state. A handoff can point to a task, but it doesn’t get to make up its own version of whether that task is open or done.

One line from a real memory note says to test that honest inputs pass, not just that bad inputs fail. That note exists because we spent too long proving only half of a guardrail worked. It has saved us from paying for the same lesson twice.

On each new session, the assistant reads its home, catches up on any newer handoff entries, and checks the queue. That’s the whole trick. The files don’t make the model smarter. They keep it from waking up blank.

Why the agents have names

The name gives work an owner. I can ask Fred what happened to a project, or ask Iris why she made a call, and there is a home and a record to inspect. I know which assistant to correct when a rule is wrong.

I still use temporary subagents for bounded jobs. They can research a question or implement a piece of work and report back. They don’t need a life story or a memory directory. The named assistant keeps the context and owns the result.

That distinction made the system easier to manage. A stable group can learn. Temporary workers can come and go without leaving a trail of half-maintained identities.

Keep the work visible

I don’t want agents doing significant work in a place I never look. A task has a written brief. When an assistant finishes, the result and evidence go back on the task. A short message can tell the others there is work to pick up, but the message is not the record.

This is partly about trust. It is also practical. If I disagree with a choice, I need to see what was assumed and what was checked. If an assistant disappears mid-job, another one needs somewhere reliable to resume. An unreadable stream of model calls gives me neither.

We use beads for the queue and a git-backed wiki for shared project knowledge. You don’t need those exact tools. You do need one place where task state lives, and one place where reusable facts live. Otherwise every handoff becomes a hunt through chat logs.

Steve Yegge’s writing on agents and his work on beads pushed me to try the larger fleet in the first place. The experiment taught me that sending out more workers was easy. Keeping their work coherent was the harder part.

How I’d start again

I’d begin with one assistant and one directory. Give it a short operating manual, an empty memory index, and a handoff file. At the start of every session, have it read those files. After meaningful work, have it write down what changed and what it learned. Put the directory in a private git repository and make sure the changes actually get pushed.

Then use it for a few weeks. Correct it when it gets something wrong. Check whether the correction survives the next session. If work starts outliving sessions, add a queue. If a second assistant needs the same project facts, add a shared wiki. Don’t build the whole organisation before you have one assistant worth keeping.

There are limits. My agents run on machines and accounts I control; their separate homes are an organisational boundary, not a security boundary. At work, persistent memory is a data store and needs to be treated as one. And no amount of memory excuses an assistant from checking the current system before acting.

The result is less theatrical than a fleet of autonomous agents. It is also more useful to me. I can leave a piece of work, come back later, and carry on with someone who remembers what we tried.