Build Reliable AI Apps Using LangGraph: The Travel Agent That Changes Its Mind — State, Nodes, Cycles, Interrupts, and Why the Vocabulary Is the Skill

The input is deliberately realistic: "two of my family want 5 days in Bali in mid-November, we like nature and food, nothing too touristy, budget is about 1.2 lakh INR in total, flying from Bangalore." Nothing in it is structured — no dates, no airport codes, no clean numbers — and four or five separate jobs are hiding inside it.

Attempt one, ask the model. ChatGPT or Claude returns a lovely, confident, instant five-day plan. What it does not return is real flight prices, real availability, or any check that the total fits 1.2 lakh. "There is no way for me to know if it did not simply invent the numbers." A model on its own is brilliant but has no hands, cannot go and look, and will not stop itself.

Attempt two, build it in n8n — the tool the cohort already knows. Read the request, find flights, find a hotel, add it up, send it back. Which works until the total comes in at 1,35,000 against a 1,20,000 budget. And here is the wall: n8n is always left to right, always driven by a trigger or an event, always a pipeline. "A line of steps has exactly one move: carry on, and hand you a plan that you cannot afford." To loop you would need multiple triggers and separate workflows watching for branch events.

Attempt three, an autonomous agent framework: "I've seen a lot of impressive demos, but there's very little wiring made between them — you need to know exactly what it will do before it does it." Attempt four, write it yourself: now you are building the cycles, the loops, the memory management, the pauses, the interrupts, the state handling and a tracer, by hand. LangGraph is the framework that gives you those parts so you can fast-track to the agent.

In LangGraph, state is the single shared record for the job. His analogy is a booking: search writes to it, pricing writes to it, payment writes to it, and the support agent on the phone reads the same record. "Nobody emails anybody. They all read and write the same record." For the travel agent the record holds two travellers, Bangalore to Bali, mid-November, 1.2 lakh budget — and then accumulates: flights, three options found; stays, two options found; things to do, searching; budget check, waiting.

His second analogy is a kitchen. Your table has a reservation ID, and that ID's status travels into the kitchen; every chef updates it — boiling done, grill done — until the recipe is complete, so the waiter knows exactly when to collect. He also points out you have already seen this: when you open the thinking pane on ChatGPT or Claude Code, the running commentary you read is the same mechanism, a record being updated as work completes.

The consequence is the one that matters operationally. Because there is one record rather than a chain of payloads, every step's contribution is visible in one place, and a later step can read what an earlier one found without anyone having to plumb it through.

A node is a specialist that does exactly one job well. In the travel agent: one node reads the request and turns a messy sentence into dates and airport codes; one searches flights and knows nothing about hotels; one searches stays; one adds up the cost, which is "pure arithmetic, no AI anywhere in it". Each updates the state when it finishes. He also offers a humanising frame that makes the parallelism obvious: "assume at every node there is a human sitting to do that particular exact job" — so when flights come back expensive and hotels cheap, those two people coordinate to land the budget.

An edge is one arrow between two nodes, and you draw it. "This matters more than it seems... because you are the person to decide what runs next, not the model." Then the line that carries the whole design philosophy: "the AI does the thinking inside every step, for sure, but it never gets to rewrite the map." He calls it a blueprint — how data must flow between nodes is your decision, exactly as it would be on an n8n canvas; what changes is that the map can contain arrows going backwards.

Nodes, he clarifies during the build, "are nothing but a bunch of functions working in conjunction, to put it in a simple fashion."

Sequential execution is slower for no reason when the steps are independent. Flights, stays and things to do do not depend on one another, so the graph fans out and runs all three at once, then rejoins to rebalance. "While I'm doing it in a sequential form, just the way I'm doing it in n8n, then it is going to take more amount of time."

Then he stops on the question that parallelism creates, using cohort members' names to make it physical: Praful searching flights takes two minutes, Sara searching stays three, Caroline searching activities four — fine, they land in sequence. But what if all three finish simultaneously? "It's like three people are talking to the same phone call. Who gets to answer it first?" Does the new result replace what is already there, or sit alongside it?

The rule for combining two results is called a reducer, and it does one of two things: replace the value in state, or append to a list in state. He flags it as an edge case you simply have to remember, and it is exactly the kind of thing that is invisible until three nodes race and one result vanishes.

A conditional edge is an arrow whose destination depends on a test. After the budget check: 1,20,000 fits, so go forward and ask the traveller to approve; 1,35,000 does not, so go backwards, search again, and do it differently. "The edge, or the checkpoint, where you make an arrow dependent on a condition is called a conditional edge." And rejection at the approval step is itself a condition — if the human does not like it, round again.

