Tuesday, March 24, 2026
How I Built a Team of AI Agents to Run My Life
Posted by
I said I would never do two things: post AI productivity content, and anthropomorphize AI agents.
Then I spent a weekend building a small team of agents to help run my actual life, gave them personalities, and recorded the whole thing.
This is not a claim that I am suddenly 100x more productive. That genre is mostly nonsense. But it has been genuinely useful, and the structure is simple enough that other people can build their own version.
Start with projects, not agents
Most agent demos start in the wrong place. They begin with a swarm, a framework, or a cute name.
I started with work.
My life already has recurring areas of responsibility: research, content, networking, customer success, finance, life admin, and a few product/building projects. Each area has tasks. Each area has workflows. Each area has things that repeat.
That is the foundation.
The system I built, Zeu, has one orchestrator and a set of project agents. The orchestrator is the front door. I give it a rough request, usually in plain language. It turns that request into a requirement document and routes the work to the right project agent.
The project agents do not invent vague work for themselves. They execute scoped tasks.
That distinction matters.
Requirement documents are the whole trick
The most important part of the system is not the personalities, the UI, or the fact that multiple agents can run in parallel.
It is the requirement document.
Every task gets an RD before it is executed. The RD defines what is being done, why it matters, what done looks like, what the agent can do without asking me, and where it needs my input.
No RD, no task.
This sounds bureaucratic until you watch what happens without it. Vague tasks produce vague work. Agents wander, overreach, or stop every five minutes because they do not know what boundary they are operating inside.
The RD gives the agent a contract.
It also forces me to be clearer. If I cannot explain what done looks like, I should not be delegating the task yet.
Skills are the workflow library
Each agent has a skills folder. These are just markdown files that describe repeatable workflows.
For example:
- how to scan Reddit for useful conversations
- how to draft a subscriber outreach email
- how to prepare a video publish pack
- how to update a backlog
- how to clean up after a content launch
This is not glamorous. It is just operating procedure.
But it compounds. When an agent learns a better way to do something, the skill gets updated. The next run starts with better instructions.
That is the difference between an agent that performs one-off tricks and an operating system that gets gradually less stupid.
The UI is boring on purpose
The dashboard is a simple kanban over JSON files.
That is it.
There is no complicated SaaS backend. No elaborate agent orchestration platform. The useful part is that each project has a visible backlog, clear lanes, and enough structure that both I and the agents can see what is happening.
At any moment I can see what is scoped, assigned, blocked, in review, or recurring.
The agents can also read and update the same files. That means the operating system is not hidden in a chat thread. It is visible, durable, and boring enough to trust.
The memory layer is RA-H
The part that makes this work across time is memory.
Not "the model remembers everything" memory. A local database.
Each agent can read from and write back to RA-H. If the customer success agent learns something about a user, that context can become a node. If the networking agent finds a person worth following up with, that can become a node. If a content launch reveals which angle worked, that can become a node linked to the task, video, and distribution channel.
Without that layer, every agent is just running a workflow from scratch.
With it, the system starts to build a map of what has happened and what matters.
That is why I keep coming back to the same point: if agents are going to do real work for you, they need a context substrate they can read from and write to. A markdown file can work for small things. A local SQLite graph is much better once multiple agents are involved.
Personalities are not just for fun
I resisted giving the agents personalities because it sounded silly.
It helps.
A good persona is not a cartoon. It is a compact description of how an agent thinks about its work. My customer success agent cares about which users could become meaningful advocates if properly helped. My networking agent hates generic outreach. My content agent is allergic to AI productivity slop.
That changes the output.
It also makes it easier to reason about ownership. The agent is not a magical all-purpose assistant. It is a specialist with a backlog, a skill library, and a standard.
What the demo shows
In the video I run tasks live.
One agent handles subscriber outreach. It looks through user context, identifies people with businesses or interesting use cases, drafts personalized emails, and can send through Postmark when approved.
Another agent scans Reddit for relevant threads and drafts replies.
The point is not that either task is impossible for a human. The point is that these are exactly the annoying recurring workflows that are worth systematizing.
If you can describe the workflow, write the skill, and define the RD, the agent can do a lot of the work.
How to build your own
Start smaller than my setup.
Pick one area of your life where work repeats. Content. Research. Emails. Admin. Anything.
Create a folder for that project. Write one AGENTS.md file that says what the agent owns. Write one skill for one workflow. Create one clear task with done criteria. Run it. Fix what breaks.
Then add a second workflow.
The leverage comes from discipline, not complexity.
If you want the full template, the Zeu repo is here: github.com/bradwmorris/zeu.
If you want the memory layer, use RA-H or the open-source RA-H repo.
The real pattern is simple: scoped work, clear ownership, repeatable skills, and a database that lets the whole system remember what happened.