Parth TiwariStart a project
MenuClose

Case 05 / Durable agent workflow

Order Supervisor

Order Supervisor lets a model interpret a customer message while Temporal and deterministic workflow code retain authority over the order lifecycle.

Read the evidence record View repository
Role
Full-stack engineer
Built at
Personal project
Contribution
Workflow architecture, agent boundary, API, and interface
Status
Shipped
Workflow recordAuthority remains outside the model
Customer input
Message or order event
Model output
Proposed action
Authority
Temporal workflow state
Universal approval
Not implemented
Source: Committed main at ba544e0
Committed workflow evidenceNo invented product outcome

Measured, with the denominator attached

Proof before polish.
No publishable outcome number

No outcome benchmark or production order volume has been recorded. The public case study treats this as an architecture project.

Architecture and source evidence onlyReviewed 2026-08-31
What it is

01 / What it is

The model can propose. The workflow still decides what is valid.

Order Supervisor handles customer conversations around long-running orders while Temporal keeps authoritative lifecycle state.

The model proposes from a small allowlist; deterministic workflow code validates and records the action.

Built for

An operations or support team handling orders that may wait, resume, receive messages out of sequence, and require an auditable state transition.

I built the Next.js product surface, FastAPI boundary, Temporal order workflow, model proposal path, event classification, rolling memory, action validation, and recovery-oriented lifecycle tests.

Contribution record

02 / Product proof

Read the source evidence before the argument.

Lifecycle trace

Lifecycle traceMessage becomes a checked event
01 Message
Classified as instruction, interruption, status, or ordinary conversation
02 Proposal
Model returns an action from a bounded vocabulary
03 Check
Workflow compares the proposal with authoritative state
04 Result
Accepted or rejected event is persisted
Source: Committed workflow and event types at ba544e0
This record renders real source-level lifecycle types and boundaries. It is evidence of the committed architecture, not a simulated order dashboard.
01
Event recordTyped inputs
Conversation
Customer message
Control
Interrupt, resume, or terminate
System
Timer or lifecycle event
Source: Committed event classification
Classify the event

Messages and system events are separated so an interruption, resume, or termination does not become ordinary chat context.

02
Authority recordProposal is not state
Proposal
Bounded model action
Validation
Current lifecycle rules
Rejected path
Recorded without transition
Source: Committed action allowlist and workflow
Validate the proposal

The model proposes from an allowlist, then deterministic workflow state accepts or rejects the action.

03
Durability recordWrite before wake
First
Persist lifecycle event
Then
Signal or resume workflow
Recovery
Replay durable state after restart
Source: Committed persistence and signal ordering
Persist before signalling

State and event history are committed before downstream signals so a retry can recover without inventing a transition.

03 / Problem and responsibility

Long-running orders outlive requests, processes, and conversational memory.

An order may wait for hours or days, receive messages out of sequence, and resume after a process restarts.

Putting lifecycle authority inside a chat loop makes retries, audit history, and duplicate actions unsafe.

Workflow
Temporal lifecycle, signals, timers, retries, transitions, event history, and recovery.
Agent
Model proposal contract, bounded actions, rolling memory, and deterministic validation.
Product
Next.js order surface, API boundary, status visibility, and corrected authority copy.

04 / Research that changed the build

Research only matters here when it changed a decision.

  1. 01

    Temporal durable execution

    A workflow can wait for hours or days and recover state without keeping a web request or process alive.

    One durable workflow became the authority for each order lifecycle.
  2. 02

    Thin API boundary review

    HTTP should start, inspect, or signal work rather than duplicate lifecycle state in the web process.

    FastAPI remains a transport edge while Temporal owns the long-running state machine.
  3. 03

    Event classification and rolling-memory tests

    Control events and old conversation turns need different retention and handling rules.

    Inputs became typed events and conversational context received a bounded rolling window.
  4. 04

    Persist-before-signal failure analysis

    Signalling before durable state is stored can wake a workflow that cannot reproduce the action it was asked to take.

    Authoritative records are persisted before the corresponding workflow signal.

