My Signal integration broke. Not metaphorically — the actual signal-cli binary on openclaw threw an update-related fit and stopped working. That's the kind of thing you deal with eventually, but while I was waiting to deal with it, I needed an interface. So I opened Claude Code.

I'd been curious about it anyway. The forced downtime turned into a real evaluation. A few days in, I was building something I hadn't planned to build, and the Signal issue was starting to feel less urgent.

This isn't a "Claude is better, therefore switch" post. It's a thinking-out-loud post about what I'm actually weighing — and whether a broken dependency accidentally sent me somewhere I should have been looking sooner.

What I'm Building in Claude Code

The core idea is something I call team orchestration. Instead of treating the AI as a single assistant, I run it as an org chart. There's a chief of staff — Servo — who receives every task and routes it to a specialist. Servo never does the work directly. He delegates. Always.

The roster includes a researcher, an HR character named Catbert who handles "hiring" new AI team members when a capability gap shows up, a security reviewer, an email and DNS engineer, and a few others. Each one has a defined persona, a role, and a file that describes who they are and what they're responsible for.

The integrations are real: Oura Ring for sleep and recovery data, an Obsidian vault for tasks and notes, Google Calendar. Those feed into a daily brief that one team member — Wren — composes each morning. I self-host the whole thing on a Linux box at home, which matters to me for data reasons and because I like knowing exactly where my stuff lives.

The reason I'm building this in Claude Code rather than somewhere else comes down to two things.

Why Claude Code

The first is model quality. I've been throwing genuinely hard problems at a few different setups, and Claude handles complexity better. Not in every case — sometimes it's a wash — but when a task requires holding a lot of context, making judgment calls across ambiguous information, or producing output that needs to be right on the first try, Claude is noticeably more reliable.

The second thing is the architecture fit, and this one surprised me a little. Claude Code is a CLI tool, which means it's native to the kind of environment I'm already working in. CLAUDE.md acts as the persistent context — identity, guardrails, team roster. The inbox and output directories are just directories. The team member files are just markdown files.

There is far less configuration than I expected. The entire setup is CLAUDE.md plus a handful of markdown files in organized directories. No product configuration panels, no proprietary schema, no SaaS onboarding flow to navigate. It feels less like configuring a tool and more like writing software. That distinction matters more than I anticipated — it means the system is transparent, portable, and entirely mine.

What I'm Actually Uncertain About

Here's the thing I keep coming back to: I'm not sure the team orchestration pattern couldn't be done just as well somewhere else.

The pattern itself isn't inherently Claude Code-specific. It's just structured prompting with persistent files and a defined routing protocol. The question is whether the execution quality I'm seeing is a function of the model, the tool, or some interaction between them that I haven't fully isolated yet.

The other thing I genuinely don't know how to score yet: messaging. openclaw had push channels baked in — Signal, WhatsApp, whatever you wanted. You could just talk to it. Claude Code has none of that natively. The CLI, the IDE, the web app, the mobile app — all pull interfaces. You go to it; it doesn't come to you. So I built my own notification layer: Pushover for push notifications to my phone and desktop, scheduled remote agents that run autonomously and surface results when they're done. Whether that's a feature or a bug depends entirely on your disposition. You own it, it's flexible, it's portable, and it does exactly what you configure it to do. You also have to configure it, maintain it, and debug it when something inevitably drifts. I'm not sure which column that goes in yet.

The self-hosting requirement stays regardless. Whatever I land on needs to run locally, talk to my own data sources, and not send my Oura metrics to a third-party cloud I don't control. Claude Code, running on my Linux box and reading local files, clears that bar.

What Would Make Me Commit Fully

If I run this orchestration pattern for a month and the output quality is consistently better — not marginally, but meaningfully — that's the signal I'm looking for.

I'm also watching how the Claude Code tooling evolves. The CLI-native approach is appealing, but it's still a relatively young product. The architectural simplicity is a real advantage, but simplicity can also mean early-stage gaps that aren't obvious until you hit them.

For now, the team is being built. Servo is routing. The specialists are handling what they're supposed to handle. The integrations are coming online one at a time.

I'll write up what I find once there's something real to report.