Financial market surveillance is a high-stakes domain where agents cannot afford to lose their place mid-workflow. AWS published a production architecture that combines LangGraph for state-driven orchestration, Strands for agent reasoning, and AgentCore for memory and observability. The result is a multi-agent system that can resume compliance checks after failures without re-processing market data or duplicating database writes.
This is not a demo. The architecture exposes how checkpoint-based recovery works, what state machines buy you over prompt chains, and how AgentCore memory primitives create audit trails that regulators can actually review.
Why State Machines Matter for Compliance Workflows
Prompt chains execute linearly. You send a prompt, get a response, send another prompt. If the process crashes between steps, you start over. For market surveillance, that means re-fetching trade data, re-running anomaly detection, and re-writing alerts to the compliance database.
LangGraph models workflows as state machines. Each node represents a discrete step (fetch trades, detect anomalies, generate alerts). Edges define transitions. The orchestrator stores state at every transition, so when a failure occurs, the agent resumes from the last successful checkpoint instead of restarting from scratch.
Key differences:
| Approach | State Persistence | Recovery Behavior | Idempotency Requirement |
|---|---|---|---|
| Prompt chain | None | Restart from beginning | High (every step must be safe to repeat) |
| LangGraph state machine | Checkpoint after each node | Resume from last checkpoint | Low (only failed node repeats) |
Checkpoint-Based Recovery: What Gets Stored
A checkpoint is not just a log entry. It is a serialized snapshot of the agent’s working memory at a specific point in the workflow. For the market surveillance agent, a checkpoint includes:
- Workflow position: Which node just completed, which node is next.
- Intermediate data: Trade records fetched, anomaly scores calculated, alert payloads generated.
- Tool call results: API responses from market data feeds, database write confirmations.
- Decision context: Why the agent chose a specific branch (e.g., flagged a trade for manual review vs. auto-clearing it).
When the agent crashes, the orchestrator reads the most recent checkpoint, reconstructs the state machine, and resumes execution at the next node. The agent does not re-fetch trades or re-run anomaly detection. It picks up where it left off.
Architecture: LangGraph, Strands, and AgentCore
The AWS architecture splits responsibilities across three layers:
LangGraph (Orchestration Layer)
Defines the state machine. Nodes represent tasks like fetch_trades, detect_anomalies, generate_alerts. Edges define conditional transitions based on agent decisions. LangGraph handles checkpoint serialization and recovery.
Strands (Reasoning Layer)
Provides the agent reasoning primitives. Strands agents decide which compliance rules to apply, how to score anomalies, and whether to escalate alerts. Strands integrates with LangGraph nodes as tool-calling functions.
AgentCore (Memory and Observability Layer)
Stores checkpoints, logs tool calls, and exposes decision trails for audit. AgentCore memory primitives let you query why an agent flagged a specific trade, which rules it applied, and what data it used. This is critical for regulatory review.
from langgraph.graph import StateGraph
from strands import Agent
from agentcore import Memory, Checkpoint
# Define state schema
class SurveillanceState:
trades: list
anomalies: list
alerts: list
checkpoint_id: str
# Define nodes
def fetch_trades(state: SurveillanceState):
trades = market_data_api.get_recent_trades()
state.trades = trades
return state
def detect_anomalies(state: SurveillanceState):
agent = Agent("anomaly-detector")
anomalies = agent.run(state.trades)
state.anomalies = anomalies
return state
def generate_alerts(state: SurveillanceState):
alerts = [create_alert(a) for a in state.anomalies]
state.alerts = alerts
compliance_db.write(alerts)
return state
# Build state machine
workflow = StateGraph(SurveillanceState)
workflow.add_node("fetch", fetch_trades)
workflow.add_node("detect", detect_anomalies)
workflow.add_node("alert", generate_alerts)
workflow.add_edge("fetch", "detect")
workflow.add_edge("detect", "alert")
# Enable checkpointing
memory = Memory(backend="agentcore")
checkpointer = Checkpoint(memory)
workflow.set_checkpointer(checkpointer)
# Run workflow
result = workflow.run()If the workflow crashes after detect_anomalies, the orchestrator reads the checkpoint, sees that state.anomalies is populated, and jumps directly to generate_alerts. No re-fetching, no re-scoring.
AgentCore Memory Primitives for Audit Trails
Regulators do not care about your agent’s accuracy. They care about explainability. When an agent flags a trade for insider trading, compliance officers need to know:
- Which market data the agent used.
- Which rules it applied.
- Why it scored the trade as anomalous.
- What threshold triggered the alert.
AgentCore memory primitives store this context alongside checkpoints. Each tool call logs its inputs, outputs, and reasoning trace. You can query the memory store to reconstruct the agent’s decision path.
Example query:
memory.query(
checkpoint_id="chk_abc123",
node="detect_anomalies",
filters={"trade_id": "TRD-9876"}
)Response:
{
"tool_calls": [
{
"tool": "anomaly_scorer",
"input": {"trade": "TRD-9876", "volume": 50000, "price": 142.50},
"output": {"score": 0.87, "threshold": 0.75},
"reasoning": "Volume 3x daily average, price 2% above VWAP"
}
],
"decision": "flag_for_review",
"timestamp": "2026-07-28T14:32:11Z"
}This is what makes the architecture production-ready. The agent does not just generate alerts. It generates auditable evidence.
Failure Modes and Observability
Even with checkpoints, things break. The market data API times out. The anomaly detection model returns NaN. The compliance database rejects a write.
LangGraph exposes failure modes at the node level. If fetch_trades fails, the orchestrator logs the error, retries with exponential backoff, and checkpoints the failure state. If retries exhaust, the workflow halts and alerts the operations team.
AgentCore observability hooks let you monitor:
- Checkpoint frequency: How often the agent saves state (high frequency = more recovery points, higher storage cost).
- Node latency: Which steps are slow (useful for identifying bottlenecks).
- Tool call failures: Which external APIs are flaky.
- State size: How much data the agent carries between nodes (large state = slower checkpointing).
You can set alerts on checkpoint write failures. If the memory backend is down, the agent cannot recover from crashes. That is a critical failure.
Deployment Shape on Amazon Bedrock
The AWS architecture deploys the agent on Amazon Bedrock AgentCore, which provides:
- Managed memory backend: No need to run your own checkpoint store.
- Integrated observability: Logs, traces, and metrics flow to CloudWatch.
- IAM-based access control: Agents cannot read each other’s checkpoints.
- Encryption at rest: Checkpoints contain sensitive trade data.
The deployment uses Lambda for node execution and Step Functions for orchestration fallback. If LangGraph crashes, Step Functions can resume the workflow using the last checkpoint.
When to Use This Architecture
Use it when:
- You need multi-step workflows that cannot afford to restart from scratch on failure.
- You operate in a regulated domain where audit trails are mandatory.
- Your agents make decisions that require explainability (financial compliance, healthcare, legal).
- You need to resume workflows after infrastructure failures without data loss.
Avoid it when:
- Your workflows are stateless (simple question-answering, one-shot generation).
- Checkpoint storage costs outweigh the cost of re-running the workflow.
- You do not need observability beyond basic logs.
- Your agents do not call external APIs or write to databases (no idempotency risk).
Technical Verdict
LangGraph state machines and AgentCore checkpoints solve the resume-from-failure problem for multi-agent workflows. The architecture is production-ready for financial compliance because it treats state persistence and observability as first-class concerns, not afterthoughts.
The trade-off is complexity. You now manage checkpoint storage, monitor state size, and tune checkpoint frequency. For high-stakes domains where re-running a workflow means re-processing millions of trades or duplicating compliance alerts, that complexity is worth it.
For simpler workflows, prompt chains with retry logic are cheaper and easier to debug. Know the difference.