Release each stage after its prerequisites

Learning objective

Implement sequential, dependency-aware orchestration

Core idea

Sequential orchestration defines who acts next before the run starts. Dependency-aware orchestration defines what must be available and valid before that actor can proceed. These coincide in a simple chain, but a sequence of successful calls is not enough when the next stage requires a particular artifact, approval, or combination of upstream results.

Use Microsoft Agent Framework’s sequential builder for a fixed agent pipeline. Use a custom workflow graph when prerequisite checks or branching must control execution. Keep business acceptance rules in executors and edge predicates rather than asking the next model to infer whether its input is usable.

A reviewer can produce a response without approving a draft. The workflow must represent that difference before publication becomes reachable. See 1.1.2 for separating deterministic control from model discretion.

How it works

Establish the ordered path

In Python, SequentialBuilder(participants=[writer, reviewer]).build() creates the pipeline in participant order. The corresponding .NET entry point is AgentWorkflowBuilder.BuildSequential(). These are Agent Framework orchestration APIs; do not treat their configuration as a property of every Microsoft Foundry agent.

Each stage processes the preceding stage’s conversation and contributes its response. In Python, the default includes the previous agent’s input and response messages. chain_only_agent_responses=True changes the chain to pass only response messages. Choose that setting when a stage transforms the preceding artifact, but preserve any requirements that the next stage still needs in the artifact itself.

A translation pipeline might deliberately consume only the translated text. A compliance reviewer also needs the policy and original request. Removing those inputs to save context can make the reviewer complete its call while failing its actual responsibility. Context selection is an input-contract decision; see 2.1.5 for the detailed context mechanisms.

Insert deterministic acceptance gates

Sequential orchestration supports custom executors alongside agents. When an executor follows an agent, the Python handler receives an AgentExecutorResponse; agent_response.full_conversation exposes the conversation. The executor can inspect the returned artifact and enforce your application’s contract before passing work onward.

Define a validation outcome such as accepted, needs_revision, or invalid. These names are application-defined, not Microsoft enum values. A gate checks required fields, artifact identity, and approval evidence. It does not infer acceptance merely because the model returned fluent prose or the transport call succeeded.

For explicit branches, construct a graph with WorkflowBuilder(start_executor=...) and add_edge(source, target, condition=...). A direct edge expresses unconditional progression. A conditional edge expresses a progression rule over the message. A switch-case group gives one routing decision with explicit cases and a Default destination for unmatched inputs.

Place a rejection or escalation destination in the graph. If validation fails, the application should produce an inspectable outcome rather than fall through to the action stage. An unmatched route that silently does nothing is hard to distinguish from successful completion when the caller looks only for the absence of an exception.

Model multiple prerequisites explicitly

A linear order can hide a richer dependency graph. Suppose a synthesis stage requires both a financial analysis and an engineering estimate. Running those tasks one after another is valid but unnecessarily serial when neither consumes the other’s output. Fan out the independent work, then join the results before synthesis; see 2.4.2 for aggregation policy.

Python WorkflowBuilder.add_fan_in_edges([worker1, worker2], aggregator) connects the sources to a collecting target. The .NET equivalent is AddFanInBarrierEdge. Treat that structural join separately from semantic acceptance. The collecting executor still checks that the expected artifacts match the request and satisfy the prerequisite contract.

For each dependency, specify the producer, artifact, and acceptance condition. A stage that needs an approved estimate must not accept an estimate marked provisional. A stage that needs two independent assessments must not count two messages from one producer as two prerequisites. These checks belong to your typed message and gate implementation.

Distinguish progress from completion

In Python, SequentialBuilder designates the last participant as the terminal output source by default. With participants=[writer, reviewer, editor], intermediate_output_from=[writer, reviewer] makes the writer and reviewer emit "intermediate" events. Listing a participant demotes it from the default-final set, so the editor alone emits "output" events in this configuration.

A custom terminal executor must call ctx.yield_output(AgentResponse(...)) to publish its result in the documented sequential pattern. Sending a message with ctx.send_message(...) advances graph work; it does not mean the caller has received a terminal answer. Make the terminal payload state whether the business result was accepted, rejected, or left incomplete.

Streaming a draft to a progress panel does not authorize another service to consume it as the approved artifact. Preserve the output designation and validation outcome together. See 1.2.8 for workflow monitoring rather than treating event volume as evidence of completion.

Key distinctions and trade-offs

Sequence versus dependency: A sequence determines order. A dependency determines which accepted result enables a consumer. Use a chain for simple dependencies and a graph for branches or joins.

Completion versus acceptance: An agent response proves that the agent returned something. A gate proves that the returned artifact meets the requirements for the next stage.

Conversation versus artifact: Full conversation gives useful context but increases irrelevant input. Response-only chaining reduces context while making a complete output contract more important.

Fixed ordering is easier to inspect than discretionary routing, but every stage adds to the critical path. Do not parallelize a consumer with its producer to reduce latency. Parallelize only work whose inputs are already available, and preserve the join before dependent work.

Architecture / decision scenario

A proposal service extracts requirements, drafts a design, reviews it, and emits a customer-ready proposal. The extraction result carries an application-defined request identifier and the required constraints. The draft must cite those constraints; the review result includes an explicit acceptance outcome.

The team uses SequentialBuilder for an initial extract-to-draft prototype. For production, it represents draft, validation, and publication as explicit graph stages. The validator routes accepted drafts through a conditional edge to publication and invalid drafts to an escalation executor. Publication cannot be reached solely because the reviewer answered.

Cost analysis and delivery estimates consume the validated design independently. The graph collects both with add_fan_in_edges before final synthesis. The join checks producer identities and the design revision so a stale estimate cannot unlock publication. The team retains full context where the policy reviewer needs the original requirements, and uses response-only transformation only where the artifact is self-contained.

Drafting and review appear as intermediate progress. The final executor yields one accepted proposal or one explicit incomplete outcome. This implements both sequencing and dependency enforcement without delegating the release decision to a prompt.

Common exam traps

• Equating an ordered list of agents with validation of their outputs.
• Running a downstream consumer before its required artifact exists.
• Assuming response-only chaining preserves the original request automatically.
• Treating fan-in as proof that every collected artifact is acceptable.
• Publishing an intermediate response as the final business result.
• Using a model’s approval wording instead of an enforced routing predicate.

What to remember

Use SequentialBuilder for ordered pipelines and WorkflowBuilder for explicit gates, branches, and joins. Advance dependent stages only from accepted artifacts, and distinguish intermediate progress from terminal output. Order describes execution; validation determines whether execution may continue.

Knowledge check

References

• Microsoft, Sequential orchestration
• Microsoft, Edges
• Microsoft, Executors