Pausing an Agent Workflow for Human Input: Request Identity, Validation and Safe Resume

A workflow that waits for a person needs an explicit pending operation. A conversational question alone leaves decisions unresolved: who may answer, which run the answer belongs to, whether the request has expired and what happens if the answer arrives twice. Model the pause as a recorded state transition so the workflow can continue safely after a delay or restart.

Record a correlated input request

Give each request an identifier bound to a workflow instance, tenant and operation. Store the form definition, expected answer shape, creation time and expiry policy alongside that binding. The interface submits the request identifier with the answer. The receiving service looks up the outstanding operation instead of guessing from the newest message in a conversation.

Request identity helps locate an operation; actor identity and authorization determine who may answer it. OWASP recommends validating permissions on every request. Apply that check at resume time, including requests from a familiar browser session.

Design the pause as part of the state machine

Imagine an original procurement workflow. A classifier identifies a replacement part, a buyer supplies a delivery window, and a deterministic service checks stock before creating an order. The workflow should not hold a database transaction open while the buyer is away. Store the pending request, close the current unit of work, and wait for an authenticated answer.

The application's state can progress from awaiting_delivery_window to validating_answer, then checking_stock. Each transition should have an owner and a recorded reason. A browser refresh must redisplay the same outstanding request rather than generate a second order opportunity. Transaction scope, identity integration and ordering policy belong to the application that owns the workflow.

Answer shape is part of the contract

Define required fields, their types and the policy for additional keys. A delivery window represented as a string and one represented as an object are different contracts. JSON Schema provides object-validation vocabulary; select and test the exact dialect and validator used by the application.

For the procurement example, accept an explicit delivery-window object rather than asking the model to reinterpret free text at every resume. If the UI changes a field, version the pending form contract. An answer to yesterday's form must not silently acquire the meaning of today's schema.

A valid answer is not authorization

A correctly shaped delivery window says nothing about whether its sender may approve a purchase. Keep authorization outside model interpretation: bind the answer to the authenticated actor, tenant, workflow instance and exact pending operation. Recheck those bindings at the time the application accepts the answer. Reject stale or already-consumed submissions with a clear result.

Similarly, response-schema validation should not be described as a complete policy engine or full JSON Schema implementation. Read the specific validator and test the fields you rely on. Business constraints such as office opening hours, approval limits and allowed delivery addresses require additional deterministic validation. Never infer purchasing authority simply because a request resumed successfully.

Resume still needs replay and effect tests

Build a small acceptance matrix around the actual user journey: submit the expected answer, an answer with the wrong request ID, the same answer twice, an invalid field and an answer after the request expires. Restart the worker between asking and answering. Change stock availability during the pause and confirm that the application rechecks it instead of trusting the earlier observation.

Run the acceptance matrix against the storage backend, identity integration and external order service used by the application. A local workflow test establishes only the behavior it actually exercises. Record external effects with idempotency and reconcile ambiguous outcomes using the order service's own identifiers.

Make the operating contract explicit

Decide who owns abandoned requests and how long the system retains them. A timeout can move work to review, cancellation or a safe default, depending on the task. Record that transition with a bounded reason. A maintenance process should be able to list pending requests directly from durable state.

Release the integration in stages. First verify correlation and duplicate submissions with synthetic inputs. Then exercise the actual identity and storage boundaries in a controlled environment. Finally test external effects using the destination service's idempotency and reconciliation interfaces. Acceptance requires a traceable answer to a specific pending operation, with business preconditions checked when work continues.

Sources and evidence

Treat a human answer as an input to a specific recorded workflow request. Validate its shape, authenticate its sender and recheck business preconditions before resuming any external effect.