back to alternatives

LangGraph Alternative for Building Stateful AI Agents

The best LangGraph alternative for teams that want stateful agent orchestration already running, not a graph runtime to code, host, and operate. Build no-code in a visual Blueprint Designer or with the API and SDKs, ground agents in your own knowledge, give them tools, and deploy across web, WhatsApp, Slack, email, and voice - fully managed, with state, observability, and governance built in. Compare ChatBotKit and LangGraph.

INTERNAL ONLY - not rendered anywhere. Provenance for the claims on this page.

path = repo file relative to sites/main; url = external link;

covers = the claim(s) it backs. (Distinct from the source: local key.)

---------------------------------------------------------------------------

sources:

-- Managed harness vs a graph runtime you code & operate (the LangGraph-specific anchor) --

  • path: content/features/cloud-agent-harness.md covers: Managed cloud harness centralizes state/orchestration vs a self-run runtime; thin clients
  • path: pages/landing/harness/index.jsx covers: Harness positioning - agent loop/state/tools managed centrally vs a runtime you assemble
  • path: pages/landing/platform/index.jsx covers: Composable building blocks / library-vs-platform framing
  • path: pages/landing/agents/index.jsx covers: Agent capabilities, build-vs-buy framing

-- State, orchestration, determinism, long-running work --

  • path: content/features/multi-agent-orchestration.md covers: Platform-managed orchestration (message routing, context passing, execution ordering); no separate framework
  • path: content/features/agentic-ai-blueprints.md covers: Blueprints - visual composition and fixed, deterministic paths
  • path: content/features/task-automation.md covers: Scheduled autonomous Tasks (cron) - long-running jobs on a cadence
  • path: content/features/memory-system.md covers: Persistent memory across sessions (per contact, per bot, shared); semantic memory search
  • path: content/features/continuations.md covers: Continuations - carry a dialogue past the model context limit (managed state)
  • path: content/features/inbox.md covers: Inbox - unified conversation view; human oversight/takeover (human-in-the-loop)
  • path: content/features/message-steering.md covers: Message steering - human/programmatic influence over agent responses
  • path: content/features/spaces.md covers: Shared Spaces for persistent shared knowledge across agents
  • path: content/features/community-hub.md covers: Community Hub - share/clone blueprints, skillsets, datasets, widgets

-- No-code + developer surface --

  • path: content/features/agent-sdk.md covers: SDKs (Node/React/Next/Python/Go); agent SDK for programmatic orchestration
  • path: content/features/cli.md covers: CLI agent mode - local file/command access for coding agents
  • path: content/features/terraform-provider.md covers: Terraform provider / infrastructure-as-code
  • path: content/features/openai-compatible-api.md covers: OpenAI-compatible endpoint - portability / low lock-in

-- Agent capabilities & tools --

  • path: content/features/secure-code-execution.md covers: Secure code execution overview (Python/JS/shell)
  • path: content/features/sandboxes.md covers: Isolated, ephemeral sandboxes; coding agents
  • path: content/features/agent-skills.md covers: Portable drop-in skills for shell/CLI coding agents
  • path: content/features/abilities-catalogue.md covers: Pre-built ability templates + custom abilities
  • path: content/features/agentic-sql.md covers: Agentic SQL over HubSpot / Postgres / CSV / Excel / JSON
  • path: content/features/browser-automation.md covers: Headless browser automation
  • path: content/features/web-search.md covers: Web search ability
  • path: content/features/mcpserver-integration.md covers: MCP server - expose skillsets as MCP tools
  • path: content/features/mcp-sdk-integration.md covers: MCP client - consume any MCP server

-- Knowledge / RAG --

  • path: content/features/datasets.md covers: Managed datasets, document processing, website crawling
  • path: content/features/dataset-reranking.md covers: Second-pass reranking
  • path: content/features/notion-integration.md covers: Notion sync

-- Channels & native channel features --

  • path: content/features/slack-integration.md covers: Slack native channel (attachments, voice/video input)
  • path: content/features/whatsapp-integration.md covers: WhatsApp native channel
  • path: content/features/messaging-attachments.md covers: Attachment processing across channels
  • path: content/features/vision-capabilities.md covers: Vision / image input
  • path: content/features/realtime-voice.md covers: Realtime low-latency voice conversations
  • path: content/features/twilio-integration.md covers: Telephony - SMS and phone-call voice via Twilio
  • path: content/features/ai-avatars.md covers: Lifelike real-time avatars
  • path: content/features/recall-integration.md covers: Live meeting bots - Google Meet, Zoom, Microsoft Teams
  • path: content/features/email-integration.md covers: Email agents

