Source library / Guides

LangGraph Multi Agent Example: Track Cost Across Agents, Tools, and Customers

A production-minded LangGraph multi agent example with supervisor routing, specialist agents, shared state, cost telemetry, customer attribution, tool usage, and privacy-safe metadata.

Short answer

A production LangGraph multi agent example should show a coordinator or supervisor, specialist agents, shared state, conditional routing, stable node names, and usage events for every supported model call or billable tool call. The useful version does not stop at a demo graph. It preserves customer ID, run ID, graph node, model, token usage, latency, status, retries, and opt-in tool usage so the workflow can support cost tracking, budget controls, and billing-ready records.

Query paths

- Show me a LangGraph multi agent example
- How do I build a LangGraph supervisor workflow?
- How do I track cost across LangGraph agents and tools?
- How should LangGraph multi-agent systems preserve customer context?
- Should I use langgraph-supervisor or StateGraph for new work?

On this page

Direct Answer For AI Agent Builders

A LangGraph multi-agent example usually combines a coordinator or supervisor with specialist agents that handle research, support, tool execution, or final response formatting. LangGraph is a good fit when the workflow needs shared state, conditional routing, retries, streaming, human review, memory, or durable execution across multiple steps.

For cost tracking, the design rule is simple: every node that calls a model or a billable tool should emit a usage record with stable customer and node context. That turns a tutorial graph into operating data for margin review, budget controls, and billing-ready usage.

A customer support request may need routing, external research, internal RAG, tool calls, and a final answer. Each step can have a different cost profile, so the graph needs shared identifiers from the first user message to the final response.

This is not a claim that every multi-agent system should use the same architecture. A single agent with tools is often enough for simple workflows. Tracing explains execution. Cost tracking applies pricing, customer attribution, and billing logic to trusted usage facts.

Use stable node names such as supervisor_agent, research_agent, support_agent, tools_agent, and final_response.
Pass customer_id, workspace_id, run_id, and workflow_name before the first graph step runs.
Report usage facts from model and billable tool calls. Keep pricing logic server-side.
Do not send prompts, completions, raw messages, tool arguments, or tool outputs into cost telemetry.

The Example Architecture

The workflow is a SaaS support graph. A customer asks a question, the supervisor chooses one or more specialist agents, and the final response node synthesizes the answer.

The LangGraph Graph API centers on shared state, nodes, and edges. That maps well to cost attribution because the same state can carry customer, workspace, run, and workflow identifiers across every branch.

Supervisor Or Router Node

The supervisor node classifies the customer request and chooses the next node. It might route a billing question to support_agent, a documentation question to research_agent, or a tool-heavy task to tools_agent.

This node has its own cost. If routing uses an LLM, track it as supervisor_agent, not as a vague background call.

Research Agent

The research agent handles external lookup, documentation search, or web search. It may call a model, a search API, and a document retrieval tool.

That combination makes it a common source of hidden cost. Track both token usage and paid tool usage so the team can see when research dominates a customer run.

Support Agent

The support agent answers from internal knowledge. It might use a RAG pipeline, vector database, or customer-specific context.

For cost attribution, this agent should include the customer ID, workspace ID, workflow name, graph node, model, token usage, retrieval cost, latency, and status.

Tool Agent

A ReAct-style tool agent can loop through model calls and tool calls before producing a result. This is useful for complex tasks, but it can multiply cost quickly.

Track tool_call_count, retry_count, and usage_missing separately. A successful final answer can still hide an expensive path.

Final Response Node

The final response node formats specialist outputs into a customer-facing answer. It often looks cheap, but long context from prior agents can inflate input tokens.

Give this node a stable name like final_response so it can be compared across deploys, prompts, and model changes.

The Example Architecture table
Node	Responsibility	Cost data to report
supervisor_agent	Route the message to the right specialist node.	Model, tokens, latency, route, status, run ID.
research_agent	Use search, docs, or external data to find context.	Model, tokens, search calls, retrieval calls, status.
support_agent	Answer from internal knowledge and customer context.	Model, tokens, retrieval usage, customer ID, graph node.
tools_agent	Run ReAct-style tool loops for complex tasks.	Tool call count, retries, model usage, usage_missing.
final_response	Format specialist outputs into the user-facing answer.	Model, tokens, latency, status, output step name.

Current LangGraph Pattern Choices

There are several ways to build a multi-agent workflow in the LangChain and LangGraph ecosystem. The right choice depends on how much control you need over graph state, subagent isolation, and handoffs.

StateGraph With Conditional Edges

