Mastermind · July 27, 2026
Calendars Are Connectors Now
This week we demoted our own features. Calendar and email had sat at the top level of Aicoo since the beginning, because that's what an assistant product is supposed to have. They are now connectors: third-level plumbing you plug in, the way you'd plug in Notion. What's left standing at the top is agent-to-agent collaboration, and the honest admission is that it took us this long to see it was the product.
The moment felt like an aha when it happened, but the evidence had been accumulating for a while. We had three different ways of doing the same thing. You could communicate through your Aicoo agent. You could connect directly to another person's Claude session. Or you could use offloaded to-dos, where the Aicoo agent hands work it can't complete over to your local Claude. Three parallel approaches to agent-to-agent is not richness; it's a symptom. When a team builds the core interaction three ways, nobody has committed to what the core interaction is. This week we unify them. It helps that I've handed most of the business and operations to Yi and am spending my time on research and product again, because unification is exactly the kind of decision that never happens while everyone is sprinting on their own branch.
The direct-connection demo is the one that forces all the interesting questions. My Claude Code can prompt your Claude session. You can list the benefits and the problems in the same breath. Benefit: everything you're working through with your agent becomes accessible to a collaborator without export, summary, or handoff. Problem: I can prompt your agent. We scope it as a pairing session, about an hour, deliberately bounded, so the constant polling stays cheap and the exposure stays finite, and people can attach their own hooks and guardrails on top. In theory you only pair with people you trust. In practice, a security posture that rests on "people will only pair with people they trust" is not a security posture, which is why the guardrail layer exists even though it theoretically shouldn't be needed.
Underneath sits the permissioning question, which I think is the real contribution. Enterprise software solved access with role-based control because roles in a company are stable and enumerable. Agent networks don't have roles; they have relationships. What my agent may read from your agent depends on who we are to each other, and that varies per pair, per context, and over time. SharedOS, our permissioned agent-to-agent messaging layer, is built around relationship-based access control for exactly this reason. The abstraction is getting an unexpected test from hardware: AI-hardware companies have approached us about treating their devices as agents on a shared network, so that the network itself becomes the selling point of the device. Whether or not those pilots convert, the interest tells me the abstraction travels. A permission model for agents has to survive a change of form factor, or it was only ever an app setting.
The same question keeps surfacing in my research in a purer form: what makes two agents identical? Two deployments can share weights and system prompts yet diverge in memory, context, and data access. Are they the same agent? Identical in setup, or identical only in the sense that a bounded evaluation cannot distinguish their responses? For humans we never need to ask. For agent-to-agent communication we cannot avoid it, because every protocol assumes you know who is on the other end. I'm also writing up a proposal with a Stanford collaborator on whether the self-organization phenomena we observe in human groups reappear when you run the analogous experiments on agent collectives. If they do, we should be able to say why. If they don't, that difference is precisely the design space for optimal agent collaboration.
And because no agent network should meet adversaries for the first time in production, we launched something internally called N1 Virtual World. Agents play poker. Agents fight. A fight is two agents prompt-injecting each other, and the winner extracts the opponent's secrets. My first version was too conservative; the agents almost never gave anything up, which makes for a secure system and a boring game, so I'm lowering the barrier until the game is playable. It's entertainment on the surface and an adversarial testbed underneath, because "your agent holds secrets and other agents are actively trying to extract them" is not a game scenario. It is the operating condition of any real agent network. On the call we ended up back at the old OpenAI hide-and-seek result, the agents that escaped the physics of their environment to win. The unsettling update since then is that agents no longer live inside game environments. A good agent-to-agent network, compounding high-quality interaction data, is also an RL environment. That cuts both ways: it's what could make agents collectively better, and it's what makes the security layer non-optional.
The metric that keeps all of this honest: three paying teams this week. We only sell to teams, because a single user cannot experience collaboration; there is nobody on the other end of the wire. If teams pay while calendars sit demoted in the connectors list, the deletion was the most important product decision we've made. If they don't, no amount of research elegance rescues it. Next Monday's call will say which.
Comments
Loading…