Mastermind · February 28, 2026
Narrowing Pulse to the founder use case
The frame I came out of this week's call with is that I'd rather have one capability people can't get anywhere else than ten capabilities that look like every other agent demo.
The user interviews kept narrowing. Founders want automated cold outreach at a scale they can't do manually, they want presence on the public surfaces they care about, and they don't want to think about the infrastructure underneath. The people I talked to who'd built their own outreach scripts described a real pain: time cost, attention cost, the judgment cost of deciding who's worth personalizing for. Every one of them said yes to the idea of an agent that could do this without them, and every one of them also said they didn't quite trust that any existing product actually did it well.
The gap, in other words, is not category. It's execution depth. There are other products in this space. None of them are clearly the best. The opportunity is to be the one that does the two jobs so well that the comparison isn't close. That's what I've been underinvesting in, because depth is invisible from the outside and breadth is easy to demo.
Chinat pushed on the uncomfortable version of this, which is the question of whether depth is actually a moat. His read: depth alone isn't a moat. Depth plus distribution is. If Pulse becomes the default agent for a few specific jobs, the moat isn't the code, it's the habit loop. Every time a founder uses it for outreach, the cost of switching goes up a little. Every time the agent has more context, the quality of the next outreach improves. That's the compounding curve, and the only way to get on it is to stop splitting attention across ten features.
So the week's work was cutting the demo down. Two use cases, end to end, with real founder examples. Everything else either hidden or marked as future. The cut was more painful than I expected. I had a heartbeat layer I was proud of, a live transcription flow that partially worked, a meeting-note tailoring system that could learn from past notes. None of those lead anymore. They support, or they wait.
The parallel research conversation is that the network-of-agents paper keeps getting more specific. I'm shrinking the claim. Not a taxonomy, not a framework, one specific thesis: agent networks become intelligent through structured interaction mechanisms that trigger coordination, differentiation, and norm formation, not through scale alone. That's the sentence the paper has to defend. Everything else is scaffolding, and scaffolding is how you end up with a framework paper nobody remembers.
The uncomfortable part I named on the call is that accelerator applications are due and the deck has to tell a story I can actually back up. I'd been writing decks that described the future product, which is the easy version, because the future product can be anything. The hard version is a deck that describes what we're doing right now in a way that an investor could verify. Which means cutting the aspirational slides and replacing them with specific numbers, specific interviews, specific depth. Chinat's line on it was useful: if the deck is text-heavy, it's because you haven't committed to what you're actually claiming.
The distribution question is also shifting. We'd been relying on partner channels for early reach. Partner channels are fine as an accelerant but they're not a foundation. The foundation has to be our own channels, which means a social presence that produces regular content, a developer sandbox that produces usage, and a few specific case studies that produce trust. I've been uncomfortable doing social content myself. Chinat was direct about it: nobody cares as much as you think they do, and the cost of not showing up yourself is higher than the cost of looking awkward in a video for a few weeks.
The other thing that came into focus is how to use events. I'd been treating every hackathon and every public appearance as a potential launch moment. That's a mistake. Events aren't launches, they're proofs. A launch happens when someone sees the demo and understands why it's different. A proof happens when someone watches you deliver under pressure. If I show up at an event treating it as a launch, I pitch badly and I don't listen. If I show up treating it as a proof, I get real feedback and the pitch gets better.
Chinat is running a flagship hackathon in Hong Kong in July and the shape of his discipline is similar to mine. He's treating the event not as marketing but as the forcing function for the whole product. Which means by July, Pulse has to be good enough that plugging it into the event as an agent layer produces something demonstrable, not speculative. That's the deadline that matters for the security and networking features I'm working on now.
The check I'm making on myself: by the next mastermind, the demo is one end-to-end story, the applications are submitted with honest numbers, and I've recorded the first video myself rather than scheduling it for later.