Every assistant I built needed an assistant

I've tried to build myself a chief of staff three times. Each time, the question was a little different.

The first asked: what if my body double was mine? It was a 3D sprite that sat beside me while I worked, running as a local Electron app. It did what it did well, but I had to type in every action myself and store them in a JSON file, and I couldn't check it from my phone. Looking back, it was a pretty wrapper on a local database.

The second asked: what if it captured everything? About five months ago I built a Markdown structure in Obsidian, with scheduled routines to extract, update and keep everything current. It had the opposite problem. It captured everything, so it added to my load instead of taking from it. The only way to use it was to connect Claude Code and have it reread all the context every time. It had all the information and far too much of it, and there was never a moment where it just told me to do this one thing. The backlog never got shorter.

Both worked, and both died the same way. The friction of using, updating and repairing them outlived their usefulness.

The problem they were solving is one everyone has. Work comes in through Outlook and Teams, meeting notes land in a Markdown file, email piles up, and half of it arrives in a side conversation in the office. It all has to live somewhere. I've used spreadsheets, notepads and sticky notes, and maintaining any of them is exhausting. The systems I built were supposed to take that off my plate. Instead each one became a part-time job just to keep running, and every time one broke, the question was the same: how long is this going to take me to fix?

I kept going because I don't let a good idea go. I want the administrative burden off my plate, and it's an area I know I need support on. Every attempt solved what I thought the problem was at the time. Some ideas are good ideas; it just isn't their time yet.

What changed

I'm not sure the frontier moved this week. It may have moved months ago. It's jagged, to borrow the term from the Harvard/BCG study Ethan Mollick co-authored, and the models won't tell you when it moves. Ask one to build something and it'll just build it, the way it wants, from training data that's often six months old. It won't survey your options or question your approach unless you make it.

So I make it. Every model I use gets the same standing instruction, and research and design work gets a second one on top.

The first one makes me earn my ideas. The model doesn't always push back on the right thing, and that's part of the value. Deciding which objections to take forces me to practise judgment instead of handing it over.

That's how I found out the ground had shifted. I asked Claude to look at my last month of email and give me rules to clean up my inbox, and it worked in one go through the Microsoft connector. Connectors that used to be fragile are now competent, and Opus 5.5 is consistent enough that I'm not wondering whether I'll get a four out of ten this time. I still name the connector out of habit, so it doesn't do something weird, but I don't need to.

Reading the data where it lies

That surfaced the lesson from the first two attempts. The painful part was capturing data from all my sources and maintaining duplicate databases of information that already lived in the systems of record. The intelligence was fine. Now I didn't have to duplicate anything. I could read the data where it lies.

So the third attempt asked: what if it only ever showed me one thing?

When Opus 5.5 came out, I handed it the mess: here's what I've tried, here's what didn't work, can you help make it workable? A problem I haven't been able to solve is always a good test of what a new model can and can't do in the real world.

What Tandem is

Tandem is an always-on dashboard plugged into the places I already work. At a glance it shows me the one thing to do next, and it's where I capture all the ad hoc items that used to end up on sticky notes. The core loop is simple: here's the next thing, do you want to do it now or not? If yes, you work on it, and when it's done you score points. Its memory is Linear, which it writes to on my behalf. I never open it.

What I like most is that it builds the day around my actual calendar. If I have a day of meetings and only a couple of half-hour gaps, it suggests work that fits those gaps and helps carve out time for deep work.

What it feels like

The part I didn't expect is that it's a joy to use. It shows me one thing instead of a list, and every finished task grows a small world under glass. I've come to think the joy isn't a nice extra; it's the reason I'm still opening it. That's the next post.

The working

It hasn't all gone smoothly. A model once told me it had filed something it never wrote, and that one failure reshaped the whole design. It's in the blooper reel, part 3.

The fine print

Nothing on the shelf fit the way I work, and I have a strong stance against death by SaaS. When the need is this particular, a generalist product isn't what you want. Tandem uses the standard connectors, including Microsoft's own, so the data stays in the cloud systems those connectors already reach. The one new place is Linear, where Tandem files the commitments it extracts. It runs on Claude today, which means some data goes to a third-party provider, but it's designed so it could run as a closed loop inside my own systems. If you build something like this, check that every connector and service meets your contractual requirements, and if you need zero data retention, verify each one rather than assuming. The inference layer could just as well be a local model or ChatGPT.

The test

The test I'd put to any AI system, including the ones you're buying: does it cost more time to keep alive than it saves? So far, mine doesn't.