The cost problem that started this
Instead of an English App, I Added a Layer on Top of AI worked well enough that I used it every day.
But the longer I used it, the more I noticed something: the I Wanted to Build My Own OS.
A subscription and an API key both give I Wanted to Build My Own OS, but the cost structure is completely different. Long conversations burned through tokens quickly. Calling multiple models in parallel for the English layer made it worse.
That was when I first thought: instead of running one expensive model for everything, what if I could combine several cheaper models and get similar results?
That question was what led me to LangGraph.
At first it looked like a simple workflow tool
When I first looked at LangGraph, I was not particularly impressed.
There is a START. There is an END. Connect some nodes in between. Branch to different nodes based on conditions.
It looked like a workflow runner — functions called in sequence.
Why call this a graph? You could do the same thing with if statements and function calls.
The difference between LangChain and LangGraph did not feel obvious at first either. It seemed like just the next version of the same thing.
Then State kept appearing everywhere
The word that appeared most often as I studied was State.
My first assumption was that it was just a global variable.
But the feeling kept being slightly off.
In LangGraph, nodes do not pass data directly to each other. Every node reads from and writes to one shared State.
Things like the conversation so far, search results, memory, and intermediate reasoning all live inside a single State object. The Planner reads from State. Search reads from State. Memory reads from State. They all look at the same thing.
That was the moment it clicked.
LangGraph is not a framework for connecting functions. It is a framework for designing State — and letting the execution flow emerge from it.
Why does Reducer exist?
The next thing I got curious about was Reducer.
What happens when multiple nodes try to modify State at the same time?
Reducer is what merges each node's changes into a new State. Similar to a reducer in React — easy enough to understand conceptually.
But there was something more interesting here: in LangGraph, what matters is not really how you wire the nodes. It is how you design the State.
Nodes read State, update State, and pass it forward. The data structure turned out to matter more than the execution order.
Then the name finally made sense
At first it looked like a simple sequential runner.
But Conditional Edges and loops changed that impression.
Depending on the question, the agent might run a search. If search results are insufficient, it loops back to the Planner. The same node can be visited multiple times: Planner → Executor → Planner → Executor → END.
That is when the name made sense. It is not a tree. It is genuinely a graph — the right structure for expressing complex, non-linear execution flows.
Multi-agent patterns were all the same underneath
I worked through a lot of examples: ReAct, Plan-and-Execute, Reflection, Supervisor, Multi-Agent.
At first each one looked like a different technology.
But once I took them apart, the structure was always the same. A Planner makes a plan. Other agents execute. Tools are called when needed. The Planner evaluates and decides whether to continue.
The node composition varied slightly. But everything was a graph where agents shared State and cooperated. Going through all of that gave me a much deeper understanding of how AI agents actually work.
But the more I built, the stranger a question got
The studying was genuinely interesting.
I ran experiments — splitting the English layer across multiple cheaper models, giving simpler tasks to smaller models to reduce cost.
But the more I built, the more a question kept growing.
What exactly am I building?
Chat UI. Tool execution. Google Calendar connector. File reader. Web search. Scheduled tasks. Memory layer. LangGraph execution engine.
I was reimplementing Claude's features one by one.
There is a real advantage to building your own: you can make it exactly the way you want. But every time a new capability shipped from Anthropic, I had to build it myself. And as Claude improved, the surface area I had to keep up with kept growing.
Was this a winnable fight?
A more fundamental question followed.
If I designed LangGraph well enough — could combining several cheaper models actually beat one expensive model?
I thought it was possible at first.
But the more I studied and the more examples and research I read, the more my thinking shifted. Complex agent architectures do not always produce better results. In many cases, a sufficiently trained single model outperforms them.
I was competing with Anthropic in their strongest domain: model performance, execution engine, chat UI, tool calling. These are exactly the areas AI companies will keep improving fastest.
Trying to keep up with that as a personal project was not a long-term competitive advantage.
So I changed direction completely
At this point I made a real decision.
I would stop building a custom chatbot.