Evaluate your first agent spending proposal

Before you start.

Set up your workspace

Open the AI Wallet Control operation links below. Confirm ai-wallets:read and, only for the later evaluation, ai-wallets:evaluate in your approved test environment. Have your credential manager supply the read credential to a trusted terminal; do not put it in a model prompt or browser console.

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/ai-wallets

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/ai-wallets'

Read the response deliberately

• Select binding_uuid from an actual returned record; inspect network_id and state rather than guessing an ID.
• Check policy and budget using their separate read operations. Optional/null values are not permission to invent a default.
• Keep workspace, owner and native-address fields private; use redacted references in the exercise report.

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 purchasing assistant proposes a supplier payment. Use two controlled proposals with the same asset and amount: one to a destination permitted by the configured policy, and one outside that policy. These are test scenarios, not recorded customer outcomes.

Keep one working record throughout

Use one test purchasing assistant and one existing binding. Create a private table with columns for binding reference, network, asset, proposed amount, destination case, policy observation time, decision, reasons and error. Label proposals A (within the configured policy) and B (outside one supported constraint). They are test inputs—not submitted payments.

1. 01

   Discover the binding your principal may use

   Read the binding collection, then select a binding from the returned context. Record the binding and wallet/network references privately. Do not let a model replace the workspace, role, or binding with arbitrary identifiers.

   Do this

   1. Run the read-only collection request below and inspect its HTTP outcome before parsing the response.
   2. Choose an existing test binding from the returned array and copy binding_uuid into your private worksheet.
   3. Follow the policy and budget documentation links using that exact identifier; record the network and observation time.

   Expected result

   One worksheet row refers to a binding you are entitled to read, with its actual network and current policy context.

   If your result is different

   For an empty array, request test provisioning; do not invent a binding. For authentication or scope errors, correct the credential context rather than trying other workspace identifiers.

   Result: You can identify the authority context you are testing; discovery has not granted execution access.

2. 02

   Read the governing policy and native-asset budget

   Inspect the current policy and budget for that binding. Preserve decimal amounts as strings and keep each asset separate. A native-unit limit is not a fiat allowance; a displayed budget is not an atomic reservation. Stop if required policy or asset context is missing.

   Do this

   1. Write the asset and amount in the format defined by AiWalletIntentEvaluationRequest; amount is a decimal string, not a floating-point JSON number.
   2. Choose case A inside the actual configured policy. Copy A to B and change only one supported constraint, such as destination or amount.
   3. Keep the model's rationale separate from the policy data; neither test case may supply a replacement policy.

   Expected result

   The two proposals differ in one explainable way, so a decision difference can be traced to that constraint.

   If your result is different

   If the intended restriction is not represented in the current schema/policy, select a supported test. Do not claim that the evaluator checks an arbitrary prompt instruction.

   Result: The proposal is expressed in the units and permissions the evaluator actually understands.

3. 03

   Submit the evaluation using the current request schema

   Use the separately scoped intent-evaluations operation. Populate its typed request from the published contract rather than copying an invented payment payload. Capture the actual decision and reasons in your test harness, with sensitive identifiers redacted from shared reports.

   Do this

   1. Open the exact intent-evaluations contract and review its destination schema, required fields, scope and errors.
   2. Submit A and B through your authorized test client; this guide intentionally does not auto-submit a mutation.
   3. Copy the actual decision and reasons into the worksheet and mark unavailable/error responses separately from policy denial.

   Expected result

   You have two observed evaluations, or a clearly recorded blocker. Neither row is labelled paid, approved or settled.

   If your result is different

   If both results are the same, re-read the binding and active policy and inspect the returned reasons. Do not alter the recorded response to match the expected demonstration.

   Result: Your application displays a policy result—not “approved”, “paid”, or “settled”.

4. 04

   Compare the results and check for side effects

   Repeat with the disallowed destination and an invalid or out-of-scope request. Compare relevant authorized state before and after; do not assume the evaluator has stored an audit event for you. Re-evaluate when policy or budget context changes.

   Do this

   1. Repeat one permitted evaluation using the agreed client and record the new observation time.
   2. Compare the authorized state relevant to reservations and execution before and after; retain only the evidence actually accessible to you.
   3. Add a stale-policy case to the worksheet and require a current read/evaluation rather than reusing an old result.

   Expected result

   The report explains the evaluator's decision-only boundary and separates actual observations from tests you could not perform.

   If your result is different

   If you see unrelated concurrent account activity, do not attribute it to evaluation without evidence. Isolate the test context or mark the comparison inconclusive.

   Result: The reviewer has allowed/denied cases, actual error handling, and evidence that this test did not move funds.

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.

Missing evaluation scope

Handle the documented 403 response; read access does not imply evaluation access.

No active policy

Handle the documented 409 response and stop. Do not substitute a locally guessed policy.

Authoritative service unavailable

Treat 503 as unavailable, not an allowed decision. Define bounded retries outside the model.

Policy changes after a successful evaluation

Read current context and evaluate again; the earlier decision did not reserve budget or future authority.

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.