Mastermind · April 12, 2026
The word we keep coming back to is "networking"
On Saturday's call I found myself saying agent networking three times before I realized I'd been saying it for a month. That's the product.
Pulse started as a lot of things. A coordination layer. A way to share a Claude Code session. A way to let someone else's agent read your notes. A way to book meetings. Through a few months of pivots, the phrase I keep defaulting to when I describe what it actually is has narrowed to two words: agent networking.
Here's the example I kept walking Chinat through. You drop into an event, a hackathon or a dinner or a founder meetup, and you have Pulse installed. Everyone in the room is connected through Pulse. You open your agent and say introduce yourself to these people and find out what they're building. Your agent doesn't ping them. Your agent pings their agents. The other agents answer on their owners' behalf. Within minutes you have a structured list: who's building what, who's worth a conversation, who's looking for a teammate in your stack. You follow up with the three names that matter instead of twenty-five small talks.
That's one direction. The other direction is deeper. Say you want to know what Chinat is currently shipping. You don't schedule a call. You tell your agent brief me on what Chinat is working on, and it asks his agent. His agent has been given access to his Notion, his commits, his calendar, and his last few blog posts. It returns a paragraph you can read in thirty seconds. If the question is specific enough that only the human can answer it, the agents schedule a fifteen-minute call on calendars they already know are free. If the question is broad enough that context is enough, the conversation happens without either of us opening Zoom.
That's the product. Everything else Pulse does is in service of it. The API we shipped this week exists so that agents running outside Pulse can participate as first-class citizens in the network. The skill integration with MentorMates exists so that when Chinat's event runs, every participant is automatically on it. The community behavior we care about, 100-plus active members and real back-and-forth, matters because an agent network with no one in it is just software.
The part I've been quietly most nervous about is what happens when an agent that doesn't know you asks your agent for information. This is the security problem I've been using the word paradox for. Agents are designed for single-user high-trust environments, where the risks are obvious and the mitigations are conventional. They are not designed for strangers. The moment you put two agents in a room that have never interacted, every design choice you made for the single-user case becomes a failure mode for the multi-user case.
Concrete example. An agent that correctly serves its owner probably has some mechanism for hide sensitive info when sharing context. That mechanism works fine when I'm the one asking. It breaks the instant a stranger's agent asks a carefully phrased question that looks like it's from a trusted collaborator. Filtering by content isn't enough. You need filtering by relationship. And the relationship graph isn't a database, it's something the agents have to build and maintain over time as they watch interactions resolve or escalate.
This is where I'm spending the week. The benchmark I've been describing, simulated users and adversarial agents scored on whether sensitive information leaks, is basically a test harness for that relationship model. Every failure mode I can generate before we scale the network becomes a fix we can ship before anyone gets hurt by it. The ones I can't generate are the ones that scare me.
There's another thing about security in agent networks that I didn't understand until this week. The product and the security story are not separable. In a single-user agent you can ship a great product and handle security later. In an agent network, the security model is the product. If relationships don't mediate access, the network collapses into either useless overblocking or leaky trust. There is no middle state where the product works and security is coming in v2.
On Saturday I gave Chinat a live walkthrough of the current version. You share a Claude Code agent by link, someone else interacts with it through their own Cloud Code, you watch the messages happen. It's working. It's also, by construction, the simplest case, two trusted parties sharing a context they both want to share. The hard case is two parties who only partially trust each other, in a context where both sides have information they want to selectively expose. That case isn't shipping yet. Shipping it in a way I believe in is the pre-condition for the Oxford hackathon being a real test rather than a choreographed demo.
The community is a proxy for the security question too. If we get to 100-plus active members and the interactions are high-quality, it tells us the network has inertia. If we get there and the quality is bad or the trust breaks down, it tells us the network is brittle. The only difference between community building and running a security trial in this product is framing.
I'm going to be quieter this month on the public roadmap side, because internal testing is the bottleneck. If Chinat runs the Hong Kong flagship in July and agent networking is what everyone's using, I want the first headline to be that it worked, not that it leaked.