-- App platform, portals, multi-tenancy, white-label --

  • path: content/features/app-platform.md covers: App Platform - Chat, Inbox, Connect, Task, Trace, Usage; Portals
  • path: content/features/portals.md covers: Portals - white-labeled custom-domain app deployment
  • path: content/features/partner-api.md covers: Partner API, parent-child sub-accounts, account isolation, reselling
  • path: content/features/team-management.md covers: Teams - built-in collaboration across bots, datasets, automations
  • path: content/features/granular-access-control.md covers: Per-context access control; accounts/sub-accounts mirror org structure
  • path: pages/landing/whitelabel/index.jsx covers: White-label / resell positioning

-- Security, compliance, cost, observability (built-in, not an add-on) --

  • path: content/features/pii-redaction.md covers: PII redaction with reversible tokens
  • path: content/features/security.md covers: Encryption, SSO, workspace isolation, compliance
  • path: content/features/audit-trails-and-compliance.md covers: Audit trails and compliance controls
  • path: content/features/retention-policies.md covers: Retention and usage policies with enforcement
  • path: content/features/data-residency.md covers: EU data residency
  • path: content/features/policies.md covers: Customer-controlled retention/deletion (Policy API); no-training / zero-retention = platform data policy (no feature doc - confirm before asserting)
  • path: content/features/trace-debugging.md covers: Millisecond-precision trace debugger (inspectability vs LangSmith add-on)
  • path: content/features/performance-analytics.md covers: Performance analytics + token-level usage/cost tracking
  • path: content/features/event-monitoring-and-analytics.md covers: Event monitoring and analytics

-- Keys, connections, deployment --

  • path: content/features/bring-your-own-key.md covers: Bring your own model API keys
  • path: content/features/model-catalogue.md covers: Wide range of model providers, swappable per agent, own/self-licensed models
  • path: content/features/oauth-secrets.md covers: Your own secrets, credentials, and OAuth connections

-- Positioning landing pages --

  • path: pages/landing/enterprise/index.jsx covers: Enterprise - multi-team RBAC, security stack, scale, deployment
  • path: pages/landing/onprem/index.jsx covers: On-prem / private cloud / air-gapped, bring-your-own-models

-- Pricing (flexibility claim only; numbers intentionally NOT rendered) --

  • path: config/subscriptions.yaml covers: Tiers exist (free -> self-serve -> enterprise); keep page generic, no numbers
  • path: config/limits.yaml covers: Per-plan limits behind the tiers

-- LangGraph (external) - re-verify competitor claims on each review --


Reach for a LangGraph alternative and you already know the shape of what you are building - a stateful agent that runs multi-step work, keeps context across turns, calls tools, and does not fall over halfway through. The open question is who authors and runs the orchestration. ChatBotKit and LangGraph both get you to a working stateful agent. Both connect a wide range of models, keep state across a long interaction, and let an agent reason over tools. What differs is whether you build the control flow or run on one that is already built.

LangGraph is a low-level orchestration framework - you model an agent as a graph of nodes that share a state object, write the edges and routing that decide what runs next, and execute the whole thing on a runtime you deploy. Its own words are "an agent runtime and low-level orchestration framework," and the appeal is exact control: nothing about how the agent steps, branches, or persists is hidden, because you wrote it. That is also the commitment - once the graph is coded, the runtime is yours to host, checkpoint, scale, and observe, with LangSmith added on for tracing. ChatBotKit starts from the other side: the orchestration, state, tools, retrieval, and observability are already wired together and running on a managed harness, so you configure an agent rather than program its control flow. LangGraph hands you the graph to draw and run; ChatBotKit hands you the orchestration already running. This is an honest look at where each one fits.

What LangGraph Does Well

