Why We Removed LangGraph From Our AI Platform

Nicola Richli — Mon, 27 Jul 2026 12:58:56 +0000

When we started building yeos.ai, LangGraph looked like the obvious choice.

It promised everything you want from an AI agent framework:

Stateful workflows
Conditional execution
Tool orchestration
Memory
Human-in-the-loop support
Graph-based execution

If you're building production AI agents, it's an attractive starting point.

We used it for months.

Eventually, we removed it completely.

This isn't a criticism of LangGraph—it solves real problems, and many teams are successful with it. But after building an enterprise AI platform, we realized we no longer needed a graph framework at all.

Here's why.

Why We Chose LangGraph

Our original architecture looked similar to many modern AI applications.

User
   ↓
Planner
   ↓
Retrieve Documents
   ↓
Execute Tools
   ↓
Generate Response
   ↓
Persist Conversation

LangGraph made this easy.

Each step became a node.

The graph handled transitions.

State was passed automatically.

Everything looked elegant.

Until the system became larger.

The Problems We Ran Into

None of these issues appeared during prototyping.

They appeared once the product became an actual platform used by multiple customers.

1. Debugging Became Surprisingly Difficult

With a graph, execution isn't always linear.

One node can trigger another.

Conditional edges decide the next path.

Retries can jump backwards.

Tool execution modifies shared state.

Eventually debugging starts looking like this:

Planner
   ↓
Retriever
   ↓
Tool A
   ↓
Planner
   ↓
Tool B
   ↓
Generator

When something goes wrong, you aren't debugging a function anymore.

You're debugging an execution graph.

Simple bugs suddenly require tracing several state transitions.

We wanted to answer questions like:

Why did the model call this tool?
Which document caused this answer?
Why was another tool skipped?
Which state changed here?

The graph made those questions harder instead of easier.

2. Hidden Complexity

Frameworks remove boilerplate.

But they also introduce abstractions.

Over time we found ourselves thinking more about LangGraph than about our own business logic.

Instead of writing code like this:

answer = retrieve(query)

we were thinking about:

graph state
edges
node serialization
execution checkpoints
reducers
graph configuration

The framework became part of the problem we had to understand.

3. Latency Adds Up

Enterprise AI systems rarely perform a single LLM call.

A typical request may involve:

authentication
permission checks
document retrieval
reranking
multiple tool calls
citations
persistence
logging
telemetry

Every layer matters.

Although LangGraph itself wasn't "slow," the orchestration overhead became noticeable as workflows grew.

We realized most of our requests were fundamentally sequential.

We didn't need a graph engine to execute them.

4. Most Flows Aren't Actually Graphs

This was probably our biggest realization.

We assumed AI agents required graph execution.

In practice, most enterprise workflows look like this:

Receive request

↓

Understand intent

↓

Retrieve information

↓

Execute tools

↓

Generate answer

↓

Store results

That's just ordinary software.

Very few requests actually branch into complex execution graphs.

What We Replaced It With

Instead of building graphs, we started building small composable components.

Request

↓

Planner

↓

Context Builder

↓

Tool Runner

↓

LLM

↓

Response Validator

↓

Persistence

Each component has one responsibility.

Each component is independently testable.

Each component can be benchmarked.

Each component can be replaced.

Most importantly:

They're just Python classes.

No graph engine.

No special execution model.

Everything Becomes Easier

Easier Testing

Each component can be unit tested.

planner.plan()

tool_runner.execute()

validator.validate()

No graph runtime required.

Easier Debugging

Every request becomes a timeline.

09:41:11 Planner

09:41:11 Retrieval

09:41:12 Tool

09:41:13 LLM

09:41:14 Validation

09:41:14 Response

We immediately know:

what happened
how long it took
which tool executed
which documents were used

Easier Observability

Instead of visualizing graphs, we visualize requests.

Each stage emits structured telemetry.

Every LLM call.

Every tool.

Every database query.

Every permission check.

Everything is measurable.

This has been far more valuable in production than visualizing node graphs.

Easier to Scale

Need another retrieval strategy?

Replace one component.

Need a different LLM?

Swap the adapter.

Need another vector database?

Replace the retrieval implementation.

Nothing else changes.

Are Graph Frameworks Bad?

No.

They're excellent for:

research
experimentation
complex planning
autonomous multi-step reasoning
recursive workflows

If you're exploring agent architectures, LangGraph is a great tool.

But many enterprise AI applications don't actually need those capabilities.

They need:

predictable execution
observability
security
permissions
auditing
reliability
maintainability

Those are traditional software engineering problems.

What Powers yeos.ai Today

Today, yeos.ai no longer uses LangGraph.

Instead, we built a lightweight orchestration layer tailored to enterprise AI.

Our architecture focuses on:

modular components instead of graph nodes
explicit execution pipelines
structured telemetry
permission-aware retrieval
deterministic tool execution
auditability by design
interchangeable LLM providers
cloud and on-prem deployments

The result is simpler to understand, easier to debug, and significantly easier to evolve.

Ironically, removing a sophisticated framework made the overall system more powerful.

Final Thoughts

Frameworks are fantastic for getting started.

But every abstraction comes with a cost.

As your platform grows, ask yourself an uncomfortable question:

Are you solving your users' problems—or your framework's?

For us, removing LangGraph reduced complexity, improved observability, and gave us full control over how AI requests move through our system.

Sometimes the best architecture isn't the one with the most features.

It's the one that's easiest for your team to understand six months later.

Have you moved away from an AI framework—or doubled down on one? I'd love to hear what worked (or didn't) in your production systems.

About yeos.ai

yeos.ai is an enterprise AI platform that helps organizations search internal knowledge and automate business processes with AI agents. It supports secure cloud deployments in Switzerland as well as fully on-premise installations, giving organizations complete control over their data while providing production-grade observability and auditability.

DEV Community: Nicola Richli