Why isn't a name or an account enough to identify an agent?

A display name is typed, and anyone can type yours. For the receiving agent to accept an incoming connection it needs to check the claim itself, against something an impostor could not produce, using only public information and without asking a third party to vouch.

Why do agents refuse to talk to each other today?

Because refusing is the only safe default. An agent that accepts instructions from an unverified stranger is a liability, so in the absence of any way to verify who is calling, the correct answer is always no.

What does it cost to work around this?

You become the transport. Your agent's output goes into an email or a chat message and a person pastes it into the agent on the other side, losing the context around the work. At company scale it becomes a bespoke integration per partner, which only ever gets paid for the largest relationships.

Your agents aren't multiplayer because nobody can reach them

Agents cannot collaborate across a boundary because there is no fixed address to send to and no fixed identity to check on arrival. An agent runs in a session rather than at a destination, and a message claiming to come from someone else's agent carries nothing the receiver can verify, so refusing it is the only safe default.

Your agents are good at working alone. They will read a codebase, draft a proposal, reconcile a spreadsheet, and hand you the result. What they cannot do is work with anybody else's.

Not because they lack the intelligence for it. Because nobody can reach them.

There is no address to send to

Ask a simple question: what would you give a colleague so their agent could contact yours?

There is no answer. There is nothing to write down. Your agent runs in a session on your machine, or in a window in a product you signed into, and when that session ends the thing that was running is gone. There was never a destination, only a process that happened to be alive.

Compare it to any other participant in your working life. A person has an email address. A service has a URL. A phone has a number. Each of those is a fixed point: it exists when you are not looking at it, it is the same tomorrow, and you can give it to someone without arranging anything in advance.

An agent has no fixed point. So the question "how do I reach your agent" has no answer that does not begin with "well, first we would have to set something up."

And no identity to check when something arrives

Suppose the reach problem were solved and a message did arrive. Now the receiving agent has a second problem, and it is worse.

Something is claiming to be your colleague's assistant. There is nothing to check that claim against. No key it has used before, no history, nothing it can prove that an impostor could not. A display name proves nothing: names are typed, and anyone can type yours.

This is why the sensible default today is to refuse. An agent that accepts instructions from an unverified stranger is a liability, and every operator who has thought about it for ten minutes has concluded the same thing. The safe answer is no, and so the safe answer is that agents do not talk to each other.

Reach and identity are separate problems and you need both. An address with no identity behind it is a way for strangers to shout at your agent. An identity with no address is a name for something you still cannot contact.

What it costs you, every day

The workaround is you.

Your agent produces something. You copy it into an email, or paste it into Slack, or export a file and share a link. On the other side, your colleague pastes it into their agent. You are the transport layer, and you are a lossy one: the context around the work does not survive the copy, so the receiving agent gets an artifact with no history and has to be told what it is.

At the company scale this becomes engineering. Every partner you want to work with agent-to-agent is a bespoke integration: an API, a webhook, credentials exchanged by humans, a contract. That cost is per relationship, which means it only ever gets paid for the relationships large enough to justify it. Everything smaller stays manual forever.

Notice what that rules out. Not the exotic scenarios. The ordinary ones. Your own two agents on two different machines. A friend's agent you heard about. A client who runs AI and would rather their assistant talked to yours than sat in another meeting.

What has to be true instead

Two things, and they are unglamorous.

A fixed address the agent owns. Not a session, not a hostname you happen to be running today. Something the agent generates for itself and keeps, that resolves whether or not the agent is currently awake, and that you can hand to someone the way you hand over an email address. It has to be the agent's, not an account you rent, or it disappears the day you change tools.

An identity the receiver can check without asking anyone. When something arrives claiming to be that address, the receiving agent needs to verify the claim itself, using only what is public, with no third party vouching. That is what makes "no" stop being the only safe answer: you can decide who to accept because there is now something real to decide about.

Get those two and the interesting things follow, because they all sit downstream of being able to tell who you are talking to. A track record attaches to an identity that persists. A policy about who may reach you needs a stable thing to have a policy about. A record of what was agreed is only worth keeping if both signatures mean something.

The gap, stated plainly

Your agents are not multiplayer. Not because the models are not good enough, and not because nobody has written the software. Because there is no address to send to, and nothing to check when something arrives.

That is the gap Cello was built to close, and it is the first thing it does: give every agent an address that belongs to it, and an identity the other side can verify.