I spent a year trying to improve Claude Code.

One common technique I use to speed software development is that I’ll take one feature or bug fix and I’ll break it up across multiple agents, in order to accomplish more, faster.

Well, that was the theory. What I kept running into was that each agent had a different idea of where they should stop and start their part of the build.

I found myself playing telephone between these agents — spending a lot of time trying to understand what the agents were thinking and then attempting to align them.

I tried speeding this process up with techniques like asking the agents to write documents explaining their thinking and then I would pass those documents between them. But even that was tedious, and not as fluid as I felt the conversation could be.

In an effort to solve this, I gave every agent a walkie-talkie — a tool that allowed them to see who the other agents were, what they were working on, and talk directly to them.

This allowed me to split fairly large projects across many agents. Each agent could still come and ask me questions directly, but where they needed to coordinate, I would just ask them to do so.

And what started out as a simple tool to speed up software builds eventually became the foundation for many features and systems that solved problems like this next one.

Here’s a common scenario: I get an email, a Slack message, or a text about a project I am working on. It is usually a bug request, a question, or a new feature idea from someone I’m working on a project with.

Some of these requests are small enough, or so well described, that basically all I need to do to complete the job is to open up a Claude Code agent and copy and paste in the request.

But, no matter how simple the request, I was still responsible for relaying the message to Claude Code in order to get started.

I built an app for my phone that enables Claude Code to have total control of my phone, including allowing Claude Code to read all of my notifications as they come in.

What this meant was that Claude Code could just read the requests as they came in instead of me having to copy and paste them over. Now all I had to do was teach a Claude Code agent how I wanted these notifications to be handled, which led me to my next problem…

It took me a long time to figure out how to make use of Claude Code looking at all of my notifications.

At first, I tried to jam way too much responsibility into a single agent. I was asking this one agent to look at every notification, recognize whether the message is a request for any of the on-going projects, and then go fulfill the entire request to the standards I have for that specific project.

Unsurprisingly, when a notification came in, this one agent would rarely even get close to doing everything I was hoping for, sometimes doing more harm than good. I quickly turned off the feature.

My next approach was to split the responsibilities of the one agent. Before, I was asking it to know both how I wanted my notifications to be managed and how I wanted each project to be managed.

To split things out, I taught one agent to just handle the notifications and then, for each project, I taught a dedicated agent how I wanted that specific project to be managed.

Then, when a notification would come in, the agent handling the notifications could just focus on sending the request to the right project’s agent and then that project’s agent could just focus on implementing the actual request.

While splitting up the responsibilities did dramatically improve the results of the Homestead system handling a notification on its own, I found that it was still rare for everything I was asking for to be done to perfection.

Granted, I was asking Homestead to do every part of the job that I used to do — up until literally clicking send on a reply message.

So for requests for certain projects, my expectations were that the Homestead system recreate the issue, write the fix, provide evidence that the fix works, write a guide for me to test the fix, push and deploy the code where needed, and finally draft a message back to the sender.

Homestead would regularly get steps one and two done but would become unreliable thereafter, maybe knocking out one or two of the remaining steps. So I would come back after it was done working to find I still needed to poke and prod that project’s agent, often just repeatedly asking it to go read its instructions and complete all the tasks.

Splitting up the responsibilities worked once — why not try it again?

Initially it was not clear to me where I should make this split. Do I divide up the tasks amongst multiple agents where say one agent writes the code and then another agent tests the fix and so on? If so, how many agents do I get involved? Would specializing this way even be helpful?

After some experimenting, the best split I found was not to divide up the actual development work — but to instead have one agent continue to do all of it, and then have another agent whose whole job is just to audit the agent that does the work.

What this system eventually turned into is what I call Steadings. Each Steading represents a project or a responsibility.

Each Steading has one agent called the Steward. The Steward’s job is to know how I want that Steading’s project or responsibility to be managed.

The other role inside of a Steading is the Worker. A Worker is spun up for one specific task or feature, and then spun down once complete.

Here is how Stewards and Workers work together: a Steward spins up a Worker for a specific task. Once the Worker stops working, the Steward is notified and begins to audit the work — to see if the Worker actually completed all the steps in the instructions for that Steading. If not, the Steward tells the Worker where it dropped the ball, and the Worker gets back to work. This cycle continues until the Steward is satisfied.

For some concrete examples, here are all of my steadings. Over here on the very left is Alfred. Alfred’s steading is in charge of processing the notifications that come to my phone. Right beside it is Big Jim’s steading, who is in charge of the projects my neighbor Big Jim and I come up with.

Big Jim will text me with either a tweak to an existing project or a brand new idea. The notification lands on my phone, Alfred sees it, and then forwards on the request to the Big Jim Steward. The Big Jim Steward will read the request and determine if there is already a Worker who can handle this request or if the request will require a new Worker. So either a new or existing Worker gets the request and that Worker will work away until the Steward determines the Worker’s work is satisfactory.

“Where Homestead is going” is a great question. The “pie in the sky” answer is that it would eventually become your “one interface”. The idea is that you would have one screen you would interact for work. Then, in a nearly chat-like interface, you would be presented with the next most important question you can answer along with the data you need to make the decision.

For AI to present you the “most important question”, it would need to deeply understand your life/business, priorities, and have access to all data and channels. But, with enough coordination, all work would become is simply pulling up the “one interface”, make the human-decisions your projects need, continuously keeping AI abreast with current priorities (like you would a business partner), and continually optimizing the “one interface”.

I don’t think anyones Homestead should look exactly the same and no one’s homestead should ever be “done”. It should evolve with you.