11. Specialized Worker Agents

Worker agents are compiled subgraphs that encapsulate a specific capability. Each worker is a create_react_agent (or custom graph) with its own toolset, and the team supervisor treats it as an opaque callable. Workers read from shared state and write results back—this is the only communication contract.

researcher_tools = [web_search, extract_content, save_to_vector_db]
researcher = create_react_agent(
    model=llm,
    tools=researcher_tools,
    state_schema=PartialableTeamState  # allows partial updates
)

coder_tools = [read_file, write_file, run_bash, run_tests]
coder = create_react_agent(
    model=llm,
    tools=coder_tools,
    state_schema=PartialableTeamState
)

To embed a worker in the team graph, use add_node with the compiled researcher or coder app directly. LangGraph will invoke that app as a subgraph, passing the team state in and receiving updated state out.

team_builder.add_node("researcher", researcher)
team_builder.add_node("coder", coder)

Workers should be idempotent: if a worker is called twice with the same input, it should produce the same output. This matters because the supervisor might decide to re-run a worker if a later step encounters an error. Workers that are not idempotent create non-deterministic multi-agent runs that are difficult to reproduce and debug.

The failure mode: workers that depend on shared mutable state (like a global variable) break when invoked as subgraphs because the subgraph runs in its own state context. All worker state must flow through the shared state dict. Workers should not reference external globals directly.

Local verification checkpoint

Run the smallest example from this chapter in a local workspace and record the package version, runtime, data path, and observed output. If the result depends on model size, vector count, CPU/GPU backend, or available memory, note that constraint beside the exercise so the lesson remains reproducible.