LangGraph has become a serious way to build controllable, long-running agents, and its strengths are real:

  • Open source and MIT-licensed - LangGraph is free to read, fork, and run, in Python and JavaScript, with no license cost and full control over the code.
  • Low-level, graph-based control - model an agent as nodes and edges with conditional routing, so you decide exactly how it steps and branches, with nothing abstracted away.
  • Durable execution - checkpointing saves state at every node, so a long run can survive failures and resume from precisely where it stopped rather than starting over.
  • Human-in-the-loop - in-graph interrupts pause a run to let a person inspect, edit, or approve a step before it continues, which suits approval-gated automation.
  • Stateful primitives that scale to production - shared state, persistent memory across sessions, and token-by-token streaming as first-class parts of the runtime.
  • A stable, production-grade foundation - LangGraph reached a 1.0 release with a commitment to interface stability, and is used to run agents at well-known companies, so it is a dependable base to build on.
  • A path to deployment and inspection - LangGraph Platform for managed HTTP deployment and LangGraph Studio for visually stepping through a graph, with LangSmith for observability.

If step-level orchestration you author and operate suits your team, and you have the engineers to run the runtime, LangGraph is a strong foundation.

Where ChatBotKit Is Different

A capable stateful agent is within reach on both sides. The differences below all turn on one question: how much of the orchestration is yours to write and run, and how much is already turning when you show up.

Orchestration You Configure, Not a Graph You Author

Start with what each product asks of you. LangGraph's model is that you are the author of the control flow - you lay out the nodes, draw the edges, write the conditional routing, and decide the order things execute in. That is the point of a low-level framework, and it is real power when a job needs exactly that structure. But it is also work that never fully ends: the graph is code you design, test, and maintain as requirements move. ChatBotKit inverts the default. The agent loop - planning, tool calls, iteration, and exit - is run by the harness, so instead of drawing a state machine you configure an agent: its knowledge, its abilities, its behavior, and its channels. When a job genuinely needs a fixed, ordered path rather than open-ended autonomy, you compose one visually as a Blueprint or schedule it as a Task, no graph runtime to hand-wire. The routine case - an agent that decides its own next step - needs no graph at all, and the structured case gets a deterministic path you assemble instead of code.

State the Harness Holds, Not a Store You Thread and Persist

This is where a stateful framework quietly hands you a database to run. In LangGraph, state is a shared object you define, thread through every node, and persist to a checkpointer you configure - commonly PostgreSQL - which then becomes yours to operate. ChatBotKit keeps state centrally on the harness. Conversation history, context flow, and persistent memory - scoped to a contact, a bot, or shared platform-wide, and searchable by meaning - are managed for you, with no state schema to design and no store to run behind it. Long interactions are handled too: continuations carry a dialogue past a model's context limit automatically, and scheduled Tasks run long jobs on a cadence. Durable, crash-safe checkpoint-and-resume is a genuine LangGraph specialty, and if resuming a failed run from an exact node is your hard requirement, that is a fair reason to choose it - but for keeping agents stateful over long, real conversations, ChatBotKit gives you the persistence without the operational tail.

Control and Determinism Without Owning the Runtime

LangGraph's headline promise is to "balance agent control with agency," and the control half is its real edge: deterministic routing you spell out, no hidden prompts, every node yours to swap, and a LangGraph Studio view to step through a run node by node. Set against a cloud service you cannot see into, that promise is decisive. The catch is the unstated premise - that visibility and control require owning the runtime. They do not. A ChatBotKit agent is auditable end to end: every tool call, model response, and decision is captured by tracing, a millisecond-precision trace debugger, and event monitoring, so you watch what an agent did rather than infer it. Determinism is available where you want it - a Blueprint pins a repeatable path and a Task runs it on schedule, while guardrails, typed tools, and policies cap what the agent may attempt. Ownership of the moving parts stays with you: usage runs on your own model keys and OAuth connections and permissions, and the model catalogue accepts your own fine-tuned or self-licensed models. None of it is a trap door either - an OpenAI-compatible endpoint and the SDKs keep code portable, your data and configuration export on demand, and when the perimeter has to be yours, the platform runs on-prem, in your own cloud account, or air-gapped. The control and the openness are intact; what you shed is the work of building and operating the runtime that normally carries them.

Deployed and Observed for You, Not a Runtime Plus Add-Ons

A graph that works in development is only the beginning of what production asks for. The graph is code; the service wrapped around it is much larger, and every piece is on you. Something has to host the runtime and keep it healthy, ship new versions, provision and back up the checkpoint database, guard secrets, and hold up under load - or you move deployment to LangGraph Platform and take that slice off your plate. What the framework never covered - tracing, evaluations, monitoring - arrives as a separate purchase in the commercial LangSmith. On ChatBotKit that entire tier ships as live services you switch on: managed knowledge with no vector store to operate, sandboxed code execution, every channel, security and compliance, per-token cost control, and full observability, billed as one platform rather than a free runtime plus a rack of paid layers you glue together. Data ownership is part of the deal: ChatBotKit does not train on your data and takes zero data retention with the model providers it calls, while retention and usage policies govern how long anything is kept and when it is purged. The stack a self-run LangGraph deployment expects you to assemble arrives assembled, and it carries from a first agent to a company-wide rollout without going back to the whiteboard.

