LangGraph vs the tools layer: where enterprise SaaS agents actually stall

Most teams evaluating LangGraph are asking the wrong question. They want to know if LangGraph is the right orchestrator for their agent project. The harder question — the one that decides whether the project ships — is what sits underneath the orchestrator and lets it actually do work inside an established SaaS product.

This comparison is for Heads of AI, CTOs, and platform leads at B2B SaaS companies who are mid-evaluation on LangGraph and trying to decide where the real engineering effort needs to go. We'll cover what LangGraph does well, what the tools layer is, and why the two are not substitutes. Short version: LangGraph wins for graph-based agent control flow. The tools layer wins — and is usually the bottleneck — when agents need to reach a product whose API surface lags its UI.

How LangGraph works

LangGraph is an open-source framework from LangChain for building stateful, multi-step agents as directed graphs. Nodes are functions or LLM calls. Edges define how state moves between them. The graph holds memory, supports cycles, allows human-in-the-loop checkpoints, and gives you fine-grained control over what the agent decides next at every step.

It sits in the orchestration layer of the agent stack. Its job is reasoning, planning, and routing — deciding what the agent does, in what order, with what fallbacks. LangGraph doesn't generate, host, or maintain the tools the agent invokes. You bring those. You write them, wire them in, and keep them current as your underlying products change. LangGraph assumes the tools already exist and are stable. For greenfield agents calling well-documented public APIs, that assumption holds. For agents acting on an established multi-product SaaS platform, it usually doesn't — which is where the orchestrator obsession starts to hurt projects.

How the tools layer works

The tools layer is the part of the agent stack that exposes a product's real capabilities to an agent. It has three jobs: generate tool definitions from the systems you already own, run those tools reliably at runtime, and keep them current as the underlying product changes. A useful frame: the orchestrator decides; the tools layer acts. We've mapped this in detail in the agent stack: a map for platform teams.

For established SaaS companies, the tools layer is where most agent projects die. The structural reason is familiar to anyone who has audited a mature platform: products were built for the UI, APIs kept up with some of it, and now the API surface typically exposes only a fraction of what the product can actually do. An orchestrator — LangGraph, OpenAI's Agents SDK, anything else — can't reason its way around capabilities the platform doesn't expose. The tools layer either generates that surface from existing code, or it doesn't exist and the agent stalls. Tools also need to execute as the authenticated user so permissions, data visibility, and audit trails honour the real identity. Orchestrators don't do that work.

Comparison

When to choose LangGraph

LangGraph is the right investment when your agent's blocker is control flow, not capability access. Specific situations where it earns its place:

• You're building agents that need cycles, branching, or human-in-the-loop approval — and a linear chain isn't enough.
• You need explicit state management across long-running, multi-turn tasks.
• Your tools are already stable: well-documented APIs, a single product surface, or third-party services with mature SDKs.
• Your team has the bandwidth to own tool definitions and keep them current as the product evolves.
• You want open-source control and are comfortable self-hosting the runtime.

LangGraph is also a reasonable default for greenfield AI products where the team builds both the agent and the product surface in lockstep. The API and the tools can be designed together. There's no legacy gap to close.

When to choose a tools layer

A dedicated tools layer is the right investment when capability access is the bottleneck — which, for established B2B SaaS companies, it almost always is. Specific situations:

• You have multiple products, built over years, and the API surface lags the UI by a large margin.
• Your agent project has stalled at the same point others have: the demo worked, production didn't, and the reason was "the agent can't do X." This is the classic stall pattern.
• You've costed the alternatives — a full API rewrite (in our experience, a multi-year program for any meaningful platform) or bespoke connectors per product — and neither survives portfolio-scale math.
• You need tool calls to execute as the authenticated user, with real permissions and audit trails, not a shared service account.
• You need maintenance to be automated and SDLC-aligned, so tools stay current as products ship.

The two choices aren't exclusive. Most production agent projects need both. The question is which one your team needs to invest in first, and the answer depends on which side is actually blocking you. If you've never written an agent before, the orchestrator feels like the hard problem. After the first stall, the tools layer usually turns out to be where the real work was.

LangGraph limitations for enterprise SaaS

A few specific limitations worth naming, because they show up repeatedly in evaluation conversations:

• No tool generation. LangGraph doesn't help you build the tool surface. If your APIs don't cover the capability, LangGraph can't route around that.
• No tool maintenance. When your underlying product changes, your tool definitions go stale. LangGraph won't catch the drift; your agent will, in production.
• No user-scoped runtime. You're responsible for threading authenticated identity through every tool call. Easy to get wrong, hard to audit.
• Operational burden of self-hosting. Open-source flexibility comes with infrastructure ownership. For teams already stretched, that's another platform to run.

None of these are criticisms of LangGraph as an orchestrator. They're reminders that an orchestrator is one component of a stack, not the whole stack.

How Pontil fits

If you're evaluating LangGraph, the comparison you actually need to make isn't LangGraph vs another orchestrator. It's whether your agent project's bottleneck is orchestration or capability access. For established SaaS companies, it's almost always the second.

Pontil is a Tools-as-a-Service platform. We sit in the tools layer, underneath whichever orchestrator your team picks. We generate tool definitions from the systems you already own, run them with user-scoped authentication, and keep them current as your products change. LangGraph stays your reasoning layer. Pontil makes sure the reasoning has something real to reach. If you want to see how the two fit together against a concrete platform, book a demo.

What we'd choose

For a B2B SaaS company with an existing multi-product platform and a stalled agent project: invest in the tools layer first, then pick whichever orchestrator your team is most productive in. LangGraph is a strong choice for that orchestrator role, especially when you need stateful, branching control flow. But solving orchestration on top of a missing tool surface produces a more sophisticated stall, not a shipped agent.

For a greenfield AI product team designing the platform and the agent together: LangGraph alone may be enough for a while. The tools layer question gets harder as the product surface grows. Better to know it's coming than to discover it the week before launch.