Human-directed task orchestration¶

Execute consequential multi-step work under explicit human step direction, with the agent carrying out instructed actions, preserving authoritative execution state, verifying each step, and packaging safe takeover or resumption when humans pause, redirect, or assume control.

Metadata¶

Pattern id: human-directed-task-orchestration
Pattern family: Execute / Automate
Problem structure: Exception-aware orchestration (exception-aware-orchestration)
Domains: Engineering (engineering), Operations (operations), Compliance (compliance)

Workflow goal¶

Complete a consequential operator-directed procedure across tools and systems while keeping each significant step tied to explicit human instruction, verified current state, and takeover-safe execution records.

Inputs¶

Directed execution charter¶

Description: The named human lead, current objective, allowed procedure scope, protected boundaries, and explicit statement that the workflow is for directed execution rather than planning or open-ended collaboration.
Kind: execution-order
Required: Yes
Examples:
Incident commander directs a live remediation sequence for a production outage while keeping database failover authority reserved for a named responder
Sanctions remediation lead authorizes immediate blocking, evidence preservation, and queue updates but forbids any regulator filing without separate approval

Current procedure and control rules¶

Description: The approved runbook fragments, step prerequisites, no-go conditions, verification requirements, and takeover rules that constrain which directed actions may be executed.
Kind: policy
Required: Yes
Examples:
Emergency service-recovery procedure requiring metric verification before each rollback or traffic move
Cold-chain containment procedure defining hold-code entry, reroute preconditions, and chain-of-custody evidence requirements

Live system and case state¶

Description: Current telemetry, records, task context, approvals already in force, and environmental conditions needed to decide whether the next human-directed step is still safe to run.
Kind: execution-state
Required: Yes
Examples:
Current incident metrics, feature-flag state, node health, and open mitigation notes during a payments outage bridge
Shipment temperature readings, trailer locations, lot holds, and vendor-response status during a cold-chain excursion

Prior step ledger and takeover context¶

Description: Durable history of completed steps, partial actions, human instructions, verification results, and any earlier handoff or pause state already accumulated in the same execution window.
Kind: stage-history
Required: No
Examples:
Ledger showing that traffic was narrowed, one cache flush completed, and the bridge lead requested human review before a database restart
Resume packet showing that account blocks were applied but one sanctions-screening queue remains on hold pending legal review

Outputs¶

Directed execution ledger¶

Description: Authoritative record of human instructions received, actions executed, verification outcomes, skipped or blocked steps, and the current procedure status.
Kind: execution-result
Required: Yes
Examples:
Timeline linking each incident-command instruction to the corresponding remediation action, health check, and remaining held steps
Step ledger showing which cold-chain lots were isolated, which reroutes were completed, and which supervisory approvals still gate field pickup

Verified operational state record¶

Description: Current state snapshot showing what is now true in the target systems after the directed steps completed, partially completed, or halted.
Kind: state-record
Required: Yes
Examples:
Verified production state showing the rolled-back service version, current error rate, and remaining degraded dependencies after guided remediation
Compliance control state showing which accounts are blocked, which transactions are held, and which remediation tasks remain open after directed sanctions action

Takeover or resumption packet¶

Description: Structured handoff that preserves pending steps, current evidence, partial changes, and boundary notes so a human or successor workflow can continue safely without rediscovery.
Kind: escalation-packet
Required: Yes
Examples:
Packet for the database platform team showing completed bridge actions, current lock contention, and the exact step where the incident commander requested takeover
Resumption packet for a sanctions counsel review showing completed account holds, unresolved entity matches, and blocked next actions

Execution evidence and control trace¶

Description: Durable audit trail of tool actions, state checks, human directives, boundary confirmations, and any manual overrides or pauses taken during the run.
Kind: audit-log
Required: Yes
Examples:
Trace linking shell commands, feature-flag updates, incident-channel instructions, and post-step telemetry checks during a live outage response
Audit record tying cold-chain system updates, supervisor directions, and chain-of-custody confirmations to each completed emergency step

Environment¶

Operates in consequential live procedures where humans retain control of the significant steps, but agents add value by executing directed actions quickly across tools, carrying forward durable state, verifying the effect of each step, and making pauses or takeovers safe when conditions change.

Systems¶

Incident, case, or command-management systems
Operational control planes, APIs, or workflow consoles
Monitoring, verification, and evidence systems
Audit stores and handoff ledgers

Actors¶

Human incident, operations, or compliance lead directing the work
Agent executor carrying out instructed steps and recording state
Domain specialist who may take over a blocked or escalated branch
Risk, security, or audit reviewer

