Two bugs in the peer call, both found in review.
message_id was context_id + peer name, so every call in a conversation carried
the same id. A2A wants one id per message; a peer treating the second call as a
replay of the first would have looked like a stale answer rather than a bug.
The peer's context_id was derived from hash(subject_token), which was wrong
twice over. hash() on a str is salted per process, so a restart changed the key
— the reported bug. And a fresh token is minted every turn, so the key changed
every turn anyway, which is worse: the peer started a new thread on each call
and lost anything it had parked, the opposite of what the key exists for. It is
now the conversation id, which is what "one conversation per peer" meant.
Not changed: output_type as a list, also raised in review. OutputSpec is
declared as an item OR a Sequence of them, so a list is the API's own form and
not a union written badly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the last item on this agent's backlog. A reference about to be reordered
is not a reference to discontinue, and the catalog's own quantity field does not
say whether it is — that is the supply agent's decision, and it answers rather
than handing back its stock table.
One narrow tool, not a generic call_agent(name, text): a generic one lets the
model reach any peer with any prompt, which is how an agent becomes a proxy onto
its neighbours. The peer's token is minted per call for that peer alone, so an
injection that talks this agent into consulting the wrong one fails at the
realm.
A peer ending in any state but completed is reported as such, never smoothed
over: a specialist that escalated has not answered, and presenting its
escalation as an answer is how a refusal turns into a fact.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stéphane Tailland