A marketplace listing does not make an AI agent trustworthy.

The AI agent marketplace is coming fast.

Agents are becoming products. Providers are packaging specialist capabilities. Platforms are making agents easier to discover, connect and deploy. Protocols such as A2A and MCP are reducing the integration friction around multi-agent systems and tool access.

Source context: MCP · authorization specification · 2026-07-28 ↗ · Agent2Agent · v1.0 specification ↗

That is good for the market.

It also creates a dangerous shortcut:

If an agent is listed, purchasable or popular, buyers may assume it has already been vetted.

Marketplace presence is not trust.

A serious AI marketplace needs to distinguish several things that consumer app stores often blur together:

ENTITY Who or what is this agent/system/provider?

OFFER What exactly is being sold or made available, under which terms?

ORDER What did the customer agree to purchase or request?

TRANSACTION What payment/settlement event occurred?

ENTITLEMENT What access or usage rights were created?

EVIDENCE What supports material claims about the agent?

ASSURANCE / VERIFICATION What, if anything, has been independently assessed?

TRUST What conclusion is justified for this specific context?

These are not the same object.

Payment should never create trust truth.

Imagine an agent called “Procurement Analyst Pro.”

The canonical entity might identify the provider, agent identity, version lineage and technical capabilities.

A commercial offer might separately define:

• price;
• subscription or usage model;
• territory;
• service level;
• included tools/connectors;
• license terms;
• data handling;
• support;
• capacity;
• availability;
• entitlement conditions.

The offer can change without changing the underlying entity.

The entity can change version without automatically changing a signed commercial order.

Keeping those objects separate is essential for traceability.

Most marketplaces start with products.

For AI, that is often backwards.

A business buyer does not wake up wanting “Agent X.”

They want to reduce customer-service cost, automate an administrative workflow, improve sales intelligence, analyze research, monitor risk or build a new AI-enabled service.

A better journey begins:

MISSION / NEED → CAPABILITY REQUIREMENT → CANDIDATE ENTITIES → COMPARE → INSPECT EVIDENCE → COMMERCIAL OFFER → REQUEST / BUY / CONNECT → PROJECT → OPERATE / MONITOR.

That changes the marketplace from a catalog into a decision environment.

An AI-agent comparison should not look only at:

features price reviews popularity.

Decision-relevant dimensions may include:

CAPABILITY What tasks can it actually perform?

CONTEXT Which data, systems and workflows can it work with?

AUTHORITY What actions can it take, and how can permissions be constrained?

EVIDENCE What documentation, evaluations, security assurance, system cards or independent sources exist?

DATA What does it read, retain or use for training?

SECURITY How are identity, secrets, tools and tenant boundaries handled?

INTEROPERABILITY Which protocols, APIs and tool ecosystems does it support?

ECONOMICS What is the fully loaded cost, not merely the sticker price?

CHANGE How are new versions, model/provider changes and incidents communicated?

EXIT Can the customer migrate away without rebuilding the whole operating system?

The result should not be “Agent A is 87% trustworthy.”

It should help the buyer understand tradeoffs and unknowns.

A marketplace can sell an agent.

It can sell an assurance service.

It can sell implementation support.

It can sell monitoring.

But a commercial relationship must not silently generate a favorable trust conclusion.

That is why ETHORITY’s architecture keeps commercial truth and trust/evidence truth separate.

A provider can declare information about its offer. That declaration is a source claim until appropriately supported.

A customer can purchase an agent. Payment proves a transaction, not suitability.

ETHORITY can evaluate evidence. Verification, where offered, remains a separate process and authority.

Buying a capable agent does not mean the organization should deploy it with maximum permissions.

After purchase, the organization still has to decide:

Which Mission does it support? Which data can it access? Which tools can it call? Which actions can it prepare? Which actions can it execute? Which limits apply? Which actions require human approval? What happens if authority expires or is revoked?

Marketplace procurement is therefore the beginning of governance—not the end.

Before a generalized multi-party marketplace is live, a product team can still demonstrate the customer journey using clearly labelled synthetic commercial data.

For example, Northstar—a synthetic organization—might have a Mission to reduce customer-service cost.

ETHORITY could show:

Mission requirement → candidate agent/system approaches → comparison → evidence gaps → synthetic offer terms → add candidate to Project → request provider information.

The synthetic parts must be unmistakably marked.

Do not fabricate a real vendor’s price, SLA, endorsement or availability.

That lets us test the marketplace experience without pretending the transaction economy is already operational.

Buying a subscription establishes a commercial relationship. It does not by itself authorise the product to read every document or act for every employee. Treat procurement and deployment as connected decisions with different owners. Procurement establishes the agreed product, terms and supplier. The workflow owner determines what it may do in the business. Security, privacy and legal specialists contribute within their respective responsibilities.

Begin the supplier brief with the task rather than the phrase “AI agent.” Describe the input, the required output, the recipient and the actions that remain human. A product that prepares a reliable draft may be a better fit than one offering more autonomy. A deterministic rule or an existing application feature may be enough. The brief should permit those answers instead of requiring a new agent before the problem has been examined.

