Founder OS connects your email and calendar to Claude, so handling your admin becomes a matter of asking for it. One command to install, and it runs on your own machine.

It started as infrastructure for me rather than as a product. I run three ventures, and the admin between them had quietly grown to eat the hours I needed for the actual work. Rather than adopt another tool that would want its own attention, I built the layer that lets an agent operate the tools I was already using.

Once it was reliable enough that I depended on it daily, giving it away cost nothing and was obviously more useful than keeping it, so it’s free and open source.

It can read your mail, draft replies, look at your calendar and propose meetings, but it can’t send or archive anything on its own. Every outward action stops and waits for you.

That one boundary is what makes the rest usable. An agent with write access to your inbox is either carefully bounded or it’s a liability, and the boundary has to be built into the thing rather than promised in the documentation, because a promise in the documentation isn’t a boundary.

It also clarified what the product is for. It isn’t trying to run your inbox for you. It takes away the reading, the sorting and the first draft, and leaves everything with consequences attached to you, which is the split I actually wanted.

Installing it is a single line, which sets everything up and walks you through connecting your account.

Most of the design effort went into that connecting step, because authorising access to your own email is genuinely unpleasant. Expiring tokens, consent screens, access getting blocked for reasons the error never explains. I worked out the three failures people actually hit and named them in the words the error uses rather than the words an engineer would reach for, which is a small thing that decides whether someone finishes setup or gives up.

After that there’s no interface to learn. You open a terminal and talk to it. Help me with my emails. What’s on my calendar this week. The absence of a UI is the design decision here, not something I didn’t get round to.

The part I didn’t plan for is the part that’s turned out most useful. Because the agent can write code, you can just ask it for a capability and it’ll build one. Describe a workflow involving your notes app or your CRM and it writes that integration into itself, then uses it.

That inverts how a tool normally grows. No roadmap deciding what it’s allowed to reach, and no plugin system that had to be designed up front and guessed right. The way you extend it is the same conversation you use for everything else.

Designing for that meant treating the codebase itself as an interface, clear enough that an agent can find the right place to put something new. Which turns out to be nearly the same exercise as making it clear enough for a human contributor, just with less benefit of the doubt.

Founder OS is live, open source, and the thing I reach for most days. Its descendants run my actual operations now, triaging inboxes across three ventures every morning and surfacing only the handful of things that need a decision from me.

The transferable part is the shape rather than the code. Take a workflow that already exists, give an agent bounded access to the systems that workflow already touches, hold every outward action behind an approval, and let it extend itself from there. That’s the pattern I use now when I build automation for other people, and it came out of trying to get my evenings back.