Use a raw StateGraph when you want explicit nodes, typed state, and conditional edges. This is the clearest pattern for cost attribution because every node is named in code and can be mapped to a cost step.

The official LangGraph workflows and agents guide covers routing, parallelization, and orchestrator-worker patterns. Those patterns are useful when different nodes can run independently or when a supervisor needs to delegate subtasks.

Subagents As Tools

Current LangChain docs describe subagents as a pattern where a main agent coordinates specialist subagents by calling them as tools.

For cost tracking, the same rule applies: the main agent, each subagent call, and each billable tool call should carry customer and run metadata.

About LangGraph Supervisor Packages

Older examples often use langgraph-supervisor and create_supervisor. Current LangChain documentation says that package is no longer actively maintained and points teams toward the subagents pattern.

If you already run a legacy supervisor graph, you can still use the cost model in this guide. For new production work, prefer the maintained LangGraph and LangChain patterns that match your runtime.

The practical decision rule is to choose the simplest maintained pattern that preserves the business context you need. If the workflow has a small number of deterministic branches, a StateGraph with conditional edges is easier to inspect and attribute. If you need many specialist workers with isolated context windows, subagents-as-tools may fit better.

Shared State For Customer And Run Attribution

The shared state is where the cost story starts. If the first user input does not carry a stable customer ID and run ID, every downstream cost record becomes harder to trust.

A practical state shape includes messages, customer_id, workspace_id, run_id, workflow_name, and the routing decision. Add plan_tier or environment only if they are safe, controlled labels.

Stable Identifiers

Use opaque account, workspace, organization, or tenant IDs. Do not use emails, phone numbers, raw names, prompt text, or user messages as cost metadata.

Stable IDs let finance and product compare margin without exposing private customer content to the telemetry layer.

Stable Node Names

Use stable names such as supervisor_agent, research_agent, support_agent, tools_agent, and final_response.

Changing node names every deploy breaks trend analysis. Treat node names like an analytics taxonomy, not like casual comments in code.

Define The State And Nodes

This simplified example uses explicit StateGraph nodes. It keeps the architecture readable and avoids depending on deprecated supervisor helpers.

Real applications should add error handling, model configuration, checkpointers, and tests around every node.

Python StateGraph nodes with shared customer state

import os
from typing import Literal, TypedDict
from langgraph.graph import StateGraph, START, END
from pylva.langchain import PylvaCallbackHandler

class SupportState(TypedDict):
    messages: list
    customer_id: str
    workspace_id: str
    run_id: str
    route: Literal["research_agent", "support_agent", "tools_agent", "final_response"]
    answer_parts: list[str]

def supervisor_agent(state: SupportState):
    route = route_with_llm(state["messages"])
    return {"route": route}

def research_agent(state: SupportState):
    result = run_research_tools(state["messages"])
    return {"answer_parts": [result.summary]}

def support_agent(state: SupportState):
    result = answer_from_internal_docs(state["messages"])
    return {"answer_parts": [result.answer]}

def tools_agent(state: SupportState):
    result = run_react_tools(state["messages"])
    return {"answer_parts": [result.output]}

def final_response(state: SupportState):
    return {"messages": [format_answer(state["answer_parts"])]}

Wire The Graph

The graph starts at supervisor_agent, routes to one specialist node, and then ends at final_response. The important cost-tracking detail is that the node names are stable and visible.

Compile the graph before invoking it. That keeps the runtime path explicit and makes route-level attribution easier to reason about in tests.

Python StateGraph routing

builder = StateGraph(SupportState)
builder.add_node("supervisor_agent", supervisor_agent)
builder.add_node("research_agent", research_agent)
builder.add_node("support_agent", support_agent)
builder.add_node("tools_agent", tools_agent)
builder.add_node("final_response", final_response)

builder.add_edge(START, "supervisor_agent")
builder.add_conditional_edges(
    "supervisor_agent",
    lambda state: state["route"],
    {
        "research_agent": "research_agent",
        "support_agent": "support_agent",
        "tools_agent": "tools_agent",
        "final_response": "final_response",
    },
)
builder.add_edge("research_agent", "final_response")
builder.add_edge("support_agent", "final_response")
builder.add_edge("tools_agent", "final_response")
builder.add_edge("final_response", END)

graph = builder.compile()

Invoke With Cost Context

Invoke the graph with stable customer and run context, then attach the Pylva callback handler through the LangChain callback path.

The Pylva LangGraph SDK docs explain how the callback reads supported LangChain usage metadata, preserves LangGraph run IDs, and uses LangGraph node metadata as step attribution.

Python invocation with callback metadata

handler = PylvaCallbackHandler(api_key=os.environ["PYLVA_API_KEY"])

