How is state passed between workflow nodes?

State is passed between workflow nodes through a shared, structured workflow state that the orchestration runtime makes available to each node. A node reads the fields it needs, performs its work, and returns updates. The runtime applies those updates before the next dependent node runs.

Example: An API test-generation workflow

Suppose a workflow has three nodes:

1. Requirements node: Reads an API specification and produces endpoint-specific requirements.
2. Test-generation node: Reads those requirements and produces proposed test cases.
3. Validation node: Reads the requirements and test cases, then records coverage gaps or a passing result.

The information flows as:

Initial state → Requirements node → Updated state → Test-generation node → Updated state → Validation node

For example, the state might start with endpoint = /orders/{id}. The first node adds requirements. The second adds test_cases, preserving the requirements. The third adds validation_status and any missing_coverage.

How is this implemented in LangGraph?

In a LangGraph-style state graph:

• A state schema defines fields such as endpoint, requirements, test cases, and validation status.
• Each node receives the current state as input.
• A node usually returns a dictionary of state updates rather than manually sending its output to every downstream node.
• The framework merges those updates according to each field's configured update or reducer behavior.
• The next eligible node reads the resulting state.

Conceptually:

PYTHON
from typing import TypedDict

class TestState(TypedDict, total=False):
    endpoint: str
    requirements: str
    test_cases: list[str]
    validation_status: str

def generate_tests(state: TestState):
    cases = build_test_cases(state["requirements"])
    return {"test_cases": cases}

Here, generate_tests updates only test_cases. It does not need to recreate the existing endpoint or requirements fields.

What if nodes execute in parallel?

Parallel branches may return updates at the same time. If they update different fields, those updates can often be combined directly. If they write the same field, the workflow must define an appropriate reducer or merging rule; otherwise conflicting concurrent updates can fail or produce incorrect results.

For example, security-test and input-validation branches can write to separate fields, or append to a shared collection using a properly configured reducer.

What about Celery or separate workers?

A local graph runtime can pass state internally. When workflow steps run in separate processes or workers, the orchestrator needs a reliable way to serialize, persist, and retrieve the required state or artifact references. A Celery task's return value alone does not automatically become another graph node's shared state.

Large files should normally be stored externally, with their identifiers passed through state rather than repeatedly copying their full contents.

Best practices

• Define clear, typed contracts for the state fields that nodes read and write.
• Return focused updates rather than accidentally replacing unrelated state.
• Use stable run identifiers to isolate concurrent users and workflow executions.
• Configure merge rules for fields written by parallel branches.
• Checkpoint important state for reliable recovery.
• Avoid putting secrets or unnecessary sensitive data into persisted state.

In short

Nodes communicate by reading and updating the workflow's state. The orchestration runtime carries those updates forward, allowing later nodes to use earlier results without tightly coupling every step to the next.