Thinking in state: what LangGraph taught me about agents
2026-05-26
My first agentic workflows were duct tape. Call the model, parse the output, call it again, add a retry, add a flag, add another flag. It worked until it didn't, and when it didn't, nobody could say what state the system was actually in.
LangGraph forced a different discipline on me: think in state, not in prompts. Once I had to define, explicitly, what belongs to each node and what transitions are legal, the mess reorganized itself. Failures became states you can inspect instead of stack traces you excavate out of a pile of if-statements. The graph became documentation that can't drift from the code, because it is the code.
Building multi-step agents for a logistics platform made the stakes concrete. An agent that reads real operational data earns you rules I now carry everywhere: untrusted content never gets tools — anything that reads the outside world outputs structured data only, validated against strict schemas. Reference records by index into a list you control, never by IDs the model generates — because scraped text will eventually try to talk its way into your database.
The unglamorous conclusion: agent engineering is mostly state machine design with a language model inside. The model is the easy part.