graph.invoke(
    {
        "messages": [{"role": "user", "content": "Why did my usage spike?"}],
        "customer_id": "cust_acme",
        "workspace_id": "workspace_prod",
        "run_id": "run_123",
        "route": "support_agent",
        "answer_parts": [],
    },
    config={
        "callbacks": [handler],
        "metadata": {
            "pylva_customer_id": "cust_acme",
            "langgraph_node": "support_workflow",
        },
    },
)

Cost Data To Capture From Each Agent Step

Each model call and billable tool call should produce a structured usage fact. The event should be small enough to emit everywhere and specific enough for finance review later.

Minimum useful fields include customer ID, workspace ID, run ID, parent run ID, graph node, step name, provider, model, tokens in, tokens out, latency, status, and retry count.

LLM Usage Fields

For model calls, capture provider, model, input tokens, output tokens, latency, status, run ID, parent run ID, and graph node.

If the provider does not return usage metadata, record usage_missing=true instead of estimating from prompt text.

Tool Usage Fields

For billable tools, capture tool name, metric, metric value, customer ID, run ID, graph node, and status.

A search API might report metric=calls and metric_value=1. A speech tool might report characters or seconds. A vector database might report queries or rows scanned.

Pricing Fields Stay Server-Side

Application code should report usage facts, not final dollars. This is the same principle behind report usage, not cost: runtime code reports facts, while the backend owns pricing logic.

Node-By-Node Cost Attribution Example

For one customer support run, the useful question is not only how many tokens the run used. It is which node created the cost, which customer caused it, and whether the workflow path was expected.

Node-By-Node Cost Attribution Example table
Node	What happened	Usage to record	Why it matters
supervisor_agent	Routed the request.	Model, tokens, latency, route.	Shows routing overhead.
research_agent	Called search and summarized results.	Model, tokens, search calls, status.	Often drives external API cost.
support_agent	Queried internal docs.	Model, tokens, retrieval calls.	Connects RAG cost to customer support.
tools_agent	Ran a ReAct loop.	Model, tokens, tool calls, retries.	Shows loop and retry cost.
final_response	Formatted the answer.	Model, tokens, latency.	Captures synthesis cost.

Tool Calls And Non-LLM Costs

Multi-agent graphs often hide cost outside the model provider. Web search, vector databases, enrichment APIs, speech services, browser automation, and internal workflow runners may all carry their own pricing.

Do not force every tool into token accounting. Report non-LLM usage with the metric that matches the tool.

Billable tools should be explicit. If a tool charges by search, row, character, second, or API request, emit a separate usage event with a controlled tool_name. This is where non-LLM cost tracking becomes part of the LangGraph cost picture instead of a spreadsheet cleanup task.
Non-billable tools should stay out of the cost ledger. Internal pure functions, deterministic formatters, and simple cache lookups may not need cost lines.

Why Token Counts Alone Are Not Enough

Token tracking is necessary, but it is not enough for multi-agent systems. Two runs can use similar token totals while taking very different paths through the graph.

A short support run may route directly to support_agent. A harder case may route to research, RAG, tools, and final response, with retries in between.

Message History And Context Strategy

If each agent receives full prior history, later nodes may pay for every intermediate message and tool result. If subagents receive isolated task inputs and return concise outputs, the supervisor context can stay smaller.

That is useful, but it must be measured rather than assumed.

Parallel Branches And Retries

Parallel branches can improve latency, but they create several events for one user request. Retries can do the same.

Track retry count and branch-level node cost so the team can tell the difference between a valuable parallel path and an expensive failure mode.

How Pylva Fits A LangGraph Multi-Agent Workflow

Pylva is SDK-first cost infrastructure for AI agent companies. In a LangGraph workflow, the callback path records cost-shaped usage metadata rather than raw content.

Use LangGraph tracing to understand execution, then use LangGraph cost tracking when the same graph needs customer-level cost records, budget workflows, and billing-ready usage.

What Pylva Records

Pylva records model, provider, token usage, latency, status, run IDs, parent run IDs, customer ID, and step attribution when those fields are available.

Tool-call usage is opt-in because many tools are not billable. When enabled, tool events can report configured metrics such as calls.

What Pylva Does Not Record

Pylva is designed for cost-shaped telemetry. It does not need prompts, completions, raw messages, tool arguments, or tool outputs to calculate cost.

That boundary matters for multi-agent systems because agents often handle sensitive customer context, retrieved documents, and internal tool payloads.

Privacy And Metadata Boundaries

Keep private content out of cost metadata. Use safe identifiers and controlled labels instead of raw user text.

