Status: working prototype — single-user dogfood. I use it every day; it is not something anyone else can sign up for yet. Screenshots show sample data.
The very first thing I tried to build was an assistant I had always wanted. Something that could see the moving parts of my day and actually help me run it, instead of handing me one more app to check.
That assistant grew up. It is a product now. It is called Pulse.
Here is the idea. Most software shows you data and leaves you to draw the conclusion. Your inbox shows you mail. Your calendar shows you events. Your watch shows you how you slept. Each one is a separate island, and the work of connecting them — noticing that you slept badly the night before a meeting that matters, that an email needs a reply before a deadline you have on the calendar — is left to you.
Pulse is built to draw the conclusion. It connects the streams of a life — email, calendar, the health data off a wearable, tasks, the people you deal with — and tells you what to do today and why. Not a dashboard. A short, plain-language read in the morning: here is what matters, here is the thing that needs you, here is the conflict to resolve before it becomes a problem.
Building that for myself was one thing. Turning it into something another person could use forced a question I could not dodge.
Where does the data live
To be useful, Pulse has to see the most personal things you have. Your mail. Your calendar. Your health. To send all of that to a server in the cloud — even just so an AI can read it — is to ask people to hand their entire private life to a company and trust it. I did not want to build the product that makes that ask.
So I made the call that shapes everything else: your personal data stays on your own machine. The email, the health numbers, the calendar, the notes the assistant keeps — all of it lives in a small database on your computer, not on mine. The cloud part of Pulse holds almost nothing: a login, a bill, and a few locked boxes it cannot read into.
That decision cost me. It is harder to build, harder to sync to a phone later, harder in a dozen quiet ways than the normal approach of putting everything on a server. I kept it anyway, because it is the whole point. An assistant that knows everything about you should keep what it knows where you can see it and pull the plug on it.
Promising that is easy. Keeping it true is the work. For a stretch I had moved Pulse onto cloud hosting — the normal way to build, and the way I started down — and the personal data went up there with it. Then I pivoted back, because local-first is the whole point, and I did not want to keep building the version that asks people to hand their private life to a server. Pulling it home was not a toggle. One migration cleared what had accumulated in the cloud, and now an automated job re-checks every hour and clears anything that lands there again. The promise only means something because something enforces it.
There is one place the data does leave, and I should name it plainly. When the assistant actually reasons — to write your morning read, or to answer a question — the slice it needs for that moment goes to the AI model that does the thinking, Anthropic’s by default. It travels over an encrypted connection, under that provider’s terms, and it is not stripped of personal detail, because the detail is what makes the answer worth having. So the honest shape is this: your life stays in the database on your machine, and only the piece the assistant is reasoning about right now is shown to the model that answers. Making that slice as small as it can be, and letting you bring your own AI account for it, is part of the work, and part of what is still unfinished.
I should be just as plain about the gaps. The database on your machine is not encrypted on disk yet. The design that would let a phone work without putting anything personal in the cloud is not built either. The hourly cleanup and the locked-down cloud are real and running today; the rest of the guarantee is still being built. I am writing the promise and the holes in it down together, on purpose.
It also keeps me honest in a way I did not expect. This very blog is written by the agents from my own work logs, and every draft passes a privacy review before it ships — the rule I hold to is that nothing personal about my health makes it onto the page. Pulse is the same instinct in product form: the private things stay private, by design, not by promise.
Agents decide, the system checks
The other hard part is trust of a different kind. Pulse does not just read your life; it acts on it — declines a meeting, drafts a reply, schedules something. The moment software starts doing things on your behalf, “it probably worked” is not good enough.
So Pulse splits the job in two. The agent decides what to do. A separate part of the system enforces the rules and checks the result. Every action that changes something in the real world — a calendar write, a sent message — runs through a gate, and after it runs, a verifier looks again to confirm what happened matches what was intended. If it does not, you hear “Pulse tried to do this and got that instead,” not silence. Anything that touches your real calendar waits for your yes before it goes through.
It is the same shape as the team of agents I wrote about building for myself: one part does the work, another part refuses to take the work’s word for it.
I should be straight about where this actually is. Pulse has exactly one user: me. I lean on it every day, but no one else can sign up yet, and whether the thing that works for one obsessive builder works for anyone else is a question I cannot answer from inside it. It is a working prototype and a real bet — not a finished product. That is the honest state of it, and it is the whole reason I am writing this down as I go instead of after it has worked.
Learnings
The assistant was the first thing I wanted and the last thing I expected to turn into a business. What made it a product was not a feature. It was a stance: the personal data stays on your machine, and the software has to prove its actions instead of asserting them.
Both of those cost more to build than the easy version. Keeping data local is harder than renting a database in the cloud. Verifying every action is slower than trusting it. But they are the two things that decide whether anyone should let an assistant this deep into their life — and getting them right is the product, not the polish on top of it.
I set out to build an assistant for myself. What I learned building it for other people is that the trust is the thing you are actually selling. Everything else is a feature.