A multi-step agent workflow passes the outputs of Step 1 to Step 2 and Step 3. Step 2 and Step 3 run concurrently. What is the correct mechanism for ensuring both steps receive accurate state from Step 1?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A relay race baton has to be passed cleanly before the next runner takes off. In agent pipelines, the 'baton' is the Step 1 output — write it to a shared artifact before downstream steps launch so both can read the same authoritative version.
Full explanation below image
Full Explanation
In concurrent agent pipelines, state passing requires a well-defined handoff mechanism. The pattern is: the upstream step writes its output to a durable, shared location before downstream steps begin; downstream steps read from that location at startup.
GitHub Actions implementation: - Use outputs from the Step 1 job, or write a JSON artifact and upload it. - Downstream jobs declare needs: [step1_job] and download the artifact or reference the output variable.
Why B is correct: A shared artifact is the standard state-passing mechanism. It is durable (survives step boundaries), deterministic (both readers see identical content), and auditable.
Why A is wrong: Having each downstream step re-run the upstream step is wasteful, potentially non-deterministic (Step 1 might produce different outputs on a second run), and defeats the purpose of the pipeline structure.
Why C is wrong: Email is not a machine-readable, reliable, low-latency inter-agent communication mechanism. Agents in a CI pipeline do not use email for state passing.
Why D is wrong: Agents do not share model weights at runtime in a way that propagates application state. Model weights are static parameters, not a communication channel for runtime data.