Constraints¶

Do not infer or expand significant next steps beyond explicit human direction and declared procedure scope.
Re-verify current state after each consequential action before the workflow accepts another directed step as safe to run.
Preserve one authoritative step ledger so pauses, redirects, and takeovers do not create conflicting accounts of current state.
Stop and package handoff context when a requested action would cross policy, authority, or reversibility boundaries that the directing human has not explicitly cleared.

Assumptions¶

A named human lead remains available to direct significant steps, confirm branch changes, and own irreversible or high-blast-radius decisions.
Target systems expose enough confirmation signals for the workflow to verify each directed step before continuing.
Adjacent recommendation, planning, and collaborative workflows may feed context into this pattern, but they do not replace the explicit action-first execution loop.

Capability requirements¶

Action execution (action-execution): The workflow must carry out real operational steps that change live system or case state rather than only drafting guidance.
Tool use (tool-use): Directed execution requires using operational consoles, APIs, tickets, and evidence systems while humans stay focused on control decisions.
Memory and state tracking (memory-and-state-tracking): The workflow needs durable step memory so humans can redirect or resume the procedure without losing authoritative state.
Verification (verification): Each significant step must be checked against live signals before the next directed action proceeds.
Policy and constraint checking (policy-and-constraint-checking): The system must enforce declared boundaries, reversible-versus-irreversible distinctions, and takeover conditions during execution.
Coordination (coordination): Human leads, agent executors, and specialist responders need one shared procedure state so directed steps and takeovers remain aligned.
Exception handling (exception-handling): The workflow must recognize when verification failure, state drift, or unclear instructions require a pause, redirect, or human takeover instead of forced continuation.

Execution architecture¶

Tool-using single agent (tool-using-single-agent): One execution agent can often carry out the instructed tool actions, maintain the step ledger, and verify state between directives while leaving consequential branching decisions to humans.
Human in the loop (human-in-the-loop): The pattern is defined by explicit human direction of significant steps, so normal operation always includes human review of procedure progress and next-action authority.

Autonomy profile¶

Level: Human directed (human-directed)
Reversibility: Some directed steps can be retried or rolled back, but the broader procedure often mixes reversible and partially irreversible actions, so harm can compound quickly if the workflow executes an instruction against stale or misunderstood state.
Escalation: Escalate whenever the next requested step is ambiguous, current verification signals disagree, authority boundaries are unclear, or safe continuation would require the agent to choose the procedure rather than execute it.

Human checkpoints¶

Confirm the directed execution scope, named human lead, protected boundaries, and initial step sequence before any live action begins.
Review verified state after each significant step or branch point before authorizing the next consequential action.
Approve any takeover, boundary change, or irreversible step before the workflow resumes or hands control to another responder.

Risk and governance¶

Risk level: Critical (critical)
Failure impact: Mis-executed human-directed procedures can prolong outages, move unsafe physical inventory, freeze or release the wrong regulated activity, or otherwise create severe operational, safety, legal, or customer harm because the workflow is already acting on live systems under pressure.
Auditability: Preserve each human instruction, state snapshot, tool action, verification result, pause, takeover packet, and manual override so reviewers can reconstruct exactly how the directed execution progressed.

Approval requirements¶

A named human lead must authorize entry into the directed execution loop and remain accountable for significant branch choices, takeover decisions, and irreversible actions.
Material changes to procedure templates, takeover rules, or authority boundaries require governance approval before future directed runs may rely on them.

Privacy¶

Limit copied incident, shipment, customer, counterparty, or case detail to the minimum needed for directed execution and governed handoff.
Keep sensitive evidence in approved audit stores or restricted annexes when broad procedural visibility does not require full raw detail.

Security¶

Use least-privilege credentials for the execution agent and separate privileged takeover authority from ordinary directed steps where possible.
Log every state-changing action and human directive so silent scope expansion or off-record execution remains detectable.

Notes: Critical-risk governance fits because the workflow performs live consequential work under time pressure, yet remains family-clean by requiring explicit human direction of significant steps rather than autonomous branching or broad collaborative authorship.

Why agentic¶

Directed live procedures benefit from an agent that can translate human instructions into tool actions, verification checks, and durable state updates faster than manual swivel-chair execution.
Safe performance depends on preserving context across pauses, redirects, and partial completion so humans can continue the procedure without reconstructing what already happened.
The workflow must decide when not to act because ambiguous instructions, stale state, or verification conflicts are themselves critical signals during guided execution.

Failure modes¶

The workflow infers an unapproved next step from earlier context instead of waiting for explicit human direction¶

