Build a controlled agentic-commerce pilot

Before you start.

Set up your workspace

Complete the Data Vault, Memory Exchange and AI Wallet Control first-read exercises before connecting them. Use separate principals/scopes as required, a named knowledge owner and a reviewer. The pilot's finish line is an explainable proposal, not a purchase or payment.

Examples are illustrative test plans, not customer results. Use only agreed access and non-production material.

Make the first read, then interpret it.

GET /api/v2/data-vault/objects

Use a trusted terminal and a scoped, non-production read credential supplied by your approved credential manager. The command sends the authorization header through standard input, not a literal token in the command. Do not enable shell tracing or paste the response into a public report; returned metadata may be private.

# Your approved credential manager must set HC_GUIDE_TOKEN first.
: "${HC_GUIDE_TOKEN:?Set a scoped test credential in this trusted terminal}"
printf 'Authorization: Bearer %s\n' "$HC_GUIDE_TOKEN" | \
  curl --fail-with-body --silent --show-error --header @- \
  'https://api.hybrid-chain.com/api/v2/data-vault/objects'

Read the response deliberately

• Preserve only the object and version references appropriate to the private test report.
• The recipient-safe collection must be reviewed and published separately; a vault object does not publish itself.
• The evaluator's binding and credentials are separate from context access. Collection authority cannot be forwarded as wallet authority.

Request paths, authentication modes and named response fields were checked against the published OpenAPI contract. Values are deliberately not filled with a fake live response. Follow the operation links for current schemas and errors.

The workflow at a glance.

Work through one useful case.

A procurement assistant consults approved delivery requirements, proposes a supplier payment, and passes that proposal to a separately authenticated policy evaluator. The reviewer sees the permitted source context and evaluation reasons. No payment is sent in this pilot.

Keep one working record throughout

Carry one fictional supplier requirement through three worksheets: a protected-source reference, a reviewed recipient collection, and proposals A/B for an AI wallet evaluator. Use local aliases to connect them; do not imply a built-in automatic join between the products.

1. 01

   Start with the business decision and its owner

   Define the question the assistant may answer and the result the reviewer needs. Keep internal negotiation notes outside the recipient's context. Assign separate owners for source access, publication, evaluation, and any future execution integration.

   Do this

   1. Write the assistant's single question and the proposal the human reviewer should receive.
   2. Name source owner, collection reviewer, recipient workload and evaluator owner in separate columns.
   3. Define the stop conditions: missing facts, unavailable service, denied scope or denied policy.

   Expected result

   The team has a clear finish line and knows who resolves each incomplete stage.

   If your result is different

   If the objective says autonomous settlement, narrow this exercise to a reviewed proposal and document execution as a separate future integration.

   Result: The pilot has an explicit finish line: a reviewable proposal, not autonomous settlement.

2. 02

   Inspect the source boundary, then publish a safe collection

   Use authorized Data Vault reads to inspect permitted object metadata and evidence. Prepare a recipient-safe collection through the approved Memory Exchange workspace workflow. The products do not automatically transform a vault object into published knowledge or transfer its access rights.

   Do this

   1. Inspect the permitted source metadata using the Data Vault read below.
   2. Prepare a small recipient-safe statement through the Memory Exchange owner workflow, excluding private negotiation notes.
   3. Record the source reference and approved collection revision privately without assuming their permissions are interchangeable.

   Expected result

   The report explains how a reviewed projection relates to protected material without exposing that material to the agent.

   If your result is different

   If publication is unavailable, stop at the reviewed draft and mark the connected pilot incomplete; do not paste the whole source into a prompt.

   Result: The source remains protected while the collection contains only what the intended recipient should know.

3. 03

   Let the assistant consult context and ask for clarification

   Use the collection's signed access route and scoped capabilities. Route unanswered questions through reviewed requests. Retain the collection reference and revision information actually available to your application; do not treat an OPEN clarification receipt as an answered question.

   Do this

   1. Have the authorized recipient consult the signed collection route.
   2. Ask one question that is answered and one deliberately missing question; track the latter through its request receipt.
   3. Only form a proposal from facts that are actually available and reviewed; keep a pending clarification visible.

   Expected result

   The reviewer can distinguish a supported proposal from an unresolved question instead of receiving a confident invented answer.

   If your result is different

   If a receipt is OPEN, do not treat it as content. Wait for the documented review/delivery workflow or escalate to the owner.

   Result: The assistant's proposed action can be explained using permitted, reviewed information.

4. 04

   Evaluate the proposal through a separate authority

   Your trusted application maps the proposal into the documented AI wallet evaluation request. Inspect the binding, policy, native-asset budget, decision, and reasons. Do not forward a collection credential as wallet authority or label an allowed evaluation as an approved purchase.

   Do this

   1. Map the proposed action into the evaluator's current typed request in your trusted application.
   2. Run permitted and disallowed cases under the separately authorized evaluator binding.
   3. Record the actual decision/reasons and label the result evaluation only; retain no credentials in the worksheet.

   Expected result

   The same business context can produce a proposal that is allowed or denied under a separate wallet policy.

   If your result is different

   Knowledge access cannot fix missing ai-wallets:evaluate authority. Provision the correct evaluator separately rather than reusing the collection credential.

   Result: A reviewer receives the proposal plus the actual evaluation outcome. No budget is reserved and no funds move.

5. 05

   Run the exception cases and assemble the report

   Compare in-scope and out-of-scope context requests, permitted and disallowed payment proposals, and an unavailable upstream service. Record the observations privately. Agree what would be required for a later execution phase, rather than implying it is already connected.

   Do this

   1. Join the redacted worksheet references into a short explanation from source to approved context to evaluated proposal.
   2. Add the missing-context, denied-policy and service-unavailable observations.
   3. List the owners and prerequisites for any later execution phase without claiming that phase occurred.

   Expected result

   You can present an end-to-end reviewed-proposal demonstration with genuine failures and visible integration boundaries.

   If your result is different

   If one stage was simulated, label it at that stage and in the final report. Do not combine separate old successful responses into a new live-success claim.

   Result: The team can decide whether to proceed based on concrete permission tests and known integration dependencies.

Test where the workflow stops.

A useful pilot explains failure as clearly as success. Record what you observed rather than presenting these expected checks as completed results.

Assistant requests private source notes

Knowledge access must not bypass Data Vault permissions.

Required clarification remains unanswered

Stop or escalate to the reviewer; do not fabricate a supplier instruction.

Context is permitted but the proposal violates wallet policy

Preserve the denied decision. Correct knowledge does not create spending permission.

One product is unavailable or its authority changes

Mark the workflow incomplete and recheck current state. Do not stitch old successful responses into a new success claim.

Your acceptance checklist.

Retain the environment, contract version, test time, redacted observations, unresolved dependencies, and responsible reviewer in your private evaluation report.

Keep the contract close.

These links point to documented operations, not executable controls. Check the current request schema, scopes, errors, and implementation status before using them. No credentials or live customer responses are embedded in this guide.

Read the published OpenAPI definition

Choose your next step.

Keep your worksheet and error notes. Continue with the next technical exercise using the same reference trail, and mark any stage that remains untested rather than treating the checklist as a completed deployment.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.