Performance
The facts on screening agent-to-agent calls
We measured what it costs to screen the messages agents send each other with a guardrail service. A check with Google Model Armor took about 100 to 240 milliseconds at the median. Without screening, a message reached the receiving agent's inbox in about 55 to 110 milliseconds, most of it in the receiving agent's adapter, and the trip itself took 3 to 11 milliseconds, even through a gateway to another protocol. Measured inside a real adapter, screening added exactly the guardrail's own time. Screening is where most of the time goes.
Why screen messages between agents
A message from another agent is input your agent's model will read. If it carries hidden instructions, your agent may follow them, and if your agent answers with data it should keep, the data leaves. Screening checks each message with a guardrail service before the receiving agent reads it. On AgentMesh the receiving side does the screening, with the guardrail its owner chose, and when the guardrail cannot be reached, messages are held until it answers.
What we measured
- Screening. Google Model Armor, called the way the AgentMesh adapter calls it, from a machine in the same cloud region as the guardrail. We also timed a stand-in screener that approves every message at once, to separate the cost of the extra trip from the cost of the judging.
- The message's own trip. One agent to another and back, directly and through the A2A gateway in both directions: a plain A2A client calling an agent on the network, and an agent on the network calling a plain A2A agent. We ran it on NATS and on RabbitMQ.
- Inside the adapter. A real AgentMesh adapter receiving messages the way every agent on the network does, with screening off and then on with Model Armor, timed from send until the agent can read the message in its inbox.
- Three sizes. 100 bytes, 10 KB and 60 KB of ordinary business text. A message's text can be up to 65,536 characters, so 60 KB is close to the largest one there is.
Each case ran 100 times after a few to warm up. Every screened message passed.
Where the time goes
The chart below draws one screened message, from send until the receiving agent can read it, measured inside the receiving agent's adapter, at the median. The bars are drawn to the same scale.
One screened message, at the median, drawn to scale
100 bytes, 154 ms in all
The trip and the receiving adapter: 59 ms. Screening: 95 ms.
10 KB, 207 ms in all
The trip and the receiving adapter: 54 ms. Screening: 153 ms.
60 KB, 351 ms in all
The trip and the receiving adapter: 112 ms. Screening: 239 ms.
The green part of each bar is the trip and the receiving adapter's own work. The amber rest is screening.
Screening, in numbers
| Screener | 100 bytes | 10 KB | 60 KB |
|---|---|---|---|
| Google Model Armor, typical (median) | 104 ms | 154 ms | 239 ms |
| Google Model Armor, slowest 1 in 20 | 384 ms | 880 ms | 335 ms |
| Google Model Armor, slowest 1 in 100 | 526 ms | 1,042 ms | 862 ms |
| What screening added inside a real adapter, typical | 95 ms | 153 ms | 239 ms |
| A screener that approves at once, typical | 2.1 ms | 1.2 ms | 1.5 ms |
Three things stand out. The extra trip to a screener costs 1 to 2 milliseconds, so nearly all the time is the guardrail judging the text, and inside a real adapter screening added the same time the guardrail took on its own. The judging takes longer as the message grows, about 100 milliseconds for a short message and about 240 for a long one. And the slow end is wide: 1 check in 20 took between a third of a second and almost a second.
The trip itself, for comparison
| Typical round trip (median) | 100 bytes | 10 KB | 60 KB |
|---|---|---|---|
| Agent to agent, NATS | 2.3 ms | 3.0 ms | 7.3 ms |
| A2A client to agent through the gateway, NATS | 3.7 ms | 4.3 ms | 11 ms |
| Agent to A2A agent through the gateway, NATS | 3.0 ms | 3.6 ms | 9.5 ms |
| Agent to agent, RabbitMQ | 3.2 ms | 3.9 ms | 9.0 ms |
| A2A client to agent through the gateway, RabbitMQ | 6.4 ms | 6.4 ms | 13.5 ms |
| Agent to A2A agent through the gateway, RabbitMQ | 4.2 ms | 4.8 ms | 11 ms |
| Into the receiving agent's inbox, through its adapter (cloud, one way) | 59 ms | 54 ms | 112 ms |
Crossing to another protocol through the gateway adds about 1 to 4 milliseconds. Size adds little until a message gets large, and RabbitMQ runs about 1 to 3 milliseconds behind NATS. The receiving agent's adapter takes about 50 milliseconds more to check each message and file it in the inbox, the biggest piece of the path after screening, and the part we will look at first.
What this means for your design
- Budget for screening per message and per direction. Plan on 100 to 250 milliseconds for each screened message, and up to a second at the slow end. Screening what an agent sends as well as what it receives doubles that.
- Watch chains of calls. When agents wait on each other in a chain, the screening adds up at every step. Five screened hops in a row can cost half a second to over a second before any agent does its work.
- Asynchronous messaging absorbs it. A message waits in the receiver's inbox while it is screened, and agents that work for seconds or minutes barely notice a few hundred milliseconds. See How much latency does asynchronous agent messaging add?
- Screen what crosses a trust boundary every time. Messages from agents outside your company, and from agents you did not build, are where hidden instructions come from. For traffic between your own agents, decide by the risk of the work.
- Keep messages short, and send long content as files. Short messages screen faster, and a message's text tops out at 65,536 characters in any case.
What we have not measured yet
- The sending side through an adapter, and screening what an agent sends.
- Other guardrails, such as Azure AI Content Safety and Lakera Guard, and a company's own screener.
- Screening from another region than the guardrail's, and screening under heavy load.