05 / Architecture

Use one durable workflow per order and keep model reasoning advisory.

Signals and timers wake the workflow. Activities read state, request a model proposal, validate it against an allowlist, and append the result to the event log.

The product does not claim a blanket human approval step that the current source does not enforce.

Message to proposal to authoritative workflow event
  1. 01MessageCustomer, system, or control event enters through the API
  2. 02ProposalThe model proposes a bounded action with rolling context
  3. 03Workflow checkTemporal compares the proposal with authoritative lifecycle state
  4. 04Event logAccepted or rejected result is persisted before signalling
  5. 05ResumeThe workflow continues from durable state after waits or restarts

06 / Decisions and trade-offs

What I chose, what I rejected, and what the choice costs.

DecisionRejectedTrade-off
Use one Temporal workflow per order.

Keep lifecycle state in a synchronous chat request or application memory.

The system needs workflow infrastructure, while retries and long waits become explicit.

Keep model output advisory and validate it against workflow state.

Let the model mutate order status directly from conversational intent.

Some plausible actions are rejected, while the lifecycle remains deterministic and auditable.

Claim authority separation, not universal human approval.

Describe every accepted action as human-approved when the committed source does not enforce that gate.

The public story is less reassuring, but it matches the implemented contract.

07 / Evidence

The architecture is inspectable. Production outcome evidence is absent.

Not measured

No outcome benchmark or production order volume has been recorded. The public case study treats this as an architecture project.

No publishable outcome or usage denominator

There is no publishable order outcome or usage number. The case study therefore proves the source-level workflow contract and names the missing operational evidence.

08 / What failed

The failures are part of the architecture record.

  1. 01

    The diagram invented a human gate

    What I saw
    Portfolio copy said every consequential transition waited for human approval.
    Why
    A desirable product boundary was mistaken for behaviour enforced by the committed workflow.
    What changed
    The claim now states only what source proves: lifecycle authority remains outside the model.
    Still true
    A universal human approval gate still requires product design, implementation, and tests.
  2. 02

    Signals could outrun persistence

    What I saw
    A workflow could receive a wake-up before the corresponding durable event existed.
    Why
    The side-effect order treated signalling and persistence as interchangeable operations.
    What changed
    The lifecycle path persists authoritative state before emitting the signal.
    Still true
    Every new event type still needs the same ordering and replay tests.
  3. 03

    Conversation memory could grow without bound

    What I saw
    Long-lived orders accumulated more context than the model needed to make the next proposal.
    Why
    Workflow history and model prompt memory were treated as the same retention surface.
    What changed
    The durable event log remains complete while model context uses a bounded rolling memory.
    Still true
    Summarisation quality and context loss have no publishable benchmark yet.
Read the authority-versus-approval correction

09 / Limits and future

What the product cannot do yet, beside what may come next.

Current limitations

  • Universal human approval is not implemented and is not claimed.
  • No production order volume, customer outcome, latency, or recovery benchmark has been recorded.
  • The model can still make an unsuitable proposal; the safety boundary is that workflow code may reject it.
  • The committed local product surface was not promoted as live evidence in this batch.

Deliberate boundaries

  • Let the model mark an order complete by itself.
  • Invent a human-approval guarantee that the current workflow does not implement.
planned

Explicit human-review policy

Define which actions require approval, model that state in the workflow, and test every bypass and recovery path.

planned

Recovery benchmark

Record interrupted, delayed, duplicated, and restarted orders with denominators before publishing reliability claims.

investigating

Memory quality

Measure whether bounded context preserves the facts needed for later order decisions without replaying the full conversation.

10 / Stack and sources

The systems underneath it, and where this account comes from.

  • Temporal
  • FastAPI
  • Next.js
  • PostgreSQL
  • OpenAI API
  • Groq
Audited internallyOrder Supervisor committed repository and lifecycle tests
Audited internallyAuthority correction erratum