A key design choice in A2A is that agents are opaque: a remote agent exposes its skills and results, but not how it works inside.
Why Opacity
- Intellectual property: businesses can offer agent services without revealing prompts, models or methods.
- Security: internal tools, credentials and data stay private.
- Independence: teams can change their agent's implementation without breaking clients.
- Heterogeneity: agents built on any framework or model can collaborate.
Consequences
- Clients can't see how results were produced, so they must judge quality from outputs and the provider's reputation.
- Debugging across agents relies on logs each side keeps.
- Trust has to come from contracts, certification, track records and testing.
Building Trust Anyway
- Evaluate remote agents on test tasks before relying on them.
- Monitor result quality over time.
- Prefer agents that return evidence, such as sources or confirmation numbers.
- Agree on service levels and data handling with providers.
A Familiar Model
This mirrors how organisations already use external services and APIs: you rely on the interface and agreements, not the provider's internal code.