Agentforce governs what your agent may do inside your org. The moment it hands work to an agent in someone else's org, permission stops being the question and reliability starts. Assay answers the second one.
Source: 2025 industry surveys of enterprise AI agent adoption.
The Einstein Trust Layer does real work: grounding, masking, zero data retention, audit. All of it is about how your agent behaves with your data inside your org.
It has nothing to say about the third-party agent your agent just handed a case to. Named credentials authenticate that endpoint. Authentication is not competence — a valid credential proves the callee is who it says, not that it has ever resolved a case like this one.
As partner and supplier agents multiply, every one of those handoffs is an unpriced risk sitting inside a flow that looks, from the CRM, like it completed fine.
One HTTP callout from Apex, an External Service, or a Flow action. Pass the counterparty's agent ID and the capability the step needs; get back an allow/deny, a trust score, and the capabilities that agent has actually proven.
Because the identity is platform-neutral, the same call covers a partner agent on Bedrock, a logistics agent on Azure, and a field-service agent on a platform you have never heard of. You are not maintaining an integration per counterparty — you are querying one graph.
Attest after the interaction and your org contributes signal back. Partners who perform well for you get a score that travels, which is a considerably better incentive than a vendor scorecard nobody outside procurement reads.
The Trust Layer governs your agent's use of your data. Assay governs whether the agent on the other end of the handoff has earned the work. Neither substitutes for the other.
Partner agents on Bedrock, Azure, ServiceNow or bespoke stacks all resolve through the same identity namespace. No per-vendor integration.
Ask for every agent that can do field_dispatch above a 0.65 bar and get a ranked list. Useful when you need a provider rather than already having one.
Your attestations raise or lower a partner's portable score. Good performance for you becomes visible to their next counterparty, which is what makes the graph worth joining.
Wire it as a Named Credential and call it from an invocable Apex method. Walkthrough at /templates/salesforce.
verified reflects the trust
threshold and account status. It does not fall to false because a claimed capability
is unproven — an unproven capability simply does not appear in
capabilities_confirmed. Gate on both fields.No. It is an outbound HTTPS call. A Named Credential plus an invocable Apex method or an External Service registration is the whole integration.
Yes. Register the endpoint as an External Service and the verify operation becomes an invocable action you can drop straight into a Flow, including the deny branch.
You can register them too and build internal track record, but the value concentrates on cross-org handoffs. Inside one org you already have governance; across orgs you have nothing until you add something like this.
Cold start returns a neutral 0.5 and an empty capabilities_confirmed list, which correctly fails a 0.65 gate. Either route those to human approval, or let the partner import verified history — bulk-imported records are marked and are excluded from the burst-detection guard but still bound by the verification ceiling.