FAQ

Short answers for teams implementing real-money-aware agent commerce loops. If you only remember four things, make them these: wallet/auth boundary first, state before spend, quote → purchase → verify, and calm observability over hype.

Is this demo-only?

No. AgentWardrobe is designed for practical, repeatable workflows with clear operational boundaries. The point is to test and operate real purchase-like behavior—without hiding the risky parts behind a polished script.

Do I need a wallet?

Yes. Real-money-aware flows assume wallet-aware auth or API-key-backed account access depending on your integration path. The important part is the boundary: before an agent can quote or purchase, identity and authorization must be explicit.

Why not test by buying physical products directly?

That path is costly, slow, and hard to reproduce. AgentWardrobe preserves realistic transaction logic while enabling faster iteration, incident replay, and run-to-run comparisons.

What does a complete transaction loop look like?

Wallet authentication first, state-before-spend checks second, then quote → purchase → verify with settlement and wardrobe state confirmation. If you skip verification, you don’t have reliability—you have hope.

What does “good” look like in testing?

Consistent quote-to-settlement behavior, verifiable state transitions, and incident replayability with measurable recovery. “Good” also means your logs can explain each step: who approved, what was quoted, what was purchased, and what changed.

How do I prevent duplicate purchases?

Start with state before spend: read what’s already owned and what’s currently worn. Then add an idempotency strategy on your side so retries don’t create multiple purchases. Finally, rely on verify to confirm the intended single state transition occurred.

What should I store for observability?

At minimum: a run ID, the authenticated principal, the quote ID + expiration, purchase attempt IDs (and provider transaction hash if applicable), timestamps for each step, and verification results. The goal is to reconstruct the story without screen recordings.

What happens if settlement succeeds but wardrobe state doesn’t update?

Treat it as an incident, not an edge case. Verification should catch it. Your recovery options typically include re-reading state, re-running the state update step (if safe and idempotent), or routing to a manual reconciliation path. The key is that your system must surface the mismatch clearly to an operator.

What’s the difference between “quote” and “purchase” in practice?

A quote is a time-bound offer with explicit totals and constraints. A purchase is the execution of that offer. Separating them gives operators a clear approval moment and gives systems a stable artifact to verify against.