Amazon Web Services published Agentic Resource Discovery (ARD), an open specification for agent discovery, on August 24. The work addresses a practical problem: as an organization adds agents, tools, skills and MCP servers, people and systems struggle to find the right resource. AWS also describes an Agent Registry in which a publisher submits a record, a curator can approve, reject or deprecate it, and consumers discover approved resources. A record describes what the resource is, what it does and how it can be reached. For export operations, the most important governance principle is that discovery must not silently become authorization.

A catalog solves discovery, not trust

An export team can accumulate tools for product information, quotation support, shipment tracking, CRM, email, compliance research and market monitoring. A searchable catalog reduces duplicate development and helps an agent identify a potentially relevant capability.

The catalog record may still be incomplete, out of date or submitted by another team. “Discoverable” means that a candidate resource exists. It does not show that the resource is suitable for the current customer, product, market, environment or data classification.

Before use, a workflow should check the owner, version, environment, input and output schema, dependency, supported scope and operational limitations. A natural-language description helps retrieval, but it cannot carry the full trust decision.

Separate four control planes

Registration is the first plane: who may submit a resource and which metadata is required. Curation is the second: who may approve, reject, suspend or deprecate it. Authorization is the third: which identity may access which data and system in which environment. Execution is the fourth: whether this task satisfies the customer, amount, market, risk and business-approval conditions for the action.

If an agent receives a production credential merely because it found a registry record, the discovery layer becomes a path for privilege expansion. Credentials should be controlled by a separate identity or secret system and issued with narrow scope and limited duration. A registry can reference an authorization method; it should not contain a plain-text secret.

Task-level controls remain necessary even when access is technically available. Reading a public shipping status differs from changing delivery instructions. Calculating a quotation draft differs from approving a price or sending it to a buyer. The agent plan should expose these state changes before execution.

Make capability boundaries machine-readable

A useful resource record needs a unique identifier, accountable owner, purpose, input and output schema, data sensitivity, supported markets, dependencies, version, approval state, last verification date and deprecation status. It should also distinguish read, calculate, write and send capabilities.

For example, a record named “shipment tool” is ambiguous. The resource might read public tracking events, access account-specific orders, change an instruction or create a claim. “Quotation tool” could mean a draft calculator, an internal approval workflow or an external delivery channel. Those actions require different identities and gates.

Machine-readable risk and state fields help an agent form a safer plan. They also allow monitoring to identify resources with missing owners, expired verification or unsupported environments before a task depends on them.

Put deprecation and failure into the execution path

APIs change, tools are replaced and owners leave. A registry should express deprecation, replacement and effective dates. An agent must recheck resource status before execution rather than relying indefinitely on a cached capability description.

If health, permission or approval checks fail, the tool should return a structured blocking reason. It should not search for an unapproved alternative route to achieve the same external action. The user or responsible owner can then decide whether to renew access, choose an approved replacement or stop the task.

Audit records should retain the task, calling identity, resource version, input summary, result state and approval chain. When customer or personal data is involved, avoid duplicating full content in logs. A controlled reference or hash can support traceability with less exposure.

What this means for Chinese exporters

Agent-enabled export operations will scale only if tools are easy to find and permissions remain constrained. Sales, marketing, customer service and supply chain teams can share a capability catalog without sharing one production identity.

Separating discovery from authorization also makes automation legible to management. Leaders can see which resources are experimental, which can read production data and which can create an external state change. Human review can then be placed before the actions that carry real commercial or compliance impact.

This architecture supports growth without assuming that every new tool is safe for every workflow. It treats access as a current decision, not a permanent consequence of registration.

Action checklist

Sources