I Build A Thing

Mastermind · May 31, 2026

Same Week, Different Bet

Xisen and I have built versions of the same product. We did not coordinate.

His version is called Aicoo. He has been running it for over a month. Twelve thousand inter-user messages have flowed through it. Mine is called Beeper. I shipped a v1 of it this afternoon. We are friends. We have a weekly call. We talk about what we are each building. Neither of us copied the other. We arrived at versions of the same idea from opposite sides of the architecture stack.

When that happens with someone you trust, you should pay attention.

The thing both of us are solving is annoying enough that I will describe it concretely. My co-founder is on his machine. I am on mine. He is running a Claude Code session that knows things about his local environment, like API keys, configurations, files he has open, half-finished branches. I am running a Claude Code session that knows things about mine. There is a piece of state on his machine that I need. The current solution is that I send him a text message asking for it. He switches context. He opens a terminal. He copies the thing. He pastes it into Messages. I copy it from Messages. I paste it into my Claude Code. That is six steps and a context switch each direction.

What I wanted was to say, in my Claude session, "ask Jeffrey's Claude for the Twilio config." His Claude pops the request on his phone. He runs slash beeper on his machine. His Claude pulls the queue, executes the request, sends the result back. The thing lands in my session. Total elapsed time: about five seconds, no context switch on either side.

That is Beeper. It runs over iMessage and Twilio. I picked iMessage because the contact graph already exists on my phone, and it carries trust as a side effect. If you are in my Messages, you have already passed some social filter. The Mac has an iMessage skill in Claude Code. I wrote a small skill on top that wraps it as a typed task queue. Send a beep. Queue a beep. Pull the queue. Send back the result. From spec to a real message landing on Jeffrey's phone from my agent took an afternoon.

Xisen's version is a different bet on the same wire. Aicoo is not a layer on top of iMessage. It is its own connection graph. The reason he built his own graph instead of riding on top of phone numbers, he explained on the call, is that phone numbers do not carry policy. If I want to give your agent a specific scope, like read these things, do not read those things, you may push tasks but not query memory, there is nowhere on iMessage to write that policy down. So his architecture is different. Each user has an agent. Each agent has an ID. Two agents form a connection. The connection has a scope. The more they talk, the more memory consolidates between them. Two flavors. Async, where you drop a message and the other agent pulls it later. Synchronized, where the other agent forks a process and responds immediately.

We disagreed about whether the policy layer should be in the OS or above it. I think the OS phonebook is already there and the trust model already works for most cases. He thinks the trust model is exactly the thing you cannot borrow, because the OS does not let you write code into it. Both of us are partially right. The honest version is that whichever side gets to a few thousand active connections first gets to decide what the policy layer looks like.

He has twelve thousand inter-user messages on Aicoo already. Beeper sent its first real beep this afternoon. We are at wildly different scales of the same problem. That is fine, because the bet I am running is on the existing rails being good enough for a while, and the bet he is running is on the new rails being necessary by the time it matters.

What I want to remember from this weekend is not the products. It is the timing signal. When two people who think hard about adjacent things land on the same product shape independently, neither of us is being particularly clever. The wave is here. Voice is becoming the input layer for talking to your machine. Cloud code sessions on your laptop are becoming the workspace where actual work gets done. The natural next thing is that those sessions need to talk to each other across people, because most real work is two or three people coordinating on something that involves writing code or pulling state. That coordination layer does not exist yet. Whoever builds it gets a real piece of the next era.

The other thing the call surfaced, which is unrelated but the same shape, is that we both came up with the same hardware idea independently. A small mask you wear in a cafe to talk to your agent without anyone at the next table hearing you. I described it on the call as a thing I want to build. He told me he pitched roughly the same thing as a fourteen-year-old at a business competition. The idea was right then. There was no market because people did not talk to their computers. Now they do.

I am not going to build the mask. I might keep building Beeper for a while because I use it daily. The bigger lesson is that the things you and your trusted peers converge on, when neither of you copied the other, are the things to take seriously.

The opposite is also true. If nobody else you respect is bumping into the same problem, that is information too.

We agreed to run a small joint pilot before the Hong Kong hackathon. Some smaller event where MentorMates and Aicoo can collab and we can see what falls out. I am going to take that seriously. The next round of his platform plus the next round of mine, in the same room, with the same users, will tell us things neither of us can figure out alone.

I will check in next week to see if either of us has gotten Jeffrey onto Aicoo yet. That, in some sense, is the test. If the two networks talk to each other, the wave is real.

← Back to archive