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.
Top comments (0)