Impact: A consequential action occurs outside the human's intended branch, widening impact or violating governance boundaries.
Severity: critical
Detectability: medium
Mitigations:
Require explicit human confirmation for each significant next step and record that instruction in the authoritative ledger.
Block continuation when the requested action cannot be tied to the current directed scope and boundary rules.

Verification state is stale or contradictory when the next directed action executes¶

Impact: The workflow continues the procedure against an outdated reality, increasing the chance of unsafe or ineffective action.
Severity: critical
Detectability: medium
Mitigations:
Re-read authoritative system state before and after each consequential action.
Treat conflicting confirmation signals as a pause-and-escalate condition rather than a warning to ignore.

Takeover or resumption state omits partial changes or pending holds¶

Impact: The human or successor workflow repeats, skips, or misunderstands steps, creating duplicate action or control gaps during a high-pressure handoff.
Severity: high
Detectability: medium
Mitigations:
Keep one append-only step ledger with explicit completed, pending, blocked, and reversed statuses.
Package current system state, partial actions, and blocked next steps together whenever execution pauses or transfers.

Directed execution drifts into planning or collaborative drafting instead of live action¶

Impact: The workflow loses its execution-first boundary and operators cannot tell whether work has actually been carried through to operational state.
Severity: medium
Detectability: high
Mitigations:
Limit outputs to execution ledgers, verified state records, takeover packets, and audit traces.
Hand off planning, recommendation, or shared-artifact revision work to adjacent patterns rather than absorbing it into the step loop.

Evaluation¶

Success metrics¶

Percentage of directed execution runs completed or safely handed off without unauthorized branch expansion or lost step state.
Rate of ambiguous, stale, or unsafe conditions caught before the next consequential directed action executes.
Completeness of takeover packets and audit traces for paused, redirected, or escalated runs.

Quality criteria¶

Every significant action is traceable to an explicit human directive and a verified current-state check.
The workflow preserves one authoritative procedure ledger across pauses, redirects, and takeovers.
{'Outputs remain execution-first': 'they show what operational work was completed, what remains blocked, and who must direct the next step.'}

Robustness checks¶

Test contradictory live signals between directed steps and confirm the workflow pauses instead of guessing the safest branch.
Test interrupted runs and verify a human can resume from the takeover packet without repeating or skipping prior actions.
Test instructions that would cross scope or authority boundaries and ensure the workflow blocks them until a named human clears the change explicitly.

Benchmark notes: Evaluate step fidelity, verified state quality, and handoff safety together; rapid execution is not success if the workflow cannot prove which human-directed actions actually ran and what state they left behind.

Implementation notes¶

Orchestration notes¶

Separate human instruction intake, state hydration, step execution, verification, and takeover packaging into explicit stages over shared durable procedure state.
Keep the current directed step, verification result, and blocked-next-step reason visible as first-class data rather than only in operator chat or tool logs.

Integration notes¶

Common implementations integrate incident or case systems, operational control surfaces, observability tooling, and governed audit stores.
Keep the pattern neutral about whether the directed execution uses shell commands, workflow consoles, operational APIs, or regulated case-management tools.

Deployment notes¶

Start with critical guided procedures that already have named human leads, explicit branch boundaries, and strong verification signals.
Review takeover quality, blocked-step frequency, and disagreement between human intent and executed steps early so the pattern stays sharply bounded at directed execution.

References¶

Example domains¶

Engineering (engineering): Under an incident commander's live direction, execute a production remediation sequence across feature flags, service restarts, and verification checks while preserving exact step state for safe handoff to a specialist team.
Operations (operations): Under a cold-chain supervisor's direction, isolate at-risk inventory, issue hold codes, reroute protected shipments, and verify chain-of-custody state after each emergency step.
Compliance (compliance): Under a sanctions remediation lead's direction, apply account blocks, transaction holds, and evidence-preservation steps while packaging unresolved branches for counsel takeover.

Exception-aware task execution (contrasts-with)
Both patterns preserve state and safe escalation, but this one requires explicit human direction of significant steps instead of delegated routine execution inside a preapproved runbook.
Staged change execution with rollback holds (adjacent-to)
Both patterns execute consequential operational work, but this one centers on stepwise human direction and takeover safety rather than predeclared stage progression with hold-release checkpoints.
Critical command-window resequencing (can-follow-from)
A critical planning workflow may establish the current command sequence, after which this pattern carries the human-directed operational steps through live execution.

Grounded instances¶

Canonical source¶

data/patterns/execute-automate/human-directed-task-orchestration.yaml