See the structure, then implement and verify with the notes.
After submission, distinguish committed, failed and unknown. Query unknown outcomes before attempting another write.
What situation are you walking into?
Users accept the advice and want execution. A retry could issue two offers; a wrong segment could affect many people. Value comes from a controlled action loop, not maximum permissions.
01 / An action is a precise contract
Define target objects, eligibility, parameter limits, budget, authorization, idempotency, result states and compensation. A model proposes the call; the service enforces constraints. Confirmation binds to a preview of affected objects, amounts and timing; changed parameters require fresh confirmation.
02 / Separate autonomy from risk
Progress from read-only to advice, confirmed execution and bounded automation. Advance based on evaluation, adoption and operating ownership. Require authorization for financial, sensitive or irreversible operations; do not add ceremonial approvals to low-risk reads.
03 / Retries, rollback and compensation differ
A timeout may hide a completed action. Query status before retrying. Database rollback cannot retract a read message or undo a redeemed offer. Separate technical rollback, business compensation and human escalation; test timeouts, duplicates and exhausted budgets.
04 / Adoption comes from fitting the job
Compare standalone chat with the existing workbench. Capture accept, edit-and-accept, reject or defer with reasons. Observe steps and time to complete the job, not conversation count. An actionable, evidence-backed recommendation is easier to incorporate than a long generic report.
Put the method to work
Offer preview: six synthetic, consented members at 10 each, total 60. After confirmation, execution times out. Recover with the same idempotency key and status lookup, not a new action. A changed recipient set invalidates the old confirmation.
Practice this week
- Define a controlled write tool and bound confirmation.
- Test duplicates, timeouts and budget exceptions.
- Map the user workflow and record rejection reasons.
Acceptance checks
- No unauthorized real-world sending.
- Repeated calls do not duplicate business effects.
- Explain which actions cannot simply be rolled back.
120 minutes: make retries safe at the business boundary
Observe preview, confirmation and replay in the browser, then inspect payload binding, expiry and execution-time budgets in the offline kit. Both are single-process synthetic simulations.
0–30 min: define preconditions, states and side effects for preview and execute. Bind confirmation to scope, quantity and amount.
30–75 min: test no confirmation, changed payload, budget overflow, expiry, replay and changed authority. Inspect final spend and record count.
75–120 min: recover from server commit followed by client timeout. Query the same request, rather than retrying with a fresh key. Design durable transactions and an idempotency ledger.
Artifact excerpt · synthetic example
State design / not a production implementation
DRAFT → PREVIEWED → CONFIRMED → COMMITTED
Changed payload: return to DRAFT
Expired / denied / over budget: BLOCKED, no state change
Client timeout: UNKNOWN → query original request_id
Same committed request_id: REPLAYED, original result
Production: unique constraint, transaction, durable ledger, reconciliationInstructor review
Prove success from final business state. HTTP responses, model text and logs alone do not prove one issuance. Irreversible external actions need compensation, not fictional rollback.
An unseen field challenge ↗
Why does a process-local lock fail when two operators spend the same budget across servers? Define the shared state and transaction boundary.
Case studies for this module
Bind a key to tenant and payload. Reject mismatched reuse; durable storage and atomic budgets remain production requirements.
After an execution timeout, what comes first?
A timeout may occur after completion. Status checks and idempotency prevent duplicate effects.
References and further reading
OpenAI ↗ · Function calling查阅 / Accessed 2026-09-07 · OpenAIKlarna ↗ · Klarna AI assistant: first-month results2024-02-27 · KlarnaModel Context Protocol ↗ · MCP security best practicesDraft · 查阅 / Accessed 2026-09-07 · Model Context ProtocolRead alongside the assignment and record design constraints and tests. Verify specifications against your deployment version.