Share useful agent context without exposing private sources

Before you start.

Set up your workspace

Start with an owner-approved test collection and registered workload signer. Open the collection and manifest operation references before making requests. The signed read requires bearer authority plus the exact timestamp, nonce and Ed25519 signature profile; the generic bearer-only curl pattern is deliberately not used here.

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/context/memory-collections/{collection_id}/manifest

This read needs the registered workload signer, not bearer-only curl. Open the operation’s authentication section and have your approved client construct a fresh request with the timestamp, one-time nonce, exact method/path/query, body-byte digest and Ed25519 signature. Do not paste captured authentication headers into a new request.

Replace {collection_id} with your approved test collection identifier in that client. An authentication failure means the read has not succeeded; it is not an empty collection or an answered request.

Read the response deliberately

• The manifest's collection section identifies the approved version; capabilities and authority describe the caller's effective boundary.
• actions and delivery describe asynchronous interactions. An OPEN request is not an answered question.
• Verify the documented integrity/signature representation using the approved signer/verifier implementation; do not reconstruct signed bytes from a prettified display.

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 supplier shares approved delivery requirements with a purchasing assistant. Internal negotiation notes remain private. The assistant can read published requirements and request clarification when an answer is missing, without receiving the entire source folder.

Keep one working record throughout

Use a fictional supplier collection with two approved facts: delivery window and support contact role. Keep an internal negotiation note outside the collection. Your worksheet tracks approved version, recipient workload, allowed capability, request reference and whether an answer is reviewed or still pending.

1. 01

   Prepare the smallest useful collection

   Choose one question the recipient should be able to answer. Remove private notes, unrelated customer data, and secrets before publication. Assign an owner for review and revisions; do not assume copying a source into a draft makes it safe to share.

   Do this

   1. Write the recipient's question first: when can this supplier deliver, and how should an exception be raised?
   2. Prepare only those approved facts using the owner workflow; leave the negotiation note in the private source.
   3. Record the publication reference and intended recipient before testing access.

   Expected result

   A reviewer can point to the approved material and explain why the private note is not part of the recipient projection.

   If your result is different

   If you cannot identify an approved version, stop at a draft. A collection title or relationship invitation is not proof of publication.

   Result: A recipient-safe collection is reviewed through the authorized publishing workflow, with an explicit audience.

2. 02

   Verify publication and workload access

   Inspect the collection manifest and collection using the recipient's approved workload route. Sign the exact request as specified by the contract. A fresh nonce and timestamp are part of replay protection; a bearer alone does not satisfy the signed-request requirements.

   Do this

   1. Use your registered signer to read the manifest with the exact method, path/query and body-byte digest required by the contract.
   2. Inspect collection, capabilities and authority in the returned manifest and add them to the private worksheet.
   3. Test the approved recipient route; plan the unrelated-workload negative case using only an authorized test principal.

   Expected result

   The intended recipient can inspect its effective knowledge boundary without receiving private source or wallet authority.

   If your result is different

   For signature errors check clock freshness, a fresh nonce, exact URL encoding and body bytes. Do not log signing keys or replay a captured authentication header.

   Result: The intended workload can read only the collection and capabilities it is entitled to use.

3. 03

   Ask for clarification without inventing an answer

   Submit QUERY or CLARIFY with context:query, or PROPOSE with context:propose, only when that capability is granted. Keep the same Idempotency-Key for retries of the same logical request and body, while constructing a fresh signed request. Inspect the returned request UUID and OPEN state; use the approved review workflow to obtain the reviewed answer later.

   Do this

   1. Ask a question intentionally absent from the two approved facts through the documented QUERY or CLARIFY action.
   2. Record the returned request UUID and OPEN state; label the answer pending in the application.
   3. For a retry, retain the logical body and idempotency key while constructing fresh signed authentication; follow the owner's review process for the answer.

   Expected result

   The worksheet contains a tracked unanswered question, not a fabricated immediate assistant response.

   If your result is different

   If the receipt is duplicated or conflicts, inspect the existing request and body/key relationship before trying another request. A new key is not a safe substitute for reconciliation.

   Result: An unanswered question becomes a tracked request instead of an assumed instant response.

4. 04

   Exercise revision and withdrawal

   Have the authorized owner revise a draft, review it, and publish through the available workspace controls. Test new reads after access is withdrawn. Do not describe withdrawal as erasing copies or model context already received by a recipient.

   Do this

   1. Have the owner revise and review the test fact through the enabled workspace workflow.
   2. Read again through the recipient route and compare the approved-version reference actually returned.
   3. After an authorized withdrawal test, attempt a fresh read and record the outcome separately from copies already received.

   Expected result

   You can explain version changes and future-access withdrawal using observed records, without claiming remote erasure of prior copies.

   If your result is different

   If the app still displays cached content, distinguish that local cache from a successful fresh service read; clear or label it according to your application policy.

   Result: The team understands which version is available and what future access withdrawal can—and cannot—control.

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.

Unrelated workload uses the same collection ID

Access must not be inferred from a different relationship or workspace; inspect the actual denied result.

Signed request is replayed

The replay-protection checks should reject reused authentication material. Test only in the agreed environment.

Retry key is reused with a different request body

Treat the documented idempotency conflict as a conflict, not a second successful request.

Collection access is withdrawn

Verify a fresh request no longer succeeds; document that previously received copies are not remotely erased.

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.