Take one useful AI feature from brief to a working web app.

Choose a small stack with an explicit job for each layer

The worked product is a support-ticket classifier: accept a short message, return a category and rationale, and show an honest failure state when the provider cannot respond. This is narrow enough to test. Do not begin with an open-ended chat interface if the product only needs one classification.

A React interface, a server route, PostgreSQL, and a model gateway are one reasonable setup. They are choices for this exercise, not a performance ranking. Keep the provider credential and all spending controls on the server. The browser submits task input and displays the result; it never chooses a privileged provider key or overrides the spending limit.

Prove the local contract before paying for model calls

Use the runnable Node example in the linked agent skill before wiring it into a web route. It models request validation, duplicate requests, a bounded call budget, and provider failures. Its in-memory ledger is deliberately limited to one process. A production server needs a durable transaction for reservation and idempotency, especially with multiple replicas.

Create a fixture set containing billing, account-access and bug reports, an ambiguous message, a large input, and an instruction trying to override the classifier. Allowed categories are billing, account, bug, and needs-review. Decide the expected category or rejection before evaluating a model. Save inputs and expected outcomes together; otherwise a fluent answer can become a moving target.

{
  "id": "billing-refund-01",
  "input": "I was charged twice for the same subscription.",
  "expectedCategory": "billing",
  "mustNotContain": ["refund issued", "account updated"],
  "reason": "Classification does not authorize or perform a refund."
}

Once the local example passes, implement the real provider adapter behind the same interface. Check the selected model's current schema support, timeout behavior, and pricing in its documentation. Record model, prompt revision, tokens, elapsed time, and outcome for evaluation runs. Do not treat JSON-shaped output as a guarantee that the underlying classification is correct.

Follow one request through a crash and a replay

Use ticket T-041 and key triage-T-041-v1. Two simultaneous requests carry the same normalized text. One database transaction claims the account/key pair and reserves the allowed cost; the other reads the existing operation. Dispatch only after the winning transaction commits. Keep the network call outside the transaction.

This is an implementation design to test when replacing the tutorial's process-local Map. It is not a finished PostgreSQL adapter. Implement and test each recovery case below before claiming durability. A unique key in your database cannot establish exactly-once work at a remote provider.

Record the operation ID, injected crash point, provider-call count, stored status and budget before/after for each case. Test two service processes against the same disposable database; two calls to one Map do not exercise this boundary.