Native Channels, Not an Endpoint to Wrap

Compiled, a LangGraph graph is a runtime object; deployed, it is an API endpoint. Neither is something a customer can strike up a conversation with, so every path from that endpoint to a real person on a real surface is yours to build. ChatBotKit puts the agent on those surfaces natively: an embeddable web widget, plus WhatsApp, Slack, Telegram, Messenger, Instagram, Google Chat, Microsoft Teams, email, and SMS and phone-call voice over Twilio, with realtime voice, lifelike avatars, and live seats in Zoom, Google Meet, and Teams meetings. The same configuration serves all of them and pools into one unified Inbox - which is also where a person can look over a live conversation and take the wheel. These are not text-only pipes, either: agents open file attachments, accept voice and video input in places like Slack and the widget, sit in on meetings, reply as the email agents you set up, and place and take calls over telephony.

One Configuration, Many Kinds of Agent

One configuration - a single body of knowledge, one set of abilities - powers every agent on ChatBotKit, so the product is not boxed into a conversational graph. The same setup stands up coding agents with shell and file access in your CI, voice and telephony systems that carry live, low-latency calls over Twilio, lifelike avatars that lend an agent a face and a voice, research agents, form-fillers, and beyond. Each of those in LangGraph is its own graph to model, deploy, and keep running - the primitives are there, but the assembly and the operations land on you every time.

Whole Applications and Branded Portals, Not Just the Logic

A working graph is still only the logic - someone has to build the product around it: the interface, the sign-in, the admin, the multi-user access. ChatBotKit ships those as ready-made applications teams open every day - Chat, a hub for multi-agent conversations; Inbox, one place to handle every conversation across channels and bots; Connect, managed third-party integrations; and Task, scheduled autonomous runs - with Trace and Usage alongside for debugging and spend. Fold any of them into a Portal, a branded site on your own domain with its own access, and hand it to a department, a client, or the whole company. The scaffolding you would otherwise build around a graph is already there.

More Than an Orchestration Engine

Whatever you would express as a node or a tool inside a graph - reasoning, actions, retrieval, memory, routing - has a running counterpart here, sitting inside a platform rather than a codebase, with the production tier a framework never ships bolted on top. This is what you get out of the box.

Agents That Act, Not Just Answer

  • A catalogue of ability templates plus custom API abilities, bundled into skillsets an agent installs and drops on its own mid-conversation.
  • Secure code execution - Python, JavaScript, and shell run inside isolated, single-use sandboxes walled off from your systems.
  • Agentic SQL - ask HubSpot, Supabase/PostgreSQL, and CSV, Excel, or JSON files a question in plain language and let the platform write the query.
  • Headless browsing, web search, vision, image and video generation, and speech-to-text over audio and video.

Knowledge That Stays Managed (RAG)

  • Meaning-based datasets from PDFs, Word documents, and spreadsheets, tightened by second-pass reranking and kept current by JavaScript-aware crawling and live Notion sync - and no vector database to stand up.
  • Long-lived memory that carries across sessions - per contact, per bot, or shared everywhere - and retrievable by meaning.

Multi-Agent, Routed by the Platform

  • Built-in bot-to-bot calls, visual Blueprints that assemble agents, datasets, and skillsets into systems, shared Spaces for common context, and cron-driven autonomous Tasks - the platform routes the messages, passes the context, and orders execution, so there is no second orchestration layer to operate.
  • A Community Hub to publish and fork blueprints, skillsets, datasets, and widgets - a head start over an empty editor.

Governance and Observability as Standard

  • Reversible-token PII redaction, audit trails, self-enforcing retention and usage policies, EU data residency, and SSO - shipped with the platform, not sold beside it.
  • Visibility across the run: performance analytics, per-token usage and cost figures, event monitoring, and a trace debugger precise to the millisecond - with no observability product to buy separately.
  • Multi-tenancy and white-label - isolated parent-child sub-accounts through the Partner API, and branded Portals on your own domains.

MCP, Both Directions

  • Reach out to any MCP server from inside an agent, and expose your own skillsets as MCP tools that outside clients - Claude Desktop, IDEs, your own apps - can call.

