LangGraph can express stateful workflows, persist checkpoints, pause for human approval, resume a thread, stream output, retry durable runs, and deploy through LangSmith Cloud, a standalone Agent Server, or a self-hosted LangSmith platform. LangSmith can trace requests, evaluate production traffic, collect feedback, and alert on aggregate signals. Those controls do not decide who owns a queue backlog, exhausted PostgreSQL connections, an interrupt resumed twice, a tool that committed before approval, an evaluator that missed a client-specific regression, or a graph that completed while the target business state remained wrong.
Datrick provides an ongoing operating layer for an agreed LangGraph estate. Named engineers correlate client requests, assistants, threads, runs, checkpoints, state, interrupts, queues, API workers, PostgreSQL, Redis, traces, evaluators, model providers, retrieval, tools, external-system audits, releases, cost, and business outcomes. LangChain Support remains the escalation path for platform defects. Datrick owns the client-specific diagnosis, containment, validation, communication, change, and prevention accepted in the service boundary.
Do you have LangGraph agents in production but no team accountable for turning a stuck run, missing checkpoint, queue backlog, repeated side effect, trace regression, or provider incident into a verified outcome? Start with one representative portfolio.
Define ownership across graph code, Agent Server, state, providers, tools, and outcomes
A production path can include a web, mobile, chat, API, or event client; load balancer and authentication; Agent Server API replicas and queue workers; graph or functional API code; assistants, threads, runs, checkpoints, long-term memory, cron jobs, and interrupts; PostgreSQL and Redis; LangSmith tracing and evaluation; model and embedding providers; retrieval stores; internal or external tools; and the target system that creates the actual outcome. Name which layers the managed service owns, observes, changes, coordinates, or excludes.
Document Cloud, standalone, or self-hosted deployment; regions and clusters; agents and versions; traffic and concurrency; API and queue capacity; Postgres, Redis, blob storage, and ClickHouse where applicable; thread and trace retention; tools and identities; support hours; severity; quality bars; change authority; budgets; fallback; and vendor escalation.
Operate the complete LangGraph production surface
| Service area | Managed responsibility | Boundary to define |
|---|---|---|
| Agent Server and queues | Availability, API latency and errors, streaming, run creation, queue depth and age, worker concurrency, heartbeat, retries, sweeper recovery, cancellation, and scaling. | Deployment model, SLO, traffic, concurrency, timeout, replica authority, load balancer, and capacity headroom. |
| Threads and durable state | Thread IDs, checkpoints, long-term memory, run status, state schema, persistence, TTL, interrupts, resume behavior, deletion, recovery, and reconciliation. | State owner, retention, consistency, migration, encryption, deletion, backup, recovery point, and recovery time. |
| Postgres, Redis, and storage | Connections, latency, locks, capacity, backup and failover, Redis communication, queue metadata, blob and trace storage, ClickHouse where applicable, and dependency health. | Managed versus client infrastructure, credentials, pooling, backup, failover, maintenance, observability, and escalation. |
| Tracing and evaluation | Trace completeness, inputs and outputs, model and tool spans, metadata, dashboards, project alerts, feedback, online evaluators, datasets, offline regression, sampling, and anomaly review. | Projects, sensitive data, retention, sampling, quality thresholds, evaluator budget, alert route, reviewer, and business KPI. |
| Tools and approvals | Tool contracts, identity, timeout, retry, interrupt policy, reviewer decision, resume value, idempotency, side effects, target audit, safe replay, and fallback. | Allowed tools, principal, action authority, approval SLA, target SLO, rollback, and emergency disable path. |
| Release and dependencies | Graph code, state schema, packages, Agent Server version, model and prompt, tool contracts, stores, infrastructure, evaluator gates, rollout, rollback, and provider change. | Source of truth, environments, change authority, freeze, migration, canary, compatibility, and acceptance evidence. |
| Cost and value | Model and embedding use, LangSmith plan and traces, online evaluators, compute, database and storage, retries, loops, support effort, attribution, anomaly, and outcome. | Commercial owner, budget, threshold, business KPI, forecast, unit economics, and optimization authority. |
Treat state, queue recovery, and observability as one operating system
LangSmith Deployment uses stateless API and server instances around durable PostgreSQL storage and ephemeral Redis communication. PostgreSQL holds runs, threads, assistants, cron jobs, checkpoints, and long-term memory; Redis carries ongoing-run metadata and streaming communication. Queue workers execute runs with configurable concurrency. On a hard shutdown, a sweeper can requeue work after a heartbeat breach. That resilience is valuable, but it makes tool idempotency and target reconciliation mandatory because a recovered attempt can repeat work around a failure boundary.
Deployment responsibility varies. LangSmith Cloud manages more of the runtime. A standalone Agent Server brings Docker, Compose, or Kubernetes but requires your PostgreSQL, Redis, license, load balancing, infrastructure monitoring, backup, and scaling. Self-hosted LangSmith brings a fuller control and data plane with more dependencies and capacity planning. Do not write a single runbook for all three models.
LangSmith traces provide the request record and dashboards can surface run count, latency, errors, feedback, and cost. Alerts are project-scoped. Online evaluators can run on filtered or sampled production traces, while offline experiments compare versions against curated, historical, or synthetic datasets. Connect these application-quality signals to API, queue, database, model-provider, retrieval, tool, and business-state metrics; a clean trace does not prove the target operation succeeded.
Distinguish runtime, state, approval, tool, quality, release, and cost failures
| Symptom | Evidence to reconcile | Safe containment | Permanent control |
|---|---|---|---|
| Run is stuck, delayed, or repeatedly retried | Run and thread IDs, queue depth and age, worker heartbeat, attempt count, API and worker logs, Postgres and Redis health, provider latency, timeout, and recent scaling. | Stop new traffic if needed, preserve state, isolate affected queue, restore dependency capacity, route to fallback, and avoid blind duplicate execution. | Queue SLO, heartbeat alert, capacity model, dependency monitoring, retry budget, dead-letter workflow, and recovery exercise. |
| Thread state is missing or inconsistent | Thread ID, checkpoint history, state schema and version, run order, concurrent updates, persistence errors, retention or deletion, backup, and client correlation. | Freeze writes for affected threads, restore an accepted checkpoint where safe, route to manual handling, preserve evidence, and reconcile external state. | Stable IDs, schema migration, concurrency tests, retention policy, backup and restore test, and state-version validation. |
| Approval resumes twice or action occurs before review | Interrupt and resume events, thread ID, node code, checkpoint, reviewer decision, client retry, code before interrupt, tool audit, idempotency key, and target state. | Disable action path, block further resumes, isolate records, reconcile side effects, require manual approval, and restore accepted state only after review. | Idempotent pre-interrupt code, separate action node, single-use approval token, resume contract, target verification, and replay test. |
| Agent completes but answer or action is wrong | Trace and spans, graph route, state, model and prompt, retrieval, tool inputs and outputs, evaluator scores, feedback, expected result, target audit, and recent change. | Narrow affected cohort, route to human, disable risky tool, restore accepted version or source, and correct impacted outcomes. | Representative datasets, deterministic assertions, online cohort evaluation, human feedback, target reconciliation, and release threshold. |
| Regression after graph or dependency release | Code and package diff, Agent Server version, state migration, model and prompt, tool schema, deployment config, traces, eval experiment, traffic, and provider change. | Stop rollout, restore accepted image and graph where compatible, preserve state, narrow traffic, and communicate migration risk. | Locked dependencies, compatibility matrix, state migration test, canary, shadow traffic, evaluation gate, and rollback rehearsal. |
| Unexpected cost or runaway loop | LangSmith cost and run metrics, trace depth, repeated nodes and tools, model tokens, retries, evaluator sampling, queue attempts, infrastructure use, and outcomes. | Stop loop, cap steps and traffic, disable noncritical evaluator or tool paths where safe, route to human, and notify the commercial owner. | Step and retry limits, per-agent attribution, cost alerts, anomaly detection, evaluation sampling policy, forecast, and unit economics. |
Safe replay is a business decision, not merely requeuing a run. Before retrying, determine whether a tool already created, changed, approved, sent, paid, assigned, or closed a record. Use idempotency keys, target-state reconciliation, explicit approval, and a record of which attempt owns the final outcome.
Place the approval boundary after preparation and before side effects
LangGraph interrupts save graph state and wait until execution resumes with the same thread ID. The interrupted node starts again from its beginning on resume, so code before the interrupt can run again. Prepare and validate a proposed action before approval, but move consequential execution into an idempotent step after the approval decision. Do not wrap interrupts in control flow that changes their order, and do not use a volatile in-memory checkpointer for production approvals.
Define reviewer identity, approval SLA, allowed decisions, expiry, editing rules, resume payload schema, delegation, audit evidence, and emergency cancellation. Test duplicate client requests, reviewer refresh, concurrent reviewers, expired decisions, rejected actions, edited arguments, process restarts, and target-system partial success.
Release graph code together with state and infrastructure compatibility
A production release includes graph or functional API code, state and checkpoint schema, package locks, Agent Server and deployment configuration, model and prompt, retrieval and tools, secrets and identities, Postgres and Redis settings, tracing projects, evaluator versions, alerts, client contracts, approvals, rollout, and rollback. A container that starts successfully is not proof that old threads can resume or that a new node order preserves interrupt semantics.
Before release, replay representative threads, test state migration and old-checkpoint compatibility, run offline evaluation and deterministic tool tests, load API and queue paths, verify provider fallbacks, canary a limited cohort, monitor online quality, and preserve the accepted image and migration reversal. For self-hosted deployments, include database backup, restore, failover, and connection-capacity tests.
Onboard through inventory, baselines, controlled failures, and shadow operations
- Inventory: deployment model, clusters, graphs, assistants, threads, runs, checkpoints, state schemas, queues, databases, stores, tools, providers, tracing projects, and outcomes.
- Responsibility: define supported layers, SLOs, severity, access, data handling, quality, change authority, budget, dependencies, fallback, vendor escalation, and exclusions.
- Baseline: measure API and queue health, run completion, state persistence, interrupt age, trace coverage, evaluation, tool and target-state success, cost, and incidents.
- Controls: validate durable checkpointers, idempotency, approval contracts, backup and restore, alerts, evaluator datasets, safe replay, releases, rollback, and attribution.
- Exercise: rehearse a worker crash, queue backlog, Postgres interruption, missing checkpoint, duplicate resume, tool side effect, quality regression, loop, and provider outage.
- Transition: operate in shadow, close or accept material gaps, publish runbooks and escalation routes, and accept the steady-state support scope.
Start with the LangGraph agents that already create customer, financial, operational, compliance, or workforce consequence. Datrick can define the operating boundary, close material control gaps, and transition one portfolio into managed support.
Request a LangGraph AgentOps reviewOfficial references and adjacent operating guides
- LangSmith Deployment models
- LangSmith scalability and resilience
- Configure Agent Server for scale
- LangGraph interrupts and durable state
- LangSmith observability
- LangSmith online and offline evaluation
- LangSmith project alerts
- White-label AI agent managed support for MSPs
- OpenAI Agents SDK production support
Frequently asked questions
What is included in LangGraph production support?
A defined service can include Agent Server availability, API and queue workers, threads, checkpoints, long-term memory, interrupts and approvals, Postgres and Redis dependencies, LangSmith traces, online and offline evaluation, alerts, tools, incidents, release control, cost, runbooks, and reporting. Scope depends on the deployment model, agents, infrastructure, integrations, access, support hours, and accepted responsibility boundary.
What is the difference between LangSmith Cloud, standalone Agent Server, and self-hosted LangSmith?
LangSmith Cloud is managed by LangChain on supported cloud platforms. A standalone Agent Server runs in your Docker, Compose, or Kubernetes environment and requires your PostgreSQL, Redis, LangSmith license, load balancing, infrastructure monitoring, and operations. Self-hosted LangSmith runs the fuller control and data plane in your cloud and has its own platform dependencies and scaling responsibilities. The support boundary must match the chosen model.
Why do LangGraph interrupts require idempotent side effects?
When an interrupted run resumes, the node containing the interrupt restarts from the beginning. Code before the interrupt can therefore execute again. Any external action before that point must be idempotent or moved into a separately controlled step, and the same persistent thread ID must be used to resume the saved state.
How do you monitor LangGraph agents with LangSmith?
Capture complete traces with inputs, outputs, model and tool calls, state and metadata; build project-scoped dashboards and alerts for run volume, errors, latency, feedback, and cost; run online evaluators on filtered or sampled production traces; and move failing traces into datasets for offline regression tests. Platform metrics must also cover API, queue, Postgres, Redis, model providers, and downstream tools.
How long does LangGraph production support onboarding take?
A focused onboarding commonly takes two to four weeks for a representative production portfolio. It covers deployment and graph inventory, state and checkpoint baselines, queue and dependency capacity, observability and evaluation, tools and approvals, incidents, releases, cost, runbooks, controlled failure exercises, and acceptance of the steady-state operating scope.
Comparing state-machine orchestration with role-based agent teams?
Review the CrewAI production support boundary