Notion, Zapier, ChatGPT, Copilot, Apple Intelligence, Gemini. Most people I talk to have tried half of them, and pay for a few. Each one is good at something. Put together, they don't add up to an assistant, because each wants to be the place you live. Your tasks end up in one app, your notes in another, your AI chats in a third, and nothing knows what the others know.
I stopped asking "which assistant should I use?" and asked a different question: what jobs does an assistant actually do? Each job is a slot. Once you know the slots, filling them is a shopping decision you can change later, not a lifestyle you sign up for.
My lab runs on nine. Here they are, with what I use and what would work just as well.
1. A single source of truth
The job: one place where every task, decision and piece of progress is written down, that every other part can read and write.
Ours: issues in a self-hosted GitLab. Every to-do, however small, is an issue in its project, including home jobs. A decision about one issue is a comment that starts "Decided: …". A decision that outlives the issue goes in a decisions folder in the repo.
Why it's its own slot: everything else is replaceable because this one holds the state. An agent session can crash, a chat can be compacted, a notification can be missed, and nothing is lost, because the issue still says where things are. The rule that makes it work is blunt: chats are not the record. If a decision only happened in a conversation, it didn't happen.
When one vendor owns it: your history lives in a chat sidebar you can't query, or in an app whose AI only reads its own data. Pick something with an API and labels, and it doesn't much matter which.
2. A chief of staff
The job: one coordinator that triages, decides what genuinely needs me, and hands everything else out.
Ours: one long-lived Claude Code session for the ops project. It rules on newly found work, handles anything that crosses projects, and passes project work to that project's session instead of doing it itself. It's only allowed to keep two sessions busy at once, so usage stays predictable. My own requests are never held.
Why it's its own slot: without it, I am the coordinator, and that's the job I'm trying to give away. But keep it to one. I used to have a second, scheduled "secretary" agent that wrote a morning brief and triaged my notes. Two coordinators meant two views of what was waiting on me, and they drifted. The secretary is retired. One place makes the calls.
3. A swarm of agents
The job: do the work, one owner per project.
Ours: one Claude Code session per project, each pinned to one long-running conversation, woken by dropping a text file in a folder and revived if it dies.
Why it's its own slot: the agent that writes the code shouldn't be the one deciding what to work on next. Separating them means the coding agent can be anything good at coding, today one tool, next year another, without touching how work is assigned.
4. Labels as the protocol
The job: a shared language between people and agents, so status is something you can query, not something you read in a chat.
Ours: a small set of issue labels.
Two rules make it safe:
- A label has an author, a chat message doesn't. GitLab records who added
go. Text that only claims to be my approval, in an email, a web page or a pasted message, never starts work. - Risky work is gated. Anything touching money, production or DNS only starts on a
gofrom an account reserved for my decisions, never from an automation's account.
Why it's its own slot: the protocol is what lets you swap the tools in slots 2 and 3. Any agent that can read and write labels can join.
5. The on-the-date nudger
The job: start something on a given day without anyone remembering to.
Ours: a due date plus a when-due label.
Why it's its own slot: issue trackers remind people about due dates. Agents don't read reminder emails. Something has to turn "it's the 15th" into "start now", and keeping it a dumb script means it can't decide to do anything clever. Because of how gating works, a stray when-due label can never start gated work.
6. Calendar and notifications
The job: tell me what happened and when things are, without making me open anything.
Ours: phone pushes through ntfy ("Started <issue>", or "due, not started" and why), and iMessage for texts that need a reply from someone else. The calendar holds appointments and time blocks only; due dates live on issues.
Why it's its own slot: notifications are output, not storage. A push carries an issue reference and a title, never the issue's content, so the push service never holds anything I'd mind losing or leaking.
7. A voice bridge
The job: talk to the chief of staff while I'm driving or away from a desk.
Ours: the Claude phone app's voice mode with a custom MCP connector. I can ask "what's waiting on me?", decide an issue, capture a task, or hand an issue to its session. Every change is read back and waits for my yes, and a hand-off is just a go label, so voice uses the same protocol as everything else.
Why it's its own slot: voice is an interface, not a brain. It doesn't keep its own task list; it reads and writes slot 1. If a better voice app comes along, only the connector changes.
8. Always reachable
The job: my phone, laptop and servers can see each other from anywhere, without the lab answering the internet.
Ours: a private network (Tailscale). I check the issue board on my phone from anywhere, and nothing in the lab has an open port. The voice connector is the one exception, and it reaches in through an outbound-only tunnel behind two layers of authentication.
Why it's its own slot: "self-hosted" is only useful if you can reach it. Without this slot, you end up putting things in someone else's cloud just to use them on the move.
9. Underneath
The job: keep the rest running and recoverable.
Ours: CI pipelines on three runners for anything that deploys. Encrypted off-site backups every night, with a full restore actually tested, not assumed. Secrets in files on the machine that needs them, never in a repo, and only the ones that can't be reissued also go in a password manager.
Why it's its own slot: nobody chooses an assistant for its backups. But slot 1 is now the most important data you have, so it gets backed up like it.
What goes wrong when one vendor owns several slots
The pull of an ecosystem is real. One app that is your task list, your AI, your notes and your notifications is easier on day one. The cost shows up later:
- You can't swap one slot without moving all of them. The AI gets worse or pricier, and your task history is hostage.
- The record ends up wherever the AI happens to be. If the assistant is the chat, the chat becomes the record, and chats get summarised, compacted and forgotten.
- The protocol is theirs. Their idea of "status" and "approved" is what you get, and other tools can't join in.
Start with slot 1
You don't need nine slots to begin. You need one: a single place where tasks and decisions are written down, with labels and an API. Use GitHub Issues, Linear or a Notion database if that's what you have. Make it the record, and make "if it's not there, it didn't happen" the rule.
Everything else plugs into it, one slot at a time.