ChatBotKit vs LangGraph at a Glance

ChatBotKitLangGraph
ModelManaged agent platform, no-code or with codeOpen-source, low-level orchestration framework (a runtime you build on)
Built aroundAn autonomous agent on a managed harnessA graph of nodes with shared state, coded and run
InterfaceNo-code Blueprint Designer and API/SDKsCode only (Python / JavaScript)
OrchestrationManaged agent loop; Blueprints & Tasks for fixed pathsYou author nodes, edges, and routing in code
StateHeld by the harness - conversation, memory, contextShared state object you thread and checkpoint yourself
Durable executionManaged state, continuations, scheduled TasksCheckpoint-and-resume from any node (a core strength)
Human-in-the-loopInbox oversight & takeover, message steering, guardrailsIn-graph interrupts to pause, review, and approve
What you can buildChatbots, voice & telephony agents, avatars, coding agents, research agentsAny stateful agent graph you code
Best forTeams shipping agents on a managed platformDevelopers who want step-level control of the graph in code
Open sourceNo - commercial managed platformYes - MIT; LangSmith is commercial
HostingManaged cloud, or on-prem / private cloud / air-gappedSelf-host the runtime, or LangGraph Platform
Who runs the infraChatBotKit (managed)You (runtime, checkpoint DB, scaling, patching) or LangGraph Platform
Who owns security patchingChatBotKitYou (self-host)
ChannelsWidget, WhatsApp, Slack, Telegram, Messenger, Instagram, Google Chat, Teams, email, SMS/voiceBuild every channel around your deployed graph
Voice & avatarsTwilio voice, realtime voice, avatars, live meeting botsNot a focus
Native channel featuresAttachments, voice & video input, meeting bots, email agents, telephonyBuild it yourself
Knowledge / RAGManaged datasets + reranking + crawling + Notion syncRetriever/vector-store interfaces; build & run the pipeline
Agent toolsAbility-template library + custom + secure code sandbox + agentic SQL + browserTools & nodes you implement and wire
Model supportWide range of providers, swap per agent, bring your own keyBroad provider integrations (in code)
Bring your own keysModel keys, secrets, and your own OAuth connectionsConfigure in your own code
Multi-agentNative bot-to-bot + Blueprints + SpacesMulti-agent & hierarchical graphs (in code)
Determinism / controlBlueprints & Tasks + guardrails + policies + tracingLow-level graph control + LangGraph Studio (in code)
Lock-in / portabilityAPI + SDKs export, OpenAI-compatible endpoint, BYO keys, on-premYour own code; self-host
Data handlingNo training on your data, zero-retention option, customer-controlled retentionDepends on what you build and host
App platformPre-built apps - Chat, Inbox, Connect, Task - packaged into branded PortalsNone - you build the app
Community / sharingCommunity Hub - share & clone blueprints, skillsets, datasets, widgetsTemplates + prebuilt graph examples
MCPClient and serverVia integrations (in code)
Scheduling / automationTasks (cron) + triggers + webhooksBuild your own scheduler (or cron on LangGraph Platform)
ObservabilityPerformance + usage/cost + events + trace debuggerLangSmith (separate commercial product)
CompliancePII redaction, audit trails, retention policies, EU data residencyBuild it yourself
White-label / resellPartner API, Portals, multi-tenancyBuild tenant isolation & branding yourself (MIT permits)
Account isolationIsolated account or space per team, org, or clientBuild it yourself
Cost controlBuilt-in usage & cost tracking + per-account limitsBring your own tooling
Developer surfaceAPI, SDKs (Node/React/Next/Python/Go), CLI, Terraform, OpenAI-compatible endpointPython & JS libraries; LangGraph Platform / LangSmith SDKs
ReplacesThe orchestration plus the runtime, ops, and add-ons you build around itThe orchestration library itself
PricingFlexible - free start, self-serve plans, enterprise when neededFree to self-run (you host & operate); LangGraph Platform & LangSmith commercial

Pricing: One Managed Bill, Not a Runtime Plus Add-Ons

Whether you run the orchestration or rent it shows up clearly once the bills arrive.

LangGraph carries no license fee under MIT - and that is exactly where the cost is easy to underestimate. A production agent on it still runs up a hosting bill for the runtime, a checkpoint database, model tokens, and the salaried hours to build, harden, and keep it live. Lifting deployment onto LangGraph Platform and turning on LangSmith for tracing each carry their own price. The free framework marks the start of the spend, not the whole of it.