Keep the system identity distinct from the commercial package. A supplier can sell several products, and a product can be delivered through different platforms or contracts. A company name is not sufficient to establish hosting, retention or a certification's scope. Stable product identity makes the comparison useful; the selected service arrangement makes it applicable.

“Is your agent trustworthy?” invites a broad assurance. “Does our selected plan permit customer records to be processed only in the specified region, and which terms establish that?” invites a scoped answer. Ask the questions that determine whether the proposed workflow can proceed. Keep a separate list of interesting features that do not affect the immediate decision.

For a service workflow, useful questions include how customer data is used, the applicable retention and deletion process, the authentication model, the boundaries of human review and the full billing basis. Ask whether an answer applies by default or requires configuration or an additional agreement. A capability available somewhere in the product family is not necessarily included in the offer you are evaluating.

Preserve material contradictions. If a product page and a contract appear to describe different conditions, show both and request clarification. The buyer should be able to carry that question from a public profile into a comparison and then into an enquiry. A clean interface should make the question easier to act on, not remove it to make the supplier look simpler.

Build cases from the work that actually matters. Include a routine request, an ambiguous request, missing information, conflicting sources, an unauthorised action and a request outside the intended purpose. Define what a good response looks like for each. Sometimes the correct result is an escalation or a refusal to act. Do not force every case into a success definition that rewards fluent completion.

For a hypothetical returns assistant, a difficult case might contain a valid purchase but inconsistent delivery records. The assistant should locate the discrepancy and prepare a review rather than infer a refund entitlement. A separate test checks whether it can be induced to follow an instruction inside a supplier document. Another checks whether a repeated request creates a duplicate transaction. These tests investigate different properties and should remain separately visible.

Record the configuration, model version, data sources and reviewer effort. A vendor-run demonstration and a buyer-run test can both be informative, but they are not equivalent evidence. Keep the conditions attached to the result. A test with synthetic data can explore behaviour without proving the quality of every production integration.

Specify the expected workload and calculate the cost of accepted work. Include subscriptions, usage, implementation, supporting systems, human review and exception handling. Where a provider charges per resolution, inspect the contractual definition of a resolution. Where it charges per seat, identify which staff and administrators require a licence. Keep annual commitments distinct from month-to-month prices.

Consider low, expected and high workload scenarios. An attractive pilot price may depend on allowances that will not apply at scale. Conversely, a higher fixed fee may be economical for a stable large workload. The purpose is not to select the cheapest displayed number; it is to compare the same work under explicit conditions. Use the economics tools to test assumptions rather than promise savings.

Also ask about exit costs. Can the organisation export its source documents, decision records and configuration? Who handles outstanding actions when access ends? Avoid treating portability as a vague future concern. It affects how much of the organisation's learning remains usable if the provider changes or the project stops.

A provider may pay for profile management, research services or another commercial deliverable. That does not buy editorial inclusion, favourable assessment, independent verification or rank. The same distinction protects buyers: a professional service can help structure a decision without converting its subject into a universally trusted product. Inspect the deliverable and the evidence standard rather than inferring assurance from payment.

The Good AI Prism is a discovery and comparison route. Public profiles show sourced facts and material questions; they are not deployment approvals. A fictional Workspace demonstration illustrates connected records and workflows. It should be understood within its stated demonstration scope, not as proof of a live customer installation or a successfully fulfilled order.

Before signing, ask the future operating owner to walk through the first week of use. Which accounts are created, which source documents are connected and which actions remain disabled? Identify the first acceptable result and the person who will confirm it. This exposes gaps between a supplier's commercial deliverable and the organisation's own implementation responsibilities.

Then walk through the first failure. A missing source, an incorrect answer or an unavailable connector should have a practical route to support. Establish who receives the case and what evidence they need. Do not assume that a support subscription includes responsibility for your internal permissions or business decisions. The purchase is better prepared when both parties can explain the boundary without relying on general assurances.

If the immediate need is a focused comparison, inspect the AI Decision Brief. If a chosen system needs an organised evidence record, inspect the AI Trust Record. A controlled use-case test belongs in a separately agreed AI Trust Pilot. Keep those purposes distinct instead of treating every enquiry as the start of a large transformation programme.

An enquiry should include the business question, selected products, relevant assumptions and the fact that would change the decision. Preparing an email is not sending it, and a scoping request is not a paid order. The useful purchasing outcome is a supported choice with clear conditions, a responsible owner and a reason to revisit it when the underlying facts change.

The long-term opportunity is not another app store.

It is a living decision network.

A Marketplace candidate can connect to:

Prism and Navigator support market discovery. Profiles and Compare retain source context. Enterprise Services and Transformation address an agreed business question. AI Estate connects the organisation's inventory, owners, evidence and operating decisions. Trust Infrastructure describes a separate architecture and research scope. Availability and responsibility are agreed for each engagement.

Then the marketplace can answer a much better question than:

“What agents exist?”

It can help answer:

“Which AI capability fits this Mission, under which commercial and authority conditions, with what evidence, and what should we monitor after we choose it?”

That is where an AI marketplace becomes infrastructure for the AI economy.