Building an integrated agent orchestrator with LangChain, LangGraph, and Temporal

Last quarter, our algorithmic execution desk migrated its multi-step portfolio rebalancing agent from a standalone LangGraph deployment to a hybrid architecture orchestrated by Temporal.

In our high-frequency execution pipelines, pure C++ handles order routing. But for our slower, multi-hour macro rebalancing loops—which require parsing news sentiment, analyzing order book depth, generating trading plans via LLMs, and seeking manual compliance sign-off for large block trades—we rely on agentic workflows.

Initially, we built this logic entirely within LangGraph. It is a fantastic framework for modeling cyclic agent interactions, tool-calling loops, and local state transitions. But as we scaled up trade sizes, we hit a wall of production failures. In-flight agent state would vanish during Kubernetes pod evictions. Long-running tool calls would timeout, leaving us in an indeterminate state where we could not tell if an order had been filled, partially filled, or rejected.

By integrating LangGraph as the “cognitive engine” inside a Temporal “durable execution” workflow, we achieved absolute fault tolerance without sacrificing the flexible, cyclic reasoning capabilities of our LLM agents.

The structural mismatch in agent execution

When building production-grade agents, we are forced to handle three hard distributed system problems:
1. Durable State: The agent’s conversation history and decision path must survive infrastructure restarts.
2. Durable Timers: If an API rate limit forces a 30-minute backoff, or if we must wait 4 hours for liquidity to pool, the execution context must remain active without consuming memory or blocking threads.
3. Deterministic Execution & Replay: If a node crashes mid-execution, we must be able to reconstruct the exact state of the workflow without re-running non-idempotent tool actions (like double-submitting a sell order).

LangGraph provides state persistence via checkpointers (like MemorySaver or PostgresSaver). However, LangGraph’s engine executes within the application process. If your runner pod crashes during a node execution, the step does not automatically recover on another node; you have to manually resume it from the last saved checkpoint.

More importantly, LangGraph does not natively solve the fallible tool problem. If an agent calls a tool to execute a trade, and the connection drops before a response is received, LangGraph cannot natively orchestrate complex retry policies with exponential backoff, circuit breaking, and human-in-the-loop signals at the framework level.

Temporal, on the other hand, is built specifically for durable execution. It uses event sourcing to replay workflows, guarantees at-least-once execution, and provides robust mechanisms for signals, queries, and long-running activities. But writing complex cyclic graphs, message histories, and dynamic LLM tool-calling loops directly in Temporal is incredibly verbose and painful to maintain.

The solution is a hybrid architecture: LangGraph manages the micro-level cognitive loops (agent state transitions, tool decisions), while Temporal manages the macro-level execution context (durable timers, activity execution, manual intervention signals, and transactional boundaries).

System Architecture

The workflow starts when a portfolio manager or automated signal triggers a rebalancing request. The orchestration pipeline uses Temporal to manage the transaction, while LangGraph determines the optimal split of trades across multiple liquidity pools.

flowchart TD
 Client["Client App"]
 Workflow["Temporal Workflow"]
 ApprovalSignal["Approval Signal"]
 AgentActivity["LangGraph Agent Activity"]
 ExecutionTool["Execution Tool"]
 Database["Postgres State Store"]

 Client -->|"Execute Trade"| Workflow
 Workflow -->|"Spawn"| AgentActivity
 AgentActivity -->|"Requires Approval"| ApprovalSignal
 ApprovalSignal -->|"Resume"| AgentActivity
 AgentActivity -->|"Call Tool"| ExecutionTool
 AgentActivity -->|"Save Checkpoint"| Database

To prevent the Temporal History size from exploding, we do not pass the entire LLM raw message history through Temporal’s workflow state. Temporal enforces a 2MB payload limit, and large prompt contexts can easily breach this during long runs. Instead, we persist the LangGraph state in an external Postgres instance, and pass only the session_id and the targeted trade_action_id within the Temporal payload.

The Code

Below is the complete implementation of our integrated agent orchestrator. It sets up a LangGraph agent that decides how to split a large block trade, a Temporal Workflow that manages the lifecycle and pauses for human confirmation when trade value exceeds $100,000, and a Temporal Worker that runs the execution loop.

1. The Cognitive Layer: LangGraph Agent

First, let’s define our agent. It takes a list of execution venues, evaluates a balance request, and outputs a execution plan.

2. The Durability Layer: Temporal Workflows & Activities

Now we define our Temporal code. We wrap the LangGraph agent execution inside a Temporal Activity. If the agent signals that a manual approval is required, the Temporal workflow yields, registers an external signal handler, and safely pauses without holding any CPU or threads active.

3. Running the Infrastructure

To hook everything up, we require a Postgres instance running (configured via the connection string) and a running Temporal service. Below is the entry point script to run the Temporal worker and run a mock execution loop.

And here is the script we use to dispatch a workflow, check if it hits compliance, and send an approval signal.

Production Execution Logs

When you run run_worker.py and then trigger dispatch_trade.py, you will see how cleanly the processing boundaries are maintained:

Performance and Reliability Results

In our local test environment, we simulated system crashes, database disconnects, and heavy network failures to compare the standalone LangGraph system against our hybrid setup.

Architecture Lessons

Lesson 1: Separate the Payload State from the Agent State

Initially, we made the mistake of dumping the complete conversational chat history and state dict into Temporal’s workflow payload. If your state contains multi-megabyte contextual documents, the Temporal payload parser will degrade workflow execution performance and trigger schema validation exceptions.

Always serialize the large chat message histories directly in a persistent store (e.g., PostgreSQL, MongoDB, Redis) inside the Activity and exchange only lightweight transactional references (IDs and status fields) in the Temporal Workflow level.

Lesson 2: Keep Activities Completely Idempotent

Because Temporal relies on event replay to rebuild state on workflow engine crashes, any activity that performs an external API operation (e.g. calling an exchange API, sending an SMS) must be structured to accept execution IDs and support idempotent lookups. If a step executes but the worker crashes before sending the success acknowledgment back to Temporal, the rescheduled worker will re-run the same activity. Always implement strict idempotency keys (idempotency_key = f"{workflow_id}_{activity_id}") on downstream payment and exchange routes.