ChatBotKit puts the managed stack on a single line. Start at no cost, grow into self-serve plans that track your usage, and turn to enterprise options - on-prem and air-gapped among them - only at the point you truly need them. Models, RAG, sandboxes, state, every channel, security, and observability arrive with no separate infrastructure beneath them and no add-on to license just to watch an agent work. Both sides adjust their pricing, so confirm the current plans directly. Simple to begin, elastic as you scale.

Choose LangGraph If

  • You want step-level, in-code control of the orchestration - authoring every node, edge, and state transition, with nothing abstracted away.
  • Durable, crash-resumable graph runs or in-graph human-in-the-loop approval are hard requirements for what you are building.
  • You want MIT-licensed, open-source primitives to read, fork, and run at no license cost.
  • You have engineers ready to host, scale, secure, and operate the runtime themselves.

Choose ChatBotKit If

  • You want the orchestration and state already turning on a managed platform instead of a graph you code and a runtime you keep alive.
  • You want a no-code visual designer to start in, with the API and SDKs there the moment you want code.
  • You want a single agent to show up on every channel - web, WhatsApp, Slack, email, and voice - with no integration to hand-build.
  • You would rather operate nothing underneath - no runtime, no checkpoint database, no deploy pipeline, no observability add-on - than babysit a self-built stack.
  • You want governance, cost control, and observability in the box, not a commercial product to license alongside.
  • You want one platform where the framework plus its runtime, ops, and tooling would otherwise sit, running on your own model keys and OAuth connections.

Moving from LangGraph to ChatBotKit

Load your knowledge into a dataset, then restate what the graph accomplished as a ChatBotKit agent - a backstory and a set of abilities, put together in the dashboard, the visual Blueprint Designer, or the SDK for whatever language you use - and attach the channels you want. The edges you hand-coded for fixed routing become a Blueprint or a Task, and the shared state you passed between nodes is the harness's job now, so no checkpoint store follows you over. There is nothing to provision below it: no runtime, no vector database, no deploy step. Any LangGraph code you would rather keep can call into the platform through the agent SDK, the API, and the OpenAI-compatible endpoint, letting both run together while you move.

Summary

LangGraph and ChatBotKit chase the same outcome - stateful AI agents grounded in your own knowledge and tools - but start at different altitudes. LangGraph is a low-level orchestration framework: you lay out the agent as a graph of nodes over a shared state, write the control flow, and then own hosting, checkpointing, scaling, and observing the runtime, with the commercial LangSmith filling the gaps it leaves. ChatBotKit is a managed platform where that orchestration and state are already live - usable no-code or in code, present on every channel, and governed and observable from the start. When step-level command of the graph and durable, resumable runs you operate are the requirement, LangGraph is a genuinely strong base. When the goal is a stateful agent that simply runs - without you authoring the orchestration or operating it - ChatBotKit hands you what LangGraph would leave you to build and keep alive.

Frequently Asked Questions

What is the best LangGraph alternative?

The best LangGraph alternative depends on whether you want to author the orchestration yourself. LangGraph is a low-level, open-source framework - you draw an agent as a graph of nodes with shared state, write the control flow in code, then host and operate the runtime that executes it. If you need step-level control over the graph and will run it yourself, LangGraph is a strong choice. If you want that orchestration, state, tools, and observability already assembled and running on a managed platform - usable no-code or with code, deployable across every channel, and shipping governance out of the box - ChatBotKit is the stronger choice.

How is ChatBotKit different from LangGraph?

LangGraph is an orchestration framework: you define nodes, edges, and a shared state object, code the routing between steps, and run the graph on a runtime you deploy - self-hosted or on LangGraph Platform, with LangSmith added for observability. ChatBotKit is a managed platform where the agent loop, state, tools, retrieval, and observability are already wired together and running on a cloud harness you never stand up. Beyond that, ChatBotKit deploys agents natively across web, WhatsApp, Slack, Telegram, Teams, email, SMS, and voice, ships pre-built apps and branded portals, and includes multi-tenancy. That is the core of ChatBotKit vs LangGraph - a running orchestration you configure versus a control graph you code and operate.

Is ChatBotKit built on LangGraph?

