LangGraph
Agents that hold their place in a conversation
We built a LangGraph agent for Military Cruise Deals: a traveller describes a trip in plain words, the agent asks a few clarifying questions, then turns the answer into validated search filters. State across turns is the whole problem it solves.
What you are getting
4 things that decide this
- 01Senior Python engineers with a LangGraph agent running in production on a live commercial site, with FastAPI behind it and Redis holding session state.
- 02They design the graph around what must not happen: a loop with no exit, a step that repeats an action, a session that leaks between users.
- 03Straight talk on when a graph is overkill. A fixed sequence of steps does not need one, and we will say so.
- 04You interview each engineer. The graph, the prompts and the state design are yours from the first commit.
What LangGraph is actually for
LangGraph exists for one problem: work where the next step depends on what happened in the last one, and the path is not fixed in advance.
Military Cruise Deals shows the shape. A customer describes a cruise loosely and changes their mind halfway through. The agent asks short follow-up questions, carries what it has learned across turns in Redis, and only then produces validated ship, port and date filters for the client's own search engine. Before that, mismatched filters were producing false no-results pages and losing bookings.
The part worth paying for is not the graph library. It is deciding what the state holds, when a branch ends, and what the system does when a user contradicts something they said two turns ago.
What they decide when designing a graph
What the state actually holds
The minimum the next step needs, and nothing carried between users by accident. Session leakage is the defect that matters most here.
Where every branch ends
Exit conditions and a step ceiling. A graph that can loop without a stop is a bill and an incident waiting to happen.
Steps that are safe to repeat
A retried node must not book, charge or send twice. This is designed in, not discovered after a duplicate.
Where a person interrupts
Checkpoints where a human approves or corrects before the run continues, placed by what an error would cost.
A record of the path taken
Which nodes ran, in what order, with what state. Without it, debugging a wrong answer is guesswork.
- RequestVague, in the user's words
- StateWhat we know so far
- ClarifyAsk, or proceed
- ValidateTurn intent into real values
- ActOnly on checked input
- ExitEvery branch ends somewhere
Boxes two and three are why a graph exists. A single prompt cannot remember what it already asked, which is how users get the same question twice.
Stateful AI systems in production
“They have a problem-solving mindset, analytical skills, and deep technical knowledge.”
David Manley · CEO, Go Real Travel
How hiring works
- 01
Describe the conversation or process
A free call about what the agent must handle and where it currently gives up. If a fixed workflow would do the job, you will hear that.
- 02
Meet the engineers
We shortlist Python engineers who have designed agent state for a live system, and you interview them your own way.
- 03
They embed
Your codebase, your standups, your deploy process. One of our engineers owns the graph design and answers for it.
- 04
They hand over
The graph, the state model and a note on where each branch terminates, with someone on your team able to extend it. Where a client wants it watched after launch, we stay on under a service level we agree.
Stack
Agent layer
State and infrastructure
Practices
Bring us the conversation your product cannot finish
Show us where users give up or get asked the same thing twice. The scoping call is free, and you will leave knowing whether this needs a graph or a simpler fix.
01Do we need LangGraph, or would a simpler setup work?
A simpler setup wins whenever the steps are known in advance, because it is easier to test and cheaper to run. LangGraph earns its place when the path genuinely branches on what the user or the data says, and when state has to survive across turns. The cruise search agent needed it because customers describe trips vaguely and change their minds mid-conversation.
02How do you keep one user's session out of another's?
State is keyed per session and stored outside the process, in Redis on the Military Cruise Deals build. The test that matters is running two conversations at once and confirming nothing crosses. It is a fast check and it catches the most damaging class of bug in a stateful agent.
03What stops an agent looping forever?
Explicit exit conditions on every branch, plus a ceiling on steps and spend per run. A graph makes those limits visible, which is one of the honest advantages over a hand-rolled loop where the stopping rule tends to live in somebody's head.
04Can it plug into a site we already run?
Yes. The cruise search agent was embedded as a widget into an existing WordPress site, with a FastAPI service behind it and a link back into the client's own search engine. Nothing about the existing platform had to be rebuilt to add it.
05Would you use LangGraph, or a different framework?
Whichever fits the problem, and we will explain the choice rather than default to one. LangGraph suits branching, stateful conversations where the path depends on what the user said three turns ago. Straightforward tool use is often better served directly by a provider SDK with less machinery in the way. Picking the wrong framework adds concepts your team then maintains forever.
06What drives the cost of an agent build?
How many branches the conversation really has and how expensive a wrong action is. A read-only assistant is straightforward. One that books, pays or changes records needs approval steps, repeat-safe design and much more testing. Scoping calls are free. Where we must work inside an existing codebase, a paid two-week diagnostic ends with a fixed price.
