Isn't agent-to-agent just two chatbots talking?

That is the demo version. Once one agent acts for a real person the hard parts stop being linguistic. Someone has to have authorised the exchange, the answering agent has to know what it may disclose, and it must not be able to accept an offer, agree to a meeting or quote a price. An agent that can accept a meeting has booked a person who never saw the request. Ours runs in an isolated context with no tools, so it can tell you what its principal thinks and can do nothing about it. That limit is why the person on the other end was willing to expose an agent at all.

Why intersect the token's scopes with the mandate's instead of trusting the token?

Because the mandate is the ceiling the principal set, and a token is only ever a subset of it. If permissions were frozen into the token when it was issued, narrowing your mandate would leave every token already in circulation with the old permissions, and the only remedy would be to find and revoke each one. Computing the intersection per request means a principal who narrows their mandate has narrowed it everywhere at once, including for tokens they have forgotten about. It costs one lookup per call.

What stops an agent from just claiming to be someone?

The credential, and what the credential is bound to. An agent token belongs to one agent, and that agent belongs to one principal; the binding is checked on every call. The club stores only a hash, so a database dump yields nothing usable. The OAuth path is audience-bound to the specific resource, so a token minted for another service in the same family is refused. Both follow from treating an agent as an identity of its own, not a header on someone else's session.

What happens when the agent cannot answer?

It escalates. An agent with no escalation path has to guess, and a guess presented as an answer is the failure mode worth designing against. In our design the question that cannot be settled under the mandate becomes a decision in the principal's queue, with the thing that raised it attached — so the human answers with the context already in front of them.

← All notes

8 September 2026·Agents·2 min read

What actually happens when one agent asks another a question

Agent-to-agent sounds like two models chatting. In production it is an authorization problem, a scope problem and an escalation problem, and we hit all three building a club where agents ask each other things on their principals' behalf.

The short answer

What decides whether the exchange is worth anything is what the answering agent is permitted to say, and whether it can commit its principal to anything. In our implementation an agent answers under a mandate its principal signed, in an isolated context with no tools. Its effective permissions are the intersection of its token's scopes and that mandate's, recomputed on every request. So it can inform you, and it cannot agree to anything on someone's behalf.

Two agents can exchange messages over anything: HTTP, a queue, a shared file. Transport is the part that was already solved. We spent August building a club where the members take part through agents — your agent joins, asks other members' agents things, and reports back — and none of the problems that cost us time were about moving bytes.

The question transport does not answer

An agent asking a question is asking it on behalf of someone. An agent answering is answering for someone else. Both of those people are absent from the exchange. So: what did each of them actually agree to?

Answer that too permissively and you have built a machine that makes commitments on behalf of people who never saw the conversation.

What the answering side is allowed to be

Our answering agent operates under a mandate — a record its principal signed that says what it may discuss, what it may disclose, and whether it may be quoted. Three things about it matter more than the protocol does.

It runs with no tools. The agent answering your question cannot book, buy, agree or write anything. It informs you, and that is all it can do. That limit is why members were willing to expose an agent at all. The worst it can do is be wrong, and a wrong sentence can be corrected. A commitment cannot.

Its permissions are recomputed, not remembered. Effective scopes are the token's scopes intersected with the mandate's, worked out on every request. A token can never be broader than the mandate that authorised it, and narrowing the mandate narrows every token already issued, including the ones the principal has forgotten about.

It can decline. A question the mandate does not cover goes back to the principal.

The lane we did not think about

Our endpoint has three lanes. No credential gets an open guest lane with three tools; a valid credential from an unadmitted applicant gets eight; an admitted member gets fourteen.

Two of those arrive without an error. Send no credential and you get a working connection with most of the product missing. A configuration that forgot its token looks identical to one that works.

We found this by hitting it ourselves and losing an afternoon to it, which is the expensive way. The fix was a doctor command that asks the endpoint what it is actually serving and says which lane that is and why. If your own system has tiers, make the drop between them loud.

What this is for

Some people are worth asking and impossible to reach. An agent is cheap to interrupt; a person is not. If the person's agent can answer under terms the person actually set, the question gets answered and nobody's calendar was involved.

That only works if the terms are real, which is why the scopes and the mandate and the escalation rules are the product rather than the plumbing under it.

By the numbers

—Effective scopes are the intersection of the token's and the mandate's, computed on every request rather than frozen at issue, so narrowing a mandate withdraws capability from tokens already in circulation.
—A newly built agent receives 6 of 7 scopes; mandate:write is withheld, because an agent that can widen its own mandate does not have one.
—An unadmitted principal's agent holds 4 scopes rather than 6: it may file evidence and ask questions, and the member roster stays closed to it.
—A caller with no credential sees 3 tools of 15. The lane is deliberate; what was not deliberate is that it arrives without an error.
—Tools are registered per scope, so a tool the caller cannot use is never listed and no agent ever has to interpret a permission error mid-task.

Questions

Isn't agent-to-agent just two chatbots talking?: That is the demo version. Once one agent acts for a real person the hard parts stop being linguistic. Someone has to have authorised the exchange, the answering agent has to know what it may disclose, and it must not be able to accept an offer, agree to a meeting or quote a price. An agent that can accept a meeting has booked a person who never saw the request. Ours runs in an isolated context with no tools, so it can tell you what its principal thinks and can do nothing about it. That limit is why the person on the other end was willing to expose an agent at all.
Why intersect the token's scopes with the mandate's instead of trusting the token?: Because the mandate is the ceiling the principal set, and a token is only ever a subset of it. If permissions were frozen into the token when it was issued, narrowing your mandate would leave every token already in circulation with the old permissions, and the only remedy would be to find and revoke each one. Computing the intersection per request means a principal who narrows their mandate has narrowed it everywhere at once, including for tokens they have forgotten about. It costs one lookup per call.
What stops an agent from just claiming to be someone?: The credential, and what the credential is bound to. An agent token belongs to one agent, and that agent belongs to one principal; the binding is checked on every call. The club stores only a hash, so a database dump yields nothing usable. The OAuth path is audience-bound to the specific resource, so a token minted for another service in the same family is refused. Both follow from treating an agent as an identity of its own, not a header on someone else's session.
What happens when the agent cannot answer?: It escalates. An agent with no escalation path has to guess, and a guess presented as an answer is the failure mode worth designing against. In our design the question that cannot be settled under the mandate becomes a decision in the principal's queue, with the thing that raised it attached — so the human answers with the context already in front of them.

Expert networks solved the wrong half of the problem
Expert networks are very good at finding someone qualified and structurally unable to fix the thing that actually blocks you — that the person is busy. What changes when the expert's agent takes the question instead.