Join the Waitlist
Guide

How to Pass Context Between Agent Steps

6 stepsUpdated AUG 2026AI

Summary

When a workflow runs multiple Agent Interaction nodes in sequence, each agent receives the instance context accumulated so far. This guide explains how that context is built, how to shape it deliberately using workflow fields and system prompts, and how to use Information nodes to document your context design.

The steps

  1. Map the context each agent needs before you build

    Before opening the Workflow Editor, map out what each agent in your workflow needs to know when it runs. This is a design step, not a configuration step, and doing it on paper first saves significant rework.

    For each Agent Interaction node in your planned workflow, answer three questions:

    1. What inputs does this agent need? List the specific values: the user's original brief, the output of the previous agent, a field collected in a User Interaction step, a value fetched by an API Call node.
    2. Where does each input come from? Identify the upstream node that produces each value and the workflow field name it will be stored under.
    3. What output does this agent produce? Name the field or fields where the agent's response will be stored, so downstream nodes can reference them.

    This map becomes your field naming convention for the workflow. Consistent field names across all nodes are what make context flow reliably from one agent to the next.

    Do this
    • List every Agent Interaction node you plan to include in the workflow.
    • For each agent, list its required inputs and their sources (upstream node and field name).
    • For each agent, name the output field or fields it will produce.
    • Write down the field names you will use. Commit to a naming convention before you start building.
    Example

    A three-agent content workflow: Agent 1 ("Research") takes the user's topic brief and produces a researchSummary field. Agent 2 ("Draft") takes researchSummary and the original userBrief and produces a draftContent field. Agent 3 ("Edit") takes draftContent and produces a finalContent field. Each agent's input and output is named before any node is placed on the canvas.

    Best practice
    • Keep field names short, camelCase, and descriptive. researchSummary is better than agent1output because it describes the content, not the source.
    • Avoid reusing the same field name for different values at different stages. If Agent 1 and Agent 3 both produce a "summary", name them researchSummary and editSummary respectively. Reusing a name overwrites the earlier value and makes debugging harder.

  2. Configure the Fields section on each Agent Interaction node

    Open the Workflow Editor and place your Agent Interaction nodes on the canvas. Select the first Agent Interaction node to open the Properties Panel on the right. In the Fields section, configure the fields that this node reads from the instance context and the fields it writes back to it.

    The Fields section is available on most node types and is the primary mechanism for defining what data a node works with. For an Agent Interaction node, the fields you configure here determine what the agent receives as context when the instance reaches this node, and what named fields are available to downstream nodes after it completes.

    Repeat this configuration for each Agent Interaction node in the workflow. Each node's Fields section should reflect the context map you created in Step 1: the inputs this agent needs, and the outputs it will produce.

    Do this
    • Select the first Agent Interaction node on the canvas to open the Properties Panel.
    • Open the Fields section in the Properties Panel.
    • Configure the input fields this agent needs from the instance context.
    • Configure the output field or fields this agent will write back to the instance context.
    • Repeat for each Agent Interaction node in the workflow.
    • Use the field names from your context map (Step 1) consistently across all nodes.
    Example

    For the "Draft" agent node: in the Fields section, you configure it to read researchSummary (produced by the Research agent) and userBrief (collected by the User Interaction node). You configure it to write its output to draftContent. The "Edit" agent node is configured to read draftContent and write to finalContent.

    Best practice
    • Configure the Fields section on every Agent Interaction node, even if you think the agent will receive everything automatically. Explicit field configuration makes the data flow visible in the Properties Panel and reduces the risk of a field being missing at runtime.
    • Save a version after configuring each node's Fields section. This gives you a restore point at each stage of the configuration, not just at the end.

  3. Write system prompts that reference the instance context

    The agent's system prompt is where you tell the agent what to do with the context it receives. The system prompt is defined in the agent's Config JSON, in the systemPrompt field. It is set when you create or update an agent version on the Agents page (navigate to Agents in the sidebar, open the agent, and click Create Version).

    A system prompt that does not reference the upstream context produces an agent that ignores it. A system prompt that references the context explicitly tells the agent how to use the values passed to it from earlier steps.

    When the instance reaches an Agent Interaction node, the platform passes the instance context to the agent. The agent's system prompt defines how the agent interprets and uses that context. Write the system prompt to describe the agent's role, the context it will receive, and what it should produce.

    For a multi-agent workflow, each agent's system prompt should be scoped to its specific task. The Research agent's prompt describes research behavior. The Draft agent's prompt describes drafting behavior and references the research output it will receive. The Edit agent's prompt describes editing behavior and references the draft it will receive. Scoped prompts produce focused outputs, which are cleaner inputs for the next agent.

    Do this
    • Navigate to Agents in the sidebar. Open the agent you want to configure.
    • Click Create Version to open the version creation form.
    • In the Config JSON editor, write or update the systemPrompt field to describe the agent's role and reference the context it will receive from upstream steps.
    • Set the model and any other parameters appropriate for this agent's task.
    • Click Create Version to save. The new version is assigned the next sequential version number automatically.
    • Repeat for each agent in the workflow.
    Example

    The Draft agent's Config JSON includes: "systemPrompt": "You are a content drafter. You will receive a research summary and the user's original brief. Use the research summary as your factual foundation and the brief as your scope guide. Produce a complete first draft that addresses the brief using the research provided." This prompt tells the agent exactly what context it will receive and how to use it, without the agent needing to guess.

    Best practice
    • Name the context explicitly in the system prompt. Instead of "use the provided information", write "use the research summary provided". Explicit references produce more reliable agent behavior.
    • Keep each agent's system prompt scoped to its single task. An agent that is asked to research, draft, and edit in one step produces lower-quality output than three agents each focused on one task.
    • Use the Prompt Library (accessible from the Prompt Library tab on the Agents page) to store and reuse system prompts across agents. This is especially useful when multiple agents in different workflows share similar behavior patterns.

  4. Assign the correct agent version to each workflow node

    Each Agent Interaction node in the workflow must be assigned a specific agent and a specific version of that agent. This is configured in the Agent Assignment section of the Properties Panel when the node is selected in the Workflow Editor.

    The agent version determines which Config JSON, and therefore which system prompt and model, is used when the instance reaches that node. If you have just created a new agent version with an updated system prompt (Step 3), you need to assign that new version to the workflow node. Assigning an older version means the node uses the older system prompt, even if a newer one exists.

    An agent must have at least one non-retired version to appear in the agent selection dropdown. If an agent does not appear, open the agent detail page and confirm at least one active version exists.

    Do this
    • Select the Agent Interaction node in the Workflow Editor to open the Properties Panel.
    • Open the Agent Assignment section.
    • Select the agent from the dropdown. Only agents with at least one non-retired version appear.
    • Select the specific version you want this node to use.
    • Repeat for each Agent Interaction node in the workflow.
    • Save a new version of the workflow after assigning all agents.
    Example

    You assign the "Research" agent at v2 to the first Agent Interaction node, the "Draft" agent at v3 to the second, and the "Edit" agent at v1 to the third. Each node now has an explicit agent and version assignment. When the instance runs, each node invokes the exact version you specified.

    Best practice
    • After updating an agent's system prompt (creating a new version), update the workflow node's Agent Assignment to point to the new version. The workflow node does not automatically pick up new agent versions: the assignment is explicit and version-pinned.
    • Before retiring an old agent version, confirm that no active workflow nodes still reference it. A workflow node that references a retired version will fail when an instance reaches it.

  5. Add Information nodes to document the context design

    The Information node (indigo info icon) is a documentation and annotation node. It does not affect workflow execution: it has no effect on the instance, creates no tasks, and invokes no agents. Its only purpose is to add notes, context, or instructions directly on the canvas for the benefit of anyone who opens the workflow in the editor later.

    For a multi-agent workflow with a deliberate context design, Information nodes are the right place to document that design on the canvas itself. Drop one next to the sequence of Agent Interaction nodes and describe the context flow: what fields are passed between agents, why the sequence is ordered as it is, and what each agent is expected to produce.

    This is especially valuable for workflows that will be maintained by more than one person, or that will be revisited months after they were built. The context design that is obvious to the original author is not obvious to a future editor who needs to add a new agent step or debug a context issue.

    Do this
    • Drag an Information node from the Node Palette onto the canvas. Place it beside the sequence of Agent Interaction nodes, not in the execution path.
    • Click the Information node to open the Properties Panel.
    • Change the label to describe what the note covers, for example "Context flow: Research to Draft to Edit".
    • In the node's configuration, add the documentation text: the field names passed between agents, the expected outputs of each agent, and any design decisions that are not obvious from the graph structure alone.
    • Save a new version of the workflow to preserve the Information node.
    Example

    You drop an Information node beside the three-agent sequence and label it "Context flow". In its configuration you write: "Agent 1 (Research) writes researchSummary. Agent 2 (Draft) reads researchSummary and userBrief, writes draftContent. Agent 3 (Edit) reads draftContent, writes finalContent. Field names must match exactly across Fields sections and agent prompts." A future editor opening this workflow sees the context design without needing to open each node's Properties Panel individually.

    Best practice
    • Update the Information node whenever you change the context design. An out-of-date annotation is worse than no annotation: it misleads future editors.
    • Use one Information node per logical section of a complex workflow, rather than one large annotation for the entire graph. Smaller, positioned annotations are easier to read than a single wall of text.

  6. Save a version and test the full context chain

    When all Agent Interaction nodes are configured, all agents are assigned, and your Information nodes document the design, click Save Version in the top-right corner of the editor. This creates a new immutable version of the workflow graph.

    Run a test instance and trace the context chain through each agent step:

    1. Start the instance and provide any required user input.
    2. When the first Agent Interaction node runs, check the instance log to confirm the agent received the expected context and produced the expected output in the correct field.
    3. When the second Agent Interaction node runs, confirm it received the first agent's output field as part of its context, and produced its own output in the correct field.
    4. Continue through each agent step, verifying at each stage that the context chain is intact.

    If an agent produces an unexpected output, the most common causes are: the upstream field was not populated (check the Fields section on the upstream node), the system prompt does not reference the context correctly (check the agent's Config JSON), or the wrong agent version is assigned (check the Agent Assignment section).

    Do this
    • Click Save Version in the top-right corner. Confirm the version is saved.
    • Start a test instance with representative input.
    • After each Agent Interaction node runs, check the instance log to verify the output field was populated with the expected value.
    • Confirm each downstream agent received the upstream output as part of its context.
    • If any step fails or produces unexpected output, check the Fields section, the agent's system prompt, and the Agent Assignment section for that node.
    • Save a corrected version and retest if changes are needed.
    Example

    You run a test instance with a topic brief of "sustainable packaging trends". The Research agent runs and writes a researchSummary covering five key trends. The Draft agent runs, receives researchSummary and userBrief, and writes a draftContent field containing a structured article draft. The Edit agent runs, receives draftContent, and writes a polished finalContent field. The context chain is intact across all three steps.

    Best practice
    • Test with a real input from your actual use case, not a synthetic placeholder. Real inputs reveal context gaps that synthetic inputs miss.
    • If the context chain breaks at a specific step, isolate that step: run a minimal workflow with just the upstream node and the failing node to confirm the field is populated correctly before debugging the full chain.

How instance context works in DAVE

When a workflow instance runs, it maintains a context: a collection of named field values accumulated as the instance progresses through each node. Every node that produces output writes values into this context. Every node that needs input reads values from it.

When the instance reaches an Agent Interaction node, the platform passes the current instance context to the agent. The agent's Config JSON (specifically the systemPrompt field, along with the model and other parameters) defines how the agent processes that context and what it produces. The agent's response is written back into the instance context, where it becomes available to every downstream node.

This is the mechanism that makes multi-agent workflows possible: each agent receives the accumulated context of everything that has happened in the instance before it ran, and adds its own output to that context for the agents that follow.

The instance context is not a fixed schema. It grows as the instance progresses. A field written by the first agent is still present in the context when the third agent runs, unless it is explicitly overwritten. This means agents later in the workflow have access to the outputs of all earlier agents, not just the immediately preceding one.

The practical implication: context design is cumulative. A field named researchSummary written by the first agent is available to the second, third, and fourth agents. You do not need to pass it explicitly at each step: it persists in the instance context for the lifetime of the instance. This is what the editorial note refers to as instance-level agent memory: the instance context itself is the memory, and it accumulates across every node the instance passes through.

Workflow fields and why naming discipline matters

The Fields section in the Properties Panel is the primary configuration surface for defining what data a node works with. It appears on most node types, including Agent Interaction, User Interaction, Human Review, API Call, and Routing nodes.

For Agent Interaction nodes, the Fields section defines which named fields from the instance context the agent receives as input, and which named fields the agent's output is written to. The field names you configure here must match the field names referenced in the agent's system prompt and in the Fields sections of downstream nodes. A mismatch between the field name written by one node and the field name read by the next is the most common cause of context not flowing correctly between agent steps.

Why naming discipline matters

The instance context is a flat collection of named values. There is no automatic mapping or aliasing between field names. If Agent 1 writes its output to researchSummary and Agent 2's Fields section is configured to read research_summary (with an underscore), Agent 2 will not find the value. The field names must match exactly, including case.

Establishing a naming convention before building the workflow (Step 1 of this guide) prevents this class of error. Consistent camelCase names that describe the content (not the source) are the most readable and least error-prone convention for most teams.

Fields from non-agent nodes

Workflow fields are not only produced by Agent Interaction nodes. A User Interaction node that collects a topic brief writes that brief to a named field. An API Call node that fetches a customer record maps response values to named fields. A Human Review node that captures a reviewer's comments writes those comments to a named field. All of these fields are part of the instance context and are available to every downstream Agent Interaction node, subject to the Fields section configuration on each node.

Agent configuration and system prompts

An agent's behavior is defined by its Config JSON, which is set when a version is created on the agent detail page. The most important field in the Config JSON for context passing is systemPrompt: the instructions that define the agent's role, what context it will receive, and what it should produce.

Other Config JSON fields that affect how an agent processes context include:

  • model: The specific model to use. Different models have different context window sizes, which determines how much context they can process in a single call.
  • temperature: Controls randomness in the response. Lower values (closer to 0.0) produce more deterministic outputs, which are generally preferable when the agent is transforming or summarizing structured context rather than generating creative content.
  • maxTokens: The maximum length of the agent's response. If an agent is expected to produce a long output (such as a full article draft), ensure maxTokens is set high enough to accommodate it. A response truncated by a low maxTokens value is a common cause of incomplete context being passed to the next agent.

Agent versions are immutable once created. To update a system prompt, create a new version of the agent and assign that version to the workflow node in the Agent Assignment section of the Properties Panel. The workflow node does not automatically pick up new agent versions: the assignment is explicit.

The Prompt Library (accessible from the Prompt Library tab on the Agents page) provides a place to store and reuse system prompts across agents. For multi-agent workflows where several agents share similar behavior patterns, the Prompt Library reduces duplication and makes prompt updates easier to manage.

Using Information nodes to document context design

The Information node (indigo info icon, code information) is a documentation and annotation node. It has no effect on workflow execution: it does not create tasks, does not invoke agents, and does not affect the instance context. Its sole purpose is to add notes and context directly on the canvas.

For multi-agent workflows with a deliberate context design, Information nodes serve a specific and important function: they make the context design visible to anyone who opens the workflow in the editor, without requiring them to open each node's Properties Panel individually.

Place Information nodes beside (not in) the execution path. A node placed in the execution path (connected with edges between two other nodes) would become part of the graph and would be reached by the instance at runtime. An Information node placed beside the graph, with no incoming or outgoing edges, is purely decorative and documentary.

Useful content for an Information node in a multi-agent workflow includes:

  • The field names passed between agents and their sources.
  • The expected output of each agent and the field it writes to.
  • Any design decisions that are not obvious from the graph structure: why a particular agent is placed at this point, why a specific model was chosen, why the sequence is ordered as it is.
  • Known limitations or edge cases: inputs that may cause an agent to produce unexpected output, context size constraints, or fields that must be non-empty for the next agent to function correctly.

Frequently asked questions

Do agents automatically receive the output of the previous agent?

The instance context accumulates as the instance progresses, so the output of every preceding node is present in the context when a downstream agent runs. However, whether the agent actually uses that context depends on its system prompt and the Fields section configuration on its node. An agent whose system prompt does not reference the upstream output will not use it, even if it is present in the context. Explicit configuration and explicit system prompt references are required.

Can an agent access the output of an agent two steps back, not just the immediately preceding one?

Yes. The instance context persists for the lifetime of the instance. A field written by the first agent is still present when the third agent runs. You do not need to pass it explicitly at each step. Configure the Fields section on the third agent's node to include the first agent's output field, and reference it in the third agent's system prompt.

What happens if a required context field is missing when an agent runs?

The agent runs with whatever context is available. If a field the agent's system prompt references is missing from the context, the agent will either produce output that ignores the missing value, produce an error, or produce lower-quality output depending on how the system prompt is written. Missing fields are most often caused by a field name mismatch between the node that writes the value and the node that reads it. Check the Fields section configuration on both nodes and confirm the names match exactly.

Can I use the same agent in multiple steps of the same workflow?

Yes. The same agent (and the same version) can be assigned to multiple Agent Interaction nodes in the same workflow. Each node invokes the agent independently with the instance context at that point in the execution. The agent does not retain state between invocations within the same instance: each call is independent, and the context it receives is determined by what the instance context contains at the moment that node runs.

Who can create and update agents?

The Admin and Create roles can create agents, create versions, and retire versions. The Curate role can view agents and select them when building workflows in the editor, but cannot create or modify agents. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator.

What is the Prompt Library and when should I use it?

The Prompt Library is a collection of reusable prompt templates accessible from the Prompt Library tab on the Agents page. Use it when multiple agents across different workflows share similar system prompt patterns. Instead of writing the same prompt structure repeatedly, save it to the library and assign it to agents. When a library prompt is locked to an agent, workflow designers cannot override it in the editor, ensuring consistent agent behavior across all workflows that use that agent.