RIP: My legacy leadership playbook 

Our CEO dropped this in our leadership channel yesterday:

That was the whole thing. No urgency, no ask, no "who's got this." Just: a customer had a question, our support agent “Sporty” went to look into it, and our own API couldn't tell it what it needed.

So what do I do with that? I wrote two replies and deleted them both. Sadly, I was operating from a legacy playbook.

Here's (roughly) the first one, which is the one I would have sent a year ago:

Every sentence in there is defensible (or was in 2025). It's also, from start to finish, an argument for not doing the thing right now. It protects our roadmap. It protects the team. It protects me — I'm just asking the responsible questions. Where's the evidence? What's the pattern? Nobody argues with those. And it asks the CEO who just told me our product has a gap to go collect evidence first. Imma go ahead and delete that, I’m somewhat self-aware.

Then I started typing this instead:

Better, right? Sounds collaborative. It's also me handing the prioritization call back to the CEO. It’s two questions and zero ownership. So I deleted that too. Maybe I will just ignore him.

Time to open up Claude and ask it to go investigate. I had meetings and other work to do, but I could also start up a side quest in cmux.

Claude came back with a couple of things. It found not just a missing API surface, but an actual bug with the support agent. It posted some suggestions to Sporty’s Slack thread. Then we started opening pull requests. Three PRs and then two more for yak-shaving reasons. Claude helped me get it all deployed in under 24 hours (manager time, not maker time), while I was in my regular meetings doing my regular job.

Now, here's why I don't think that was me doing a favor for one customer.

We talk about going agent-first at Customer.io. It's easy to hear that as agents using Customer.io—sending the emails, SMS, building targeted audiences and automations. That's the version everyone pictures when they think agent-first.

But agent-first also means agents can debug and diagnose for us. Every surface of our product should be drivable agentically, including the boring ones. So when there's a gap in our ability to debug something for a customer, or in a customer's ability to debug it themselves, that's not a support annoyance and it's not a feature request. It's missing functionality. It's a thing we say the product does that it doesn't do.

And once I see it that way, my first draft falls apart. "Show me the pattern" is a reasonable thing to say about a feature request. It's the wrong thing to say about a product vision gap.

Ninety percent of our product is already agent-operable. The last ten percent is where the hard stuff lives, and "show me the pattern" is exactly how ten percent stays ten percent forever. Gaps like this never announce themselves as a strategy. They just make "an agent can run Customer.io" a little less true every day we don't close one.

So I closed this one. It was also fun, and I learned a bunch. I learned how some of the more arcane parts of our system actually get deployed. I worked with engineers as a peer. I sat and waited for our CI, and felt the same friction my team feels every day. You don't get that by putting the CEO’s ask in the backlog.

This morning:

Getting the fix out mattered. The CEO publicly blessing how it got fixed mattered a lot more—that's the part the rest of the org reads.

Declining work to protect your team's focus used to be the right call. There's a lot more we can do now, both with agents and for agents. So before you protect the roadmap, ask whether it's a feature request or something you already say your product does. If it's the second, scheduling it is just dodging responsibility with extra steps. Close it.

And if you read all that and think well, yeah, obviously—and you see the world where agents are doing the debugging, the customer support, and the product interactions, not just the code? Come talk to us. We're hiring.