// Production / Agentic Workflows & RAG

AI agents on LangGraph.

You picked LangGraph for control of the agent runtime. Now state graphs, checkpointers, and recursion limits have to hold up under production load - on your infra, with your on-call. We build that layer.

// What we see

Notebook works. Production has a different bar.

01

MemorySaver shipped to production

The tutorial checkpointer is in-memory - on restart, every in-flight conversation evaporates. Most teams find out on their first production deploy.

02

Recursion runs out before the workflow does

Default recursion limit: 25. A supervisor fanning out to 4 workers gets about six steps before silent truncation - and the failure mode is a confident wrong answer.

03

Schema change is a production migration

Add a field to the graph state and every checkpoint persisted yesterday is incompatible - in-flight conversations crash on resume. Teams find out during a Friday rollout.

// Case Study

Guidemate - tourist AI agent for the Lubelskie region

We built Guidemate as a LangGraph-based agent embedded on the Lubelskie Voivodeship's official tourism portal - typed toolkit over the region's curated tourism knowledge, integrated with Poland's RCB government safety-warning feed, deployed on the LangGraph Platform agent service. Serves visitors in 30+ languages at ~$0.01 per message, with a guardrails layer running at 99.3% accuracy.

  • 99.3%

    guardrails accuracy

  • $0.01

    per message

  • 30+

    languages supported

Read the case study
Guidemate - tourist AI agent for the Lubelskie region

// What we do

Three decisions that decide whether the graph holds up.

Most LangGraph deployments don't fail on the model layer. They fail on persistence shape, recursion budgets, and observability that doesn't see inside the graph.

Postgres checkpointing from day one

Durable, horizontally scalable state, designed alongside the graph.

  • Postgres or Redis-backed checkpointers
  • Schema versioning planned before the first deploy

Recursion budgets per graph, not defaults

Node-hop budgets mapped per graph and per conversation type.

  • Explicit termination conditions
  • Workflows finish or fail loud

Observability that sees inside the graph

Per-node traces showing where time and cost actually go.

  • OpenTelemetry per node, Langfuse or LangSmith
  • Per-tool latency breakdowns your on-call can read at 2am

// Method fit

LangGraph isn't the right runtime for every agent.

skip it if

  • You're on AWS and need the perimeter

    If your stack is AWS-native and compliance is the determining factor, AgentCore inside your VPC and IAM is the simpler call.

    AWS AgentCore Agents
  • You're still in R&D

    Plain SDK calls iterate faster while you're testing prompts and scoping the problem. Build the graph after R&D converges.

  • Your workload isn't an agent

    One LLM call with no tools, state, or branching? A single SDK call in your service code does the job.

use it if

LangGraph fits agents with real structure - branching, persistent state, human-in-the-loop interrupts - where you want explicit control of how the flow is expressed and observed.

// How we work

Graph design first. Iterate in a shared trace store. Hand off the runbook.

Every LangGraph engagement starts with the design decisions that are expensive to undo - state schema, persistence backend, recursion budgets, supervisor topology. From there we build in your repo, with your engineers in the loop.

01

Graph and persistence design (week one)

We map the state graph with your team - nodes, state schema, checkpointer choice, recursion budget, interrupt paths. Output: a written design your engineers approve before code lands.

02

Build in your repo, trace in shared tooling

Code lands in your repo. Every run streams to a Langfuse or LangSmith workspace your engineers can open - trace tree, per-node timing, failures, in real time.

03

Hand off the runbook and on-call dashboards

You get the code, the eval suite in CI, dashboards, and a runbook written for an engineer new to the system. Slack access for 30 days after delivery.

Michał Pogoda-Rosikoń

// Expert insight

The most common LangGraph mistake is overengineering. Teams build 80-node state graphs to handle cases the frontier model would generalize over on its own. Every node is another error path, another schema to migrate, another place to look when a run fails. We always start with simplest model, and add nodes only if evals shows it is beneficial.

Michał Pogoda-Rosikoń

Co-founder @ bards.ai

See our open-source work

// Why bards.ai

Why us, instead of two senior agent engineers you'd hire.

Hiring this team takes a year, and they'd learn LangGraph in production on you. We bring the schema-versioning scars and recursion-limit incidents already absorbed.

LangGraph in production at scale

Brand24's internal agent: 13 data sources, Slack-native, sub-5s p50 - Postgres checkpointing and supervisor topology in production.

Eval-first methodology

Every graph change ships with a measured delta - latency, cost per conversation, task completion - on a shared dashboard.

Senior engineers only, no juniors

Everyone on the engagement has shipped LangGraph to production - no ramp-up tax on your dollar.

// FAQ

Common questions about LangGraph in production

LangGraph wins when you need full control of state, retries, and tool dispatch, or when your stack isn't AWS-first. AgentCore wins when you're already on AWS, need VPC and IAM-native isolation as a compliance requirement, and want a managed runtime your security team has cleared. Both can coexist - LangGraph as the inner-loop orchestration inside an AgentCore-hosted worker is a pattern we've shipped.

LangGraph gives you an explicit state machine - nodes, edges, conditional transitions, interrupt points. CrewAI and AutoGen abstract that into role-based or message-passing models, which feel cleaner in a demo and harder to reason about under load. For workflows with branching, human-in-the-loop, or strict latency budgets, the explicit graph is worth the verbosity. For one-off multi-agent demos, the abstractions win.

Two layers. (1) Versioned state schemas - every checkpoint carries the schema version it was written under. (2) A migration step that reads old-version checkpoints, transforms them, and writes them back at the current schema version. We design this before any state touches durable storage, because retrofitting it under production traffic is brutal.

OpenAI Agents SDK wins if you want low ceremony and are comfortable on the OpenAI stack - clean API, built-in tracing, minimal boilerplate, ships fast. LangGraph wins when you need explicit state control: a persisted, versionable state graph; conditional branching that's legible in code; human-in-the-loop interrupts at specific graph nodes; and per-node observability that shows exactly which step failed and what state it held. The practical gap appears in your first production incident. On LangGraph, a bad run is a trace of the exact failing node plus its state. On the Agents SDK, you inspect the thread and guess. If your agent is multi-step, stateful with persistent conversations, or has strict latency budgets per branch - LangGraph's verbosity pays back at the first incident. For one-off tools or simple linear flows, the Agents SDK is the faster path.

MCP servers wrap cleanly as LangChain tools - a BaseTool subclass with an MCP client in the run method. The graph node that calls it gets the same retry logic, error handling, and OTel tracing as any other tool. The piece teams consistently miss: MCP servers with persistent session state (SSE connections, session IDs) need explicit lifecycle management across a multi-worker LangGraph deployment. Each worker needs its own managed client with connection pooling and health checks, or you'll hit session collisions under concurrent load. We wire this alongside the Postgres checkpointer design in week one - because adding it later, under live traffic, is a painful retrofit.

// Let's ship it

Send us your graph. We'll send back a plan.

Tell us the agent's job, state shape, latency budget, and persistence backend. A graph design and an eval plan come back within a business day.

Engagements from
$40K
Typical range
$40K-$120K
Duration
4-8 weeks

Fixed-fee proposal after the first scoping call. Scope drivers: graph complexity, multi-agent topology, persistence and observability scope, eval infrastructure.

Michał Pogoda-Rosikoń

Michał Pogoda-Rosikoń

Co-founder @ bards.ai