The backwards arrow is a cycle, which is LangGraph's own word: "we don't use the name loop here, but they both mean the same thing." Round one came in at 1,35,000 and was over budget; round two shifted the dates, accepted a stopover, and came in under. He caps it at three rounds "just for the sake of convention", and both the session and the post read repeat the cap — an uncapped cycle is how a retry loop becomes a bill.

This is the capability that the whole four-attempt escalation was built to motivate. A pipeline cannot draw this arrow. "It is much more prominent for building agents left, right, centre."

A checkpointer saves the state after every step. His analogy is a game's auto-save at each milestone. Three consequences follow, and they are all operational. It remembers a user across sessions — "if someone comes back next month, it still knows that they had 4am departures, Sara hates 4am departures." It survives a server restart mid-run, so the agent resumes rather than starting over. And it lets you rewind: if something went wrong at round two, you can go back to round two, because round two was saved. He notes this is also what lets one well-built agent serve a hundred or 150 users at once, and lets you scale infrastructure to meet demand.

His illustration is one everyone in the cohort has lived: ask ChatGPT to search, let it work for five or ten minutes, cut the conversation, come back five days later and say resume. It does not lose the context it gathered. That is a checkpointer.

An interrupt is the deliberate pause that puts a human in the loop. "One more jargon — the one your finance team cares about: it stops before it spends money. And that's how it has to be, because we don't want it to spend money on our behalf." The agent does every bit of the work, then freezes and waits — five seconds or five days, nothing is lost. The human approves or rejects; on approval the interrupt releases, the payment confirmation runs, and both the checkpoint and the state are updated.

Three disqualifiers. If the problem is a straight line with no decisions, no cycles, no retries — use n8n, "it is faster to build and easier to change." If one prompt to ChatGPT or Claude is enough, just ask the model once. And if someone else on the team has to be able to edit it, keep it as a linear automation even at a time cost: "it helps you to maintain with no overhead of the learning curve for different teams and different people involved." That third one is a maintainability argument rather than a technical one, and it is the one most often ignored.

The positive signal is compact: "reach for LangGraph only when there is a decision, a retry, or a human in the middle." Later he adds the shape to watch for: "wherever you see a loop and a pause and a parallel processing requirement, that's a signal for you to start with LangGraph."

And he applies it against a cohort member's real case without hedging. Rahul's marketing workflow — write scripts for videos, send to the business, get feedback, create the videos, send them, approve, edit — gets a flat no: "this is a pipeline. You are just saying step 1, step 2, step 3, step 4, step 5. Anything that is related to pipeline, I believe you should not do it in LangGraph, because it's, like, over-engineering. You can just do that in n8n."

Without a recording you add print statements everywhere, run it again, change something, and "hope half an hour later you're still not sure." With a recording you know exactly which node, which tool call, which attempt. He walks the flights node as an example: it went to Skyscanner, looked at an itinerary, found the cost high, shifted the dates by three days, found it moderate, then did the same across Google Flights — and none of that reasoning exists anywhere unless it was traced. "If the agent goes rogue, I need to find it accountable and see where exactly it went rogue."

LangSmith is "an eye for the agent": a microscopic view of its thinking, reasoning, tool calls, steps, and why it retried. The division of labour is one line: "LangGraph is going to help you build a graph and build this agent, while LangSmith is going to keep a recording or keep a trace of what this agent built, the LangGraph, is going to do."

The part worth carrying beyond the tool is his reason. "This is the most important observability pillar every single enterprise is actually standing against." And crucially: "only when you know how the agent is working or thinking behind the lines, you'll be able to take much more steps towards guardrailing." You cannot guarantee an agent is not reading or storing personal data if you cannot see what it does. The hard gotcha, repeated in the post read, is that the data region is chosen at account level — "this can't be changed for that LangSmith account itself. This is an account-wide enforcement, not a project-wide" — because everything the agent does is sent to a cloud and stored there for observability.

He is explicit that the first half of the session was not a programming lesson, and says so twice. "We don't have to necessarily understand the Python programming and all the other things around it, but we need to know what LangGraph consists of primarily." And at the end: "the idea of the session is to understand how LangGraph works, what are the typical jargons used around the ways of agents in LangGraph, and build a simple agent that gets the job done using the things that we have learned. That is the takeaway."

The mechanism is prompt specificity. Ask Claude Code to "build a travel agent that can try again if it is too expensive" and it can choose any framework and any shape, and may not get the job done. Ask instead: "add a conditional edge from a budget check; if it is over budget, go to a relaxed step that loops back to the three searches, capped at three rounds." Same request, same model, twelve words of the right vocabulary, and the build lands. "Now, we are using the actual jargon that LangGraph needs, or the Claude Code needs to understand in the context of a LangGraph."

