Agent orchestration design
Decide how to represent routing, transitions, and exception handling explicitly
When agent behaviour must follow a controlled sequence across tools and people, this area becomes relevant. For the workflow platform lead, the concern is specific: a workflow advances because a message sounds complete despite missing a required state change. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. The orchestration model should define what counts as completion at each boundary. Natural-language messages can carry useful context, but the design should identify the authoritative state and evidence required before advancing.
The engineering decisions relationship
- Workflow graph
Establish the basis for workflow state.
- Branch ownership
Assign responsibility when routes diverge.
- Orchestration design
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around workflow state
Questions and the evidence they need
- Workflow state
- Inspect workflow graph for the relevant constraint or observation.
- Branch ownership
- Inspect transition conditions for the relevant constraint or observation.
- Interrupted handoff
- Inspect exception categories for the relevant constraint or observation.
For the workflow platform lead, this becomes relevant when agent behaviour must follow a controlled sequence across tools and people. The immediate decision is how to represent routing, transitions, and exception handling explicitly. 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 workflow advances because a message sounds complete despite missing a required state change. 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
Orchestration needs explicit transitions and exception owners
Relationships within engineering decisions
- Workflow state
- Define valid movement between task stages.
- Branch ownership
- Assign responsibility when routes diverge.
- Interrupted handoff
- Provide a recovery rule for unfinished transfers.
State transition validity
For this scope, state transition validity should be examined alongside workflow graph. Define valid workflow states and the evidence required for each transition. A tool request, acknowledgement, and verified effect may represent different states. The orchestration design should make those distinctions explicit so the agent cannot advance merely because a message sounds complete.
Branch ownership
For this scope, branch ownership should be examined alongside transition conditions. Assign branch ownership and establish when clarification is required. A route should fit the task and permission context rather than only a keyword classification. Include cases where new information changes the appropriate branch after the workflow has already begun.
Recovery from interrupted handoffs
For this scope, recovery from interrupted handoffs should be examined alongside exception categories. Represent rejected approvals, unavailable tools, and interrupted handoffs as normal design paths. The system should preserve enough state to resume or escalate accurately. A successful ordinary trajectory does not demonstrate that exceptional transitions maintain authority and business consistency.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for workflow state
Illustrative working format
- Workflow graph
- Identify provenance and the specific decision this material can inform.
- Transition conditions
- Check its relationship to the relevant workflow and expose missing context.
- Exception categories
- Name the custodian and the conditions requiring a refreshed version.
The starting material is workflow graph, transition conditions, and exception categories. 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 workflow state through to an accountable finding
From the scoped material to a decision record
- Workflow graph
Make the component and operating boundary explicit.
- Branch ownership
Apply the scoped check to interrupted handoff.
- Orchestration design
Record the evidence, open dependencies, and the owner’s next decision.
Represent exceptional transitions as deliberately as the expected path. A missing document, rejected approval, expired credential, or failed tool effect should lead to a defined state with an owner. The proposed design should also distinguish an event that requests a transition from evidence that the transition actually completed.
A practical first slice would focus on state transition validity and then follow its consequences into branch ownership. Keep recovery from interrupted handoffs 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 orchestration design usable by its owner
Orchestration design
Illustrative working format
- Orchestration design
- Identify the assessed workflow, revision, and decision boundary.
- Transition contract
- Record accepted inputs, task meaning, and incomplete or failed outcome semantics.
- Exception handling cases
- Name the unresolved condition, next action, and accountable owner.
Indicative outputs include orchestration design, transition contract, and exception handling 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 interrupted handoff through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Workflow state
An onboarding workflow waits for human approval before provisioning.
- Branch ownership
Interrupt the workflow between document approval and provisioning.
- Interrupted handoff
Resume through an explicit transition with a named exception owner.
Consider an illustrative situation in which an onboarding agent coordinates document collection, validation, and a human approval before provisioning. This is a constructed example, not a client engagement or an observed Softlander outcome.
In the onboarding example, document validation should not automatically imply authorisation to provision access. The illustrative design exercise would interrupt the workflow between those steps and inspect the saved state. The owner could then decide whether the orchestration contract contains enough information to resume without bypassing review or repeating an effect.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves recovery from interrupted handoffs 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
- Workflow state
- This review is limited to the defined workflow and configuration.
- Workflow graph
- The relevant owner must confirm access and the intended operating conditions.
- Orchestration design
- 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.