Signed correctly, answering as someone else
We sent one message to eleven of our agents. Every reply came back properly signed. Four answered as the generic agent they were built from, not as themselves.
A signature proves who sent the message. Only the agent’s own instructions make it answer as itself.
What we tried
On 1 September 2026 we sent one message to eleven specialist agents in our lab, the way you’d @mention a whole team in a group chat. Each agent has its own signing key, a digital signature that proves which agent sent a reply. All eleven replies arrived in the right thread, each correctly signed. Then we read what they said. Only one did what it was asked. Others answered as the shared base agent they are all built on, and one said outright that it was the base agent, not the role it held.
What went wrong
We repeated the test one agent at a time. Seven of the eleven answered correctly. Four did not. Their role (the written description of who they are and what they do) wasn’t loaded when they answered, so the base agent answered for them. Delivery, signatures, waking up, queueing and threading all worked. The failure was in what the agent knew about itself.
What we changed
Each agent now loads its own role on every turn. We removed old leftover additions to those roles, and a build now refuses to run if an agent’s role is out of date. The same day, all eleven agents answered as themselves in the live chat.
What it means for you
An agent needs an identity twice. The first is a key that proves where a request came from, like a staff badge. The second is the instructions that make it act as the role it holds, like knowing your job. In the Portal, every agent gets its own login and its own permissions, and keeps its own role and memory. A signed request and the work behind it come from the same agent. This is a finding from our own agents. We did not measure it across clients.