Privacy And Metadata Boundaries table
Metadata class	Examples	Guidance
Good metadata	customer_id, workspace_id, run_id, graph_node, workflow_name, model, provider, status, tool_name, retry_count.	Safe controlled labels and numeric usage values.
Unsafe metadata	Emails, phone numbers, prompt text, generated answers, raw documents, SQL queries, payment data, full tool arguments.	Keep out of cost telemetry and leave in the systems that own the content.

Production Checklist

Before publishing a multi-agent LangGraph workflow, check the cost path as carefully as the answer path.

Confirm every model-calling node has a stable name.
Confirm every run includes a stable customer ID and run ID.
Confirm every event has status, model, provider, tokens, and run context when available.
Confirm billable tools are opt-in and non-billable tools do not create cost lines.
Confirm missing usage is marked as missing rather than guessed.
Confirm only one instrumentation path is active for the same runtime.
Review cost by graph_node, customer, and run every week until the workflow stabilizes.

Budget Controls And Guardrails

Once usage is trustworthy, teams can add budget controls. A guard node or middleware check can inspect customer spend, plan tier, or run cost before the next expensive call.

Useful guardrails include a per-run token budget, a per-customer monthly cap, a limit on search calls per run, or routing to a cheaper model after a threshold.

Budget enforcement should degrade gracefully. If enforcement state is unavailable, teams need a deliberate product decision about whether to warn, fail open, or stop the call. For runtime control patterns, see pre-call budget enforcement.

Common Pitfalls

The most common mistake is treating a multi-agent demo as production-ready because it returns the right answer. Production readiness also means stable attribution, privacy-safe metadata, and clean failure behavior.

Another mistake is optimizing only for average cost. Average cost hides the exact customer, graph node, or tool path that creates margin pressure.

Double counting happens when provider instrumentation and LangGraph callbacks both record the same call. Choose one instrumentation path per runtime.
Double counting can also happen when a tool result is counted as a second model call. Keep LLM events and tool events separate.
Unstable graph_node names across deploys make cost trends hard to trust. Use a naming convention and review it like an analytics contract.

How This Supports The LangGraph Funnel

This supporting page answers the top-of-funnel question: show me a LangGraph multi agent example. The next buyer question is whether that example can run in production without hiding cost.

Readers who need execution visibility should continue with LangGraph tracing. Readers who need cost attribution by customer, node, run, and tool call should continue to LangGraph cost tracking.

For adjacent workflows, the same schema connects to LLM orchestration monitoring, per-customer AI cost attribution, and LLM cost tracking for AI agents.

Conclusion: From Example To Production-Ready Cost Visibility

A LangGraph multi agent example becomes production-ready when the graph can explain its own cost. The architecture should show who routed the request, which specialist agents ran, which tools were called, what each node cost, and which customer created the usage.

For AI agent builders, that is the path from a useful example to a business system: trace the graph, report usage facts, preserve customer and node context, and move qualified readers toward customer-level LangGraph cost tracking.

FAQ

Frequently Asked Questions

What is a LangGraph multi-agent example?

A LangGraph multi-agent example is a graph or agent workflow where a coordinator routes work to specialist agents such as research, support, tool execution, and final response formatting. In production, each node should carry customer and run context.

How do I track cost in a LangGraph multi-agent system?

Instrument the LangGraph callback path or your chosen runtime instrumentation so every model and billable tool call emits customer ID, run ID, graph node, provider, model, tokens, latency, status, and retry context.

Can I track cost by LangGraph node?

Yes. Use stable LangGraph node names and preserve node metadata as step attribution. Pylva uses LangGraph node metadata when available so cost can group by graph step.

Should I use langgraph-supervisor for new work?

Be careful. Current LangChain documentation says the langgraph-supervisor package is no longer actively maintained and points teams toward subagents. Existing projects can still apply the cost-tracking ideas here, but new projects should choose maintained patterns.

Are tool calls billed separately?

Only if the tool has real cost and your pricing model treats it as billable usage. Otherwise, keep the tool in traces but do not create a cost line.

Is token tracking enough?

No. Token tracking misses customer attribution, graph node attribution, retries, non-LLM tools, status, and missing-usage data. Multi-agent cost tracking needs all of those fields.

What should not be sent as metadata?

Do not send prompts, completions, raw messages, tool arguments, documents, emails, phone numbers, or payment data. Use safe identifiers and controlled labels.

What is the next step after this example?

Instrument one production LangGraph workflow, verify the event shape, then connect it to customer-level reporting, budget controls, and the LangGraph cost tracking workflow.