Reliable workflows and agents

What you will be able to do

1. Model durable state explicitly.
2. Use idempotency, transactions, compensation, and approval.
3. Test crashes, replay, races, and malicious observations.

Prerequisites: Builder-level interface validation, Python, testing, metadata logging and state-transition tracing. Hardware benchmarks and model accounts are not required.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

Durable workflows separate state from a worker process. Each transition has a precondition, action, recorded result, and next state. At-least-once delivery means duplicate messages are expected; idempotency keys make repeated requests converge on one recorded outcome. Transactions protect local consistency, while compensating actions address completed external steps that cannot share a transaction. Human approval is a signed state transition with scope and expiry, not a sentence in a prompt. Audit records must reconstruct decisions without exposing prohibited content.

Mechanism and implementation

An effect may finish before acknowledgment is lost. Record scoped idempotency keys/outcomes durably and reconcile unknown status before retrying. Approval binds actor, exact action/arguments, resource version and expiry. Cancellation stops future work; completed effects need reviewed compensation.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

ledger = {}
def action(key, value):
    if key in ledger:
        if ledger[key] != value:
            raise ValueError("key_reused_for_different_action")
        return "replayed"
    ledger[key] = value
    return "recorded"
assert action("case-1:v1", "draft") == "recorded"
assert action("case-1:v1", "draft") == "replayed"
assert len(ledger) == 1
print("one simulated effect despite replay")

Engineering decisions

• Define state transitions and terminal states.
• Choose idempotency scope and retention.
• Place approvals before consequential simulated actions.

Worked example

A synthetic case workflow crashes after recording an action but before acknowledging the message. Replay uses the same idempotency key and does not duplicate the action. A malicious observation cannot move the case to approved.

Diagnose the failure

Identical replay produces one effect; changed intent rejects. This in-memory construction is not process-durable; persistent storage needs transaction/reconciliation design.

Part 2 Guided practice

Simulate a crash after the record and before acknowledgment, then replay. Independently reject changed arguments under the same key, expired approval and cancellation before a next action.

Answer criteria and feedback: Identical replay produces one effect; changed intent rejects. This in-memory construction is not process-durable; persistent storage needs transaction/reconciliation design.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

Replay the event log from state zero. If reconstructed state differs, locate the first nondeterministic or unrecorded transition. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

• https://genai.owasp.org/
• https://docs.temporal.io/workflows

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.