No. ChatBotKit runs its own managed cloud harness - state, tools, memory, secrets, retrieval, and the agent loop live on a control plane that thin clients and SDKs connect into. It is not a wrapper around LangGraph, so your agents do not inherit a graph framework's execution model, and there is no orchestration library for you to keep current underneath the platform.

Is ChatBotKit open source like LangGraph?

No. ChatBotKit is a commercial, managed platform, while LangGraph is open source under the MIT license (LangSmith, LangChain's observability and deployment product, is a separate commercial offering). The trade-off is that with ChatBotKit you run no infrastructure - no runtime to host, no checkpoint database, no deploy pipeline, no upgrades - and state, channels, governance, and multi-tenancy are included rather than things you build and operate around a library.

Do I have to write the graph and control flow in code, like LangGraph?

No. LangGraph is code-first - you compose nodes, edges, and conditional routing in Python or JavaScript, and that is the only way in. ChatBotKit has a full no-code path: a dashboard and a visual Blueprint Designer for wiring agents, datasets, skillsets, and abilities into a working system, plus a Community Hub of templates to start from. When you do want code, the same agents are reachable through the API and SDKs for Node, React, Next, Python, and Go, a CLI, a Terraform provider, and an OpenAI-compatible endpoint. With ChatBotKit, code is a choice rather than the entry fee.

LangGraph is about low-level control - isn't a managed platform a black box?

Not a sealed one. LangGraph's pitch is fine-grained, step-level control: you see every node, every edge, and every state transition because you wrote them. Against a cloud-only platform with no visibility that argument lands, but authoring the graph is not the only way to get control. ChatBotKit makes behavior inspectable - full tracing, a millisecond-precision trace debugger, and event monitoring show every step, tool call, and model response. When you want a fixed, repeatable path instead of open-ended autonomy, Blueprints and Tasks give you one, with guardrails, structured tools, and policies holding behavior inside the lines. You bring your own model keys, OAuth connections, and self-licensed models, and an OpenAI-compatible endpoint plus SDKs keep your code portable. If step-level control over the exact graph is a hard requirement, LangGraph genuinely wins there - but for most teams, inspectable and constrained is the control that matters, without writing and running the runtime.

Can ChatBotKit do durable, long-running agents like LangGraph?

Partly, and it is worth being precise. Durable execution - checkpointing state at every node and resuming a run from exactly where it failed - is a genuine LangGraph strength, and if crash-safe, resumable graph runs are your core requirement, LangGraph is built for it. ChatBotKit takes a different route to durability: the harness holds conversation state and persistent memory centrally, continuations carry a dialogue past a model's context limit, and scheduled autonomous Tasks run long jobs on a cadence - so you get long-running, stateful agents without designing, hosting, or operating a checkpoint store yourself.

Does ChatBotKit manage agent state, or do I wire a state store like in LangGraph?

ChatBotKit manages it. In LangGraph you define a shared state object, thread it through your nodes, and persist it to a checkpointer you configure - often PostgreSQL - which you then run. ChatBotKit centralizes state on the managed harness: conversation history, per-contact and shared memory, and context flow are handled for you, and persistent memory is searchable by meaning across sessions. There is no state schema to design and no database to operate behind it.

What about human-in-the-loop - can ChatBotKit keep a person in control?

Yes, though the shape differs. LangGraph offers in-graph interrupts to pause a run and let a person review or approve a step, which is a real strength for approval-gated flows. ChatBotKit keeps humans in the loop through the Inbox - a unified view of every conversation across channels and bots where a person can watch, step in, and take over - alongside message steering and guardrails that constrain what an agent may do on its own. For approval-gated autonomy you keep oversight without coding an interrupt handler.

Do I have to host and deploy the runtime myself with ChatBotKit?

No. The agent loop, model orchestration, retrieval-augmented generation, sandboxed code execution, state, and message routing all run on ChatBotKit's managed cloud harness. With LangGraph you either self-host the graph behind your own service or move deployment onto LangGraph Platform, and you add LangSmith for tracing and evaluation. ChatBotKit is managed from the first agent, with nothing to stand up or take down.

Do I need LangSmith for observability with ChatBotKit?

No. With LangGraph, tracing, evaluation, and monitoring come from LangSmith, a separate commercial product you connect to the framework. ChatBotKit builds observability into the platform - performance analytics, token-level usage and cost tracking, event monitoring, and a millisecond-precision trace debugger - alongside PII redaction, audit trails, SSO, and enforced retention and usage policies, on every tier. It is one platform rather than a runtime plus a separate observability layer.

Can ChatBotKit agents run code and take real actions like LangGraph tools and nodes?

Yes. ChatBotKit agents run Python, JavaScript, and shell in isolated, ephemeral sandboxes, call from an extensive library of pre-built ability templates and custom API abilities, query third-party sources with agentic SQL, automate a headless browser, search the web, and connect to any MCP server. ChatBotKit can also expose your own skillsets as MCP tools for other clients to use, so it works as both an MCP client and an MCP server. In LangGraph each of these is a tool or node you implement, wire into the graph, and operate; here they are running services.

Does ChatBotKit support voice and messaging channels that LangGraph does not?

Yes. ChatBotKit ships native channels out of the box - an embeddable web widget, WhatsApp, Slack, Telegram, Messenger, Instagram, Google Chat, Microsoft Teams, email, and SMS and phone-call voice via Twilio - plus realtime voice, lifelike avatars, and live meeting participation in Zoom, Google Meet, and Teams. A LangGraph graph is a runtime object, or an API endpoint once you deploy it, so reaching users on messaging or voice is integration work you build and host around it.

Can I build things beyond a chat graph with ChatBotKit, like coding agents or voice systems?

Yes. From one configuration - a single body of knowledge and set of abilities - the same platform builds coding agents that run in your shell or CI with local file and command access, real-time voice and telephony systems that hold live phone conversations over Twilio, lifelike avatars that give an agent a face and presence, research agents, form-filling agents, and more. In LangGraph each of these is a separate graph you design and operate, where the primitives fit the job at all.

Can I bring my own model keys and OAuth connections to ChatBotKit?

Yes. You can bring your own model API keys so model usage runs on your own provider accounts and rates, pair the model catalogue with your own fine-tuned or self-licensed models, store your own secrets and authentication credentials, and set up your own OAuth connections to the services your agents reach - so integrations run under your apps and permissions rather than a shared, opaque account.

Will I be locked in if I choose ChatBotKit over open-source LangGraph?

No. ChatBotKit keeps your options open - an extensive API and SDKs to move data and agents in and out, an OpenAI-compatible endpoint so your code is not bound to a proprietary interface, bring-your-own model keys, and on-prem deployment if you want to run it yourself. Your knowledge, conversations, and configuration are yours to export, and our team provides full migration support to move data in or out.

Can I keep data on my own infrastructure with ChatBotKit?

Yes. Beyond the managed cloud, ChatBotKit offers enterprise deployment in your own cloud account (your AWS, Azure, or GCP VPC), a private data center, or a fully air-gapped network paired with self-hosted models on your GPUs. Your data stays in your perimeter and you keep the keys. The difference from a self-hosted LangGraph runtime is that data control does not force you to build and operate the orchestration - ChatBotKit stays a managed, supported platform whether it runs in our cloud or yours.

Is ChatBotKit more flexible on pricing than LangGraph?

Yes. ChatBotKit offers a free way to start and self-serve plans that scale with your usage, up to full enterprise options - so you are not locked into a large commitment to begin. LangGraph is free to license under MIT, but you carry the runtime hosting, the checkpoint database, the model tokens, and the engineering time to build, secure, and operate it; managed deployment on LangGraph Platform and observability through LangSmith are priced on their own. Pricing on both sides changes, so check current plans directly.

How do I migrate from LangGraph to ChatBotKit?

Bring your knowledge sources into a dataset, then re-express what your graph did as a ChatBotKit agent - a backstory and abilities, built in the dashboard, the visual Blueprint Designer, or the SDK for your language - and connect the channels you need. Fixed routing you encoded as edges becomes a Blueprint or Task; the shared state you threaded through nodes is handled by the harness. Because ChatBotKit is managed, there is no runtime to host, no checkpoint store to operate, and no deploy step. If you have LangGraph code worth keeping, the agent SDK, the API, and the OpenAI-compatible endpoint let it call into the platform, so the two can run side by side during a transition.

When is LangGraph the better choice?

LangGraph is the better choice when you want step-level, in-code control over the exact orchestration - authoring every node, edge, and state transition - when durable, crash-resumable graph runs or in-graph human-in-the-loop approval are hard requirements, or when you want MIT-licensed building blocks you can read, fork, and run yourself and have the engineers to host and operate the runtime. If your reason is data control specifically, note that ChatBotKit also deploys on-prem, in your own cloud account, and air-gapped, so you can keep data in your perimeter without operating the orchestration yourself.