Human-in-the-loop workflow design
Decide where people should review, intervene, refuse, and recover
When agent actions need meaningful human authorisation, this area becomes relevant. For the product owner responsible for human review, the concern is specific: a human clicks approve without seeing the action or evidence that will actually be used. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. Human oversight needs an operating role, usable information, and time to decide. The proposed workflow should allow refusal and escalation, and should specify what happens when the action changes after approval.
The engineering decisions relationship
- Action consequence map
Establish the basis for reviewer authority.
- Approval freshness
Invalidate approval when material parameters change.
- Human review workflow
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around reviewer authority
Questions and the evidence they need
- Reviewer authority
- Inspect action consequence map for the relevant constraint or observation.
- Approval freshness
- Inspect reviewer roles for the relevant constraint or observation.
- Unavailable review
- Inspect approval interface and evidence for the relevant constraint or observation.
For the product owner responsible for human review, this becomes relevant when agent actions need meaningful human authorisation. The immediate decision is where people should review, intervene, refuse, and recover. The scope should be narrow enough that the engineering team can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that a human clicks approve without seeing the action or evidence that will actually be used. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Human review must bind to the final action payload
Relationships within engineering decisions
- Reviewer authority
- Assign the decision to a competent permitted role.
- Approval freshness
- Invalidate approval when material parameters change.
- Unavailable review
- Define refusal, timeout, and escalation behaviour.
Reviewer authority
For this scope, reviewer authority should be examined alongside action consequence map. Assign review to a role with competence and authority to decide. The workflow should distinguish advisory comments from permission to execute. A reviewer needs a meaningful ability to refuse or escalate, not merely a name recorded beside an automated action.
Approval freshness
For this scope, approval freshness should be examined alongside reviewer roles. Bind approval to the final action, relevant evidence, target, and scope. Material changes after approval should follow an explicit renewal rule. The design should let reviewers and operators compare what was approved with what was actually dispatched and observed.
Behaviour when review is unavailable
For this scope, behaviour when review is unavailable should be examined alongside approval interface and evidence. Define behaviour when review is delayed, unavailable, refused, or cancelled. The workflow should preserve a clear authority state and an accurate user explanation. Human oversight should not disappear automatically under queue pressure or after a late tool response changes the task.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for reviewer authority
Illustrative working format
- Action consequence map
- Match this description to the deployed or proposed boundary being examined.
- Reviewer roles
- Identify the accountable role and verify its decision rights or availability.
- Approval interface and evidence
- Connect the accepted action parameters to grant, amendment, expiry, and withdrawal.
The starting material is action consequence map, reviewer roles, and approval interface and evidence. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a workflow owner, an implementation lead, an eventual maintainer, and qualified control reviewers where needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry reviewer authority through to an accountable finding
From the scoped material to a decision record
- Action consequence map
Make the component and operating boundary explicit.
- Approval freshness
Apply the scoped check to unavailable review.
- Human review workflow
Record the evidence, open dependencies, and the owner’s next decision.
Design the review screen around the decision a competent person must make. Show the proposed effect, relevant evidence, uncertainty, and available alternatives without requiring the reviewer to reconstruct an entire trace. The proposed workflow should define what information is frozen at approval and which changes require another review.
A practical first slice would focus on reviewer authority and then follow its consequences into approval freshness. Keep behaviour when review is unavailable visible as a separate review question rather than assuming it is satisfied by the first result. The engineering team should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the human review workflow usable by its owner
Human review workflow
Illustrative working format
- Human review workflow
- Identify the assessed workflow, revision, and decision boundary.
- Approval evidence contract
- Link observations and counterevidence to the case, configuration, and conclusion limit.
- Refusal and escalation cases
- Name the unresolved condition, next action, and accountable owner.
Indicative outputs include human review workflow, approval evidence contract, and refusal and escalation cases. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Examine unavailable review through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Reviewer authority
An employee reviews the final payload of a proposed account change.
- Approval freshness
Change a consequential field after the employee reviewed the payload.
- Unavailable review
Require refreshed approval before executing the changed operation.
Consider an illustrative situation in which an agent proposes a customer account change that requires a competent employee to inspect the final payload. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the account-change example, an illustrative exercise would present an ambiguous request and an altered final payload. The reviewer should be able to refuse or request clarification, and the system should preserve that decision. Acceptance should include the unavailable-reviewer path so human oversight does not silently disappear when the queue is unattended.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves behaviour when review is unavailable unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the defined workflow and configuration
Confirm fit before the next commitment
- Reviewer authority
- This review is limited to the defined workflow and configuration.
- Action consequence map
- The relevant owner must confirm access and the intended operating conditions.
- Human review workflow
- Production acceptance needs separate scoped evidence.
The method described here is proposed engineering work. Scope, staffing, implementation access, acceptance, and commercial terms require a readiness review. A design or lab result does not establish production suitability, guaranteed reliability, or security certification.
Ways to engage
Related engagement scopes
AI Fractional Agentic AI Office
Create a regular place for agentic AI decisions. Connect initiative priorities, architecture questions, risk ownership and evidence reviews.
AI Fractional Agentic Transformation Office
Coordinate the operating changes behind agent adoption. Align workflow redesign, ownership, dependencies and adoption measures.
AI Harness Engineering Pod
Engineer a bounded AI execution harness with tool adapters, context handling, orchestration, recovery and observable traces.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Do you need an agent centre of excellence?
A centre can concentrate scarce expertise and reusable controls, or become an approval queue detached from real work. Choose the mandate before the structure.