What LangGraph is, in its own words
LangChain describes LangGraph as “an agent runtime and low-level orchestration framework” for agents that “reliably handle complex tasks”, under the headline “Balance agent control with agency” and the product tagline “Build agents with low-level control.” It supports “single, multi-agent, hierarchical” control flow “all using one framework”, lets you “Guide, moderate, and control your agent with human-in-the-loop” and “Add human-in-the-loop checks to steer and approve agent actions”, persists memory “for future interactions”, offers “first-class streaming”, and claims it “will not add any overhead to your code.” It is “an MIT-licensed open-source library and is free to use.” The commercial layer is LangSmith — “our agent engineering platform” — sold in Cloud, BYOC (“LangChain runs the control plane, you run your data planes”) and Self-hosted tiers, the latter two “available on the Enterprise plan.” (Sources: langchain.com/langgraph and docs.langchain.com .)
We are quoting that at length because the tempting version of this page — “LangGraph is just a graph library, it has no human-in-the-loop, no memory, no multi-agent” — is false on every count. It has all three, it is used in production at large companies, and its low-level posture is a deliberate design choice.
So the comparison is not feature-by-feature. It is who writes the architecture, and what you are left holding afterwards.
The difference in one table
| LangGraph | Forge | |
|---|---|---|
| What it is | A library you write your agent runtime in | An operated system that runs agent teams for you |
| What you author | Nodes, edges, state schema, checkpointer — in Python or JS | A plain-English brief; Forge proposes roles, transitions and a validator for your approval |
| Who checks a step | You, by placing interrupts and writing the check | A management agent on every handoff by default: pass, return with enrichment instructions, or escalate to a person |
| A rejected step | Whatever your graph does with it | A new commit; the earlier attempt stays in history and git diff shows what changed |
| Where the record lives | A checkpointer (Postgres, Redis, memory) plus traces in LangSmith | A branch in your repository — spec, brief and every handoff as commits, Co-authored-by the persona |
| Scheduling, approvals, secrets, notifications | You build them, or buy the platform tier | Included: cron schedules, Telegram approvals, scoped secrets, notifications, per-org agents |
| Model choice | “any model provider” — your code calls it | A routing gateway across a provider pool with priority weights and automatic failover |
| Where it runs | Wherever you deploy it; managed/BYOC/self-hosted via LangSmith Enterprise | Managed SaaS, or self-hosted runners on your own hardware |
| Scope | Anything you can express as a graph | Software delivery (most mature), plus research, content and operations |
Where Forge is different
You describe the team, not the graph. The input is a sentence: “a researcher who gathers sources, an analyst who re-opens every one and checks the quote, and a writer who turns it into a client-ready brief.” Forge proposes the roles, the transitions and the management agent, and waits for your approval before spending anything. See Workflow Engine .
The validator is structural. In a framework, a review step is a node you decide to add and code you decide to write — and the honest failure mode is that under deadline, it does not get written. In Forge the management agent sits on every edge as the default: it reads the handoff and passes it, sends it back with specific enrichment instructions, or escalates to a human. See Multi-Agent Pipeline .
The audit trail is git, and it is yours. Every run gets a branch — forge/workflow/{workflowId}/run/{runId} — holding the spec, the original brief and each role’s structured and freeform handoff as commits, authored by the persona. A checkpointer lets a run resume; a branch lets a person read the argument two quarters later, diff the second attempt against the first, or intervene by committing a corrected handoff. If we disappeared tomorrow, your history is still a git repository on your disk. See Git-Backed Audit
.
The operated parts are included. Cron schedules, approvals and dispatch over Telegram , scoped secrets and egress control , notifications , self-hosted runners , and a routing gateway with priority weights and automatic failover across Anthropic, Google, Z.AI, Ollama, self-hosted models and any OpenAI-compatible endpoint. With a framework, each of those is a project.
It is not only software. The same engine, the same validation loop and the same audit trail run a research team that verifies its own sources, a content team, or an ops rotation. See the use cases .
The one number a single agent cannot report
A framework can be made to produce this table. Ours produced it without anyone deciding to build it, which is the entire argument for an opinionated system stated as a number rather than as a philosophy.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample, not a pilot, not a customer case study we cannot show you.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is precisely the review a single-agent tool leaves on your desk — here it is priced at one model call per edge, and counted.
It merged 202 pull requests across 7 repositories in the same period — roughly 17 a week, into the platform you are reading about, with a human performing every merge. Organisation-wide, agent-authored work merged at 773 of 875 opened. Forge is not a demo running beside the product; it is how the product gets built, and these are its commits.
A finished run takes about 39 minutes and 5 handoffs. Median dispatch-to-done — and inside those 39 minutes sit the reviews that stopped 80 pieces of work from reaching the next role in the state they were first written in.
That review step ran 1216 times and nobody had to remember to add it. On LangGraph this table is a node you write, a store you run and a schema you version — and the version you build is the version you maintain, for as long as you run it.
Ask us to walk you through the runs themselves — the branch, the handoff commits, the verdicts that sent work back, and the ones that went to a person. Every other number on this site belongs to a named run and says so: 18 sources gathered, 11 verified by direct retrieval, 4 corroborated and 2 shipped marked unverifiable, on the research use-case page .
Sources
- langchain.com/langgraph — positioning, control-flow, human-in-the-loop, memory, streaming, licensing, customer claims.
- docs.langchain.com — LangSmith platform setup — the Cloud / BYOC / Self-hosted deployment tiers and the Enterprise-plan gate.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.