His analogy answers the cohort member who asked what to do if you are not familiar with the terminology: "if you're talking to a civil engineer, they will appreciate if you use civil engineering jargon, and they will do the work much more efficiently with a limited number of words." The awareness is the deliverable — is it state, a checkpoint, a loop, an edge, a conditional edge, an interrupt — "because I'm sure everyone is proficient enough to talk to Claude Code and Codex of the world. This session is primarily to teach you how to talk with LangGraph kind of projects."

The method is fast and unglamorous. Screenshot the architecture diagram you have just been taught, attach it to Codex or Claude Code as context, and describe the build in framework terms — which is where the vocabulary pays off. He asks for mock data first and names the live sources for later, requests a Mermaid diagram in the README, and specifies a plain interface with a per-node visibility toggle he names Sherlock mode: "a toggle to see behind the scenes, which will unlock the audit for Sherlock Holmes mode of looking at every step."

Plan mode then interrogates him: Python or TypeScript (Python, for the clearest learning path); real LLM plus mock travel data or fully deterministic; local learning app or deployable demo (local, defer the cloud); chat or editable fields for the trip requirements; targeted replan or full replan (targeted — rerun only the affected searches while retaining valid results, with the audit explaining which constraint drove the retry); what Sherlock mode exposes; which LLM; what the cap means; and what happens if the user rejects the plan. He answers all nine, notes he should have started in plan mode, and then names the better instruction: tell it to go with its recommended answers for everything it is about to ask.

The plan that comes back is worth reading as an artefact: nodes to interpret the request, validate requirements, collect missing information with an interrupt, plan the searches, search flights, stays and activities, compose an itinerary and evaluate the plan; conditional routing for revise-strategy and request-approval; the state and interface definitions; mock providers; the UI; a test plan; and an assumptions section that hands his own ambiguities back to him — budget as a hard ceiling, currency conversion out of scope, three retries meaning the initial itinerary plus at most two replans, a rejection treated as new information that resets the counter, and the app recommending but never reserving or purchasing.

Rather than finish the build, he writes the handover as a to-do list and shares the document. Four items. Connect the LLM to the app after the UI mock is done — the mock revises nothing without it. Add Firecrawl and Skyscanner APIs for real-life ingest, replacing the mock providers. Add LangSmith as the tracer, with the API key from the LangSmith console and the data-region caveat. And: "create 10 edge cases for testing the app. Edge cases are where the app can break, where the human in the loop can be assumed — using AI, of course, using ChatGPT or anything."

Then the definition, stated plainly: "essentially, you are creating an instruction set or an eval set. This is what we call as an eval set. Creating a bunch of edge cases where the model can break is an eval set to essentially give a benchmark of your entire agent."

And the loop that follows, given in answer to a question about testing a customer-support bot before production. First, guardrails: "does your app have guardrails? What if it is taking customer data and storing it somewhere? What if it is not anonymising a social security number, but just storing it as is? Because these are against the GDPR standards." Second, the eval set: "if you have 100 edge cases that you have tested, and your AI is performing 80%, your benchmark is 80%." Then take that number back to a model — here is my set, I am getting 80%, how do we optimise, what are the places we can optimise, what better decisions can we make so we can scale it. "Eventually, you'll get an understanding or suggestions from AI itself in this process."

A cohort member asks the question twice — early, and again at the end with cost and speed attached. His answer is consistent. A graph divides work into nodes where each node is a specialist agent and you wire the directions and the loop-backs. Loop engineering is "a little bit of more advanced and abstract form of graph, where we just worry about the loops because the agents themselves have become more prominent and more better. I don't have to divide them into sub-agents or nodes to connect and talk to each other."

So the trade is specificity against trust. "Given the access to higher tiers of model, you don't have to worry about the nodes anymore, you just have to describe a goal. That is the context or premise of loop engineering." But: "here, one node inside the LangGraph is a specialist agent. In loop engineering, one node can do 15 different things, and you're assuming that the node will do that exactly as is. And there is no way for us to trace their activity also. Hence it becomes a little complex." On cost he is relaxed — "loop engineering is not super expensive, I think it's one of the easiest ways to do, because you're just defining when to loop and how to loop."

Then the correction that makes the concept worth keeping: "don't think about loop engineering as the next evolution. ChatGPT 3.5 can only do 10 things. Now ChatGPT Astra can do 100 things. Does that mean we have increased loops or cycles? It's just the inherent nature of the model that has just evolved, to become much more goal-oriented by just a mere description of an abstract problem statement." Loop engineering is not a newer technique; it is the same technique made viable by better models. He also predicts convergence — LangChain improving its docs for loops, "or they will call it LangLoop, whatever it is."