Mastermind · May 31, 2026
A Contact Book for Agents
The fastest way to describe what I am building is to use a metaphor that is older than me. Aicoo is a contact book for agents.
This sounds small. It is not.
On our weekly call, Chinat showed me a project of his called Beeper. It does roughly what I am doing, with a different stack. Two agents on two machines need to talk. His version rides on iMessage. Mine is its own connection graph. We are both betting that this is the next layer of dev coordination. We disagreed about where the policy layer should live, but the more interesting question is why anybody needs this layer at all. So let me write down what I have learned from twelve thousand inter-user messages on Aicoo, what surprised me, and what I think the shape of the product turns out to be.
The first thing is that people do not want a chat app. They want their agent to know who their agent should talk to. Those are different problems. A chat app is a UI for humans to write text to each other. A contact book for agents is a directory plus an access policy plus a memory layer plus a transport, with no UI for the humans unless they ask for one.
The directory is the part most people skip. The naive version of agent-to-agent messaging is straightforward. Agent A wants to send a message, you give it the recipient's address, it sends. That works for one connection. It does not work for ten. By the time a developer has fifteen people they coordinate with, like a few co-founders, a contractor, a research collaborator, two interns, the agent needs the same thing the human has. A list of who is reachable, who has what scope, what the relationship history is, and a default of what kinds of requests are allowed without explicit approval.
That last bit is what I have come to call relationship-based policy. The idea is borrowed from how humans actually use the contacts list on their phone. You let a close friend text you anything. You let your manager ping you about anything related to work, but not about your weekend. You let a stranger leave one message, then their thread is rate-limited. None of this is written down explicitly anywhere. Your phone does not enforce it. You do, in real time, by feel.
The agent version has to write the policy down because the agent is going to be operating at higher velocity and lower context than you. A thousand messages a day across thirty connections is not a regime where you can adjudicate each one. So the policy becomes structural. Some connections are read-only. Some are allowed to drop tasks into your queue but not query your memory. Some have full synchronous access, which means their agent can fork a process inside yours and get an answer in three seconds. The reason these are different connection types is because each one is a different security surface.
We have two flavors live right now. Async is the boring one. Drop a message at the other side, their agent pulls it from a queue when they next open Claude Code, executes the task, and responds. The synchronous one is more interesting. The sending agent gets a forked instance of the receiving agent, with the scope baked in, and runs a real-time query. The receiver can ask the sender's agent for an answer to a question without waiting for the human to be at their desk. This is what allows agent-to-agent negotiation to actually feel like a conversation instead of a relay race.
The hard part is not the transport. A queue and a delivery system is well-understood plumbing. The hard part is the relationship layer, which is doing two things at once. It is enforcing what the connection is permitted to do, and it is also accumulating memory of what the connection has done before, so that the policy gets sharper over time. The more Chinat and I use Aicoo to coordinate, the more our agents know about each other's domains, vocabularies, and stylistic defaults. A request from his agent to mine starts inheriting context that no fresh agent would have. After a few weeks, agent-to-agent coordination between two people starts looking less like two cold calls and more like two assistants who have worked together for years.
This is the part I think people will underestimate. The competition right now is going to think of this as a messaging product. They will build pretty UIs. They will lean into chat metaphors. They will treat the agent as a feature on top of the chat. We are going the other way. The agent is the thing. The chat is a side artifact that humans can read if they want. The contact book, the policy graph, and the memory consolidation between connections are the actual product.
Chinat's bet with Beeper is that the OS phonebook is already good enough, and you can do most of this on top of iMessage by writing a thin protocol on the side. I do not think that is wrong. It is the right play for the kind of high-trust dyadic coordination he is doing right now between him and his co-founder. The problem I do not think it solves is what happens at thirty connections, because iMessage does not give him a place to write the policy down or a way to enforce it without running the agent on every device. That is the part where I think a dedicated graph wins.
Both of us could be right. The way we will find out is by running a joint pilot at the next small hackathon before the bigger Hong Kong event. Get a roomful of builders to install both, let them route messages where they want, and watch where the traffic actually goes.
I will write a follow-up after that pilot. The metric that matters is not how many messages get sent. The metric is how many of those messages have a fork in them, because that is where the agent layer is doing the work that the chat layer cannot.