In a three-stage pipeline — research agent → synthesis agent → writing agent — the synthesis agent needs access to the raw findings produced by the research agent. Which state-sharing pattern is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Think of a relay race — you need a clean baton handoff, not one runner carrying the baton while the next one jogs alongside them. On the exam, durable named artifacts are the correct inter-agent state handoff mechanism; passing large outputs through prompt prefixes or environment variables is fragile and doesn't scale.
Full Explanation
In a sequential multi-agent pipeline, each stage must receive the previous stage's output in a reliable, inspectable, and scalable way. Having the research agent write its findings to a named durable artifact, and configuring the synthesis agent to read from that artifact as its input source, achieves all three: the research agent writes once, the synthesis agent reads at its own pace, the data persists through failures, and the artifact serves as an audit trail. This is the standard pattern for inter-agent state handoff.
Passing the research agent's full output as a prompt prefix to the synthesis agent's context window is tempting because it seems direct, but it has critical limitations: context windows have size limits, the data is ephemeral once the session ends, and it cannot be inspected or replayed by the orchestrator. For anything beyond trivial data volumes, this approach breaks down.
Re-running the research agent inside the synthesis agent's session so it can observe the findings directly is incorrect because it wastes compute, may produce different results when agents are non-deterministic, and creates a hard coupling between stages that defeats the purpose of a modular pipeline. It also doubles the cost and latency of the research phase.
Storing the research findings in the coordinator's local variables and passing them as environment variables to downstream agents is incorrect because environment variables are not designed for structured, potentially large datasets. They have system-level size limits, typically only a few megabytes total, are not durable, are not queryable, and expose data in a low-visibility format that is difficult to audit. Local coordinator variables are in-memory and lost on restart.