Somewhere warm,
planned by an agent that thinks.
Tell Atlas where you want to go. It checks the sky, finds the route, prices the nights, and rearranges the days around the rain, one reasoned step at a time.
Palm Cove
Coconut coast
Braies
Alpine lake
Whitehaven
Reef shallows
Oia
Caldera terraces
Uluwatu
Reef break
Lofoten
Night ridgeline
Big Sur
Hidden cove
Faroe
Green headland
Palm Cove
Coconut coast
Braies
Alpine lake
Whitehaven
Reef shallows
Oia
Caldera terraces
Uluwatu
Reef break
Lofoten
Night ridgeline
Big Sur
Hidden cove
Faroe
Green headland
The shift
A chatbot answers the question you asked. It guesses at the weather, invents a hotel rate, and never checks whether the budget actually closes. An agent does the work instead: it picks a tool, reads what comes back, and lets the result change the plan.
Grounded
Every figure in the itinerary traces back to a tool call, not to the model's memory.
Observable
Thought, action, observation. Each step streams to the screen as it happens.
Adaptive
A rain forecast reorders the days. The plan responds to what the tools return.
#01 / Live playground
Give it a goal. Watch it decide.
This runs the real agent against the real tools. Every thought, tool call and observation below is produced during the run, not replayed. Ask a follow-up and it keeps the thread.
atlas - travel agent
Tell Atlas where you want to go.
It will think, call the tools it needs, and show every step on the way to the plan. Then you can keep talking to it.
Pick a starting point below, or type your own
#02 / Context and memory
The next step starts from
what the last one returned.
[1] thought Need the April climate before I fix the day order.
[2] action getWeather { city: "Kyoto", month: 4 }
[3] observe { meanHigh: 19.4, rainDays: 9, advice: "pack a shell" }
[4] thought Nine wet days. Put the temple walks on the clear ones.#03 / The loop
One pass of the
ReAct cycle.
Reason, act, observe. The agent repeats this until the goal is met, and the whole sequence is visible while it runs.
Read the goal
The run begins with one sentence of intent. Atlas pulls out the place, the dates, the party size and the ceiling, and states what is still missing rather than assuming it.
goal: "5 days in Kyoto, early April, 2 people, 90000 INR"
Think
Before any call, the agent writes down what it is trying to establish and why this tool is the one that settles it. That sentence is the thought, and it is kept in the trace.
thought: the day order depends on rainfall, so climate comes first
Act
The model emits a tool name and a JSON argument object. The runtime validates the arguments, dispatches the call, and enforces a timeout so one slow endpoint cannot stall the run.
action: getWeather { "city": "Kyoto", "month": 4 }Observe
The tool result is appended verbatim to the scratchpad. Nothing is paraphrased on the way in, so a later step can be audited against exactly what the API returned.
observation: { "meanHigh": 19.4, "rainDays": 9 }Decide again, then answer
The loop repeats until the agent judges the goal satisfied or hits the step ceiling. Only then does it write the itinerary, with each number attributed to the call that produced it.
final: 5-day plan, 86600 INR of 90000, temple days moved to the dry window
#04 / The tool surface
Six calls the agent
can actually make.
The model never answers from memory where a tool can answer from fact. Each entry below is labelled by where its data genuinely comes from.
Returned to the scratchpad
Reykjavik, Iceland lat 64.1355, lon -21.8954 timezone Atlantic/Reykjavik, population 118918
Observations are appended verbatim. The agent reasons over this text on the next pass, so what you see here is what it sees.
#05 / System architecture
Where each request goes,
and what comes back.
One HTTP request opens a Server-Sent Events stream. The orchestrator holds the loop, the model chooses, the dispatcher executes, and the finished trace is written to Atlas.
Streaming
Steps are flushed to the client as they complete, so the trace fills in live rather than arriving as one block at the end.
Degradation
With no Groq key the loop runs a deterministic planner over the same tools. With no Mongo URI it runs without persistence. Neither failure stops a demo.
Two deployments
The same orchestrator is importable from the Next.js route and from the standalone Express server, which is what lets the client sit on Vercel and the API on Render.
#06 / Analysis, syllabus part C
Rule-based agent against
the modern agentic system.
Both agents are implemented in this repository and both are runnable from the playground, so the comparison below is observed rather than quoted.
Rules written by the developer. Anything not anticipated at authoring time is simply absent.
A pretrained model for language and judgement, with every fact sourced from a tool call at run time.
Fixed. The same branch order executes on every input, regardless of what the input needs.
Chosen per step. The next action depends on the observation the previous one returned.
Falls through to a default branch. A destination missing from the table yields a generic reply.
Generalises. An unfamiliar destination still routes through geocoding, weather and encyclopedic lookup.
None. The developer decomposed the problem in advance by writing the branches.
Performed by the agent at run time, and revised mid-run when an observation invalidates the plan.
Total. The branch taken is readable in the source, and the output is reproducible to the character.
Reconstructed from the trace. Every thought, call and observation is logged, but runs are not bit-identical.
Silent irrelevance. It confidently returns a rule that does not fit the request.
Wasted or looping steps, and fabrication if a tool result is missing. Mitigated by step ceilings and strict grounding.
Microseconds, no network, no spend. Hard to beat when the domain really is closed.
Seconds and a token bill, because reasoning and tool round trips dominate the run.
Every new city, season or currency is a new branch. Effort grows with coverage.
Add a tool and describe it. Capability grows without rewriting the control flow.
Where the classical agent wins
When the domain is genuinely closed, rules are better. The rule agent answers in microseconds, costs nothing, never fabricates, and its output can be proved correct by reading the source. For a fixed list of twelve cities with fixed packages, the ReAct agent is strictly worse engineering.
Where it breaks down
Travel planning is not closed. The thirteenth city, an unseasonal forecast, a budget that does not divide cleanly: each is a branch nobody wrote. Atlas absorbs these because it decides the next step after seeing the last result, which is exactly the capability the rule agent cannot express.
#07 / Recorded runs
Three runs, and what
each one exposed.
Captured from the playground against the live tools. Step counts are the real number of loop iterations each goal required.
What happened
The forecast returned nine wet days in the window, so the agent moved both temple walks to the two clear days and pushed the covered market and the Nishiki arcade into the rain. It closed at 86600 INR, 3400 under the ceiling.
The reordering was not requested. It followed from the observation.
#08 / Budget calibration
The three tiers the
budget tool reasons with.
These are not products. They are the lodging and per diem bands that calculateBudgetAndCurrency works from, shown so the arithmetic in a plan can be checked against its assumptions.
Backpacker
plus 1200 per diem
Hostels and guesthouses, public transit, street food. The tier the agent falls back to when a budget pass overshoots.
- Dormitory and guesthouse stock
- Transit passes over taxis
- Free and civic sights prioritised
- Two paid activities per week
Mid-range
Defaultplus 2800 per diem
The default assumption when a traveller states a budget without naming a style. Most recorded runs settle here.
- Three-star and boutique inns
- Mix of transit and point-to-point
- Paid headline sights included
- One reserved dinner per city
Boutique
plus 6500 per diem
Ryokan, design hotels and guided access. Selected only when the stated ceiling genuinely supports it.
- Ryokan and design properties
- Private transfers
- Guided and timed-entry access
- Reserved dining throughout
#09 / Project team
Three students, one shared scope.
Work on this project was not split by module. All three members worked across orchestration, tools, evaluation and documentation, and contribution is recorded as equal.
Aryan Lomte
Fullstack AI co-developer
Aditya
Fullstack AI co-developer
Manthan
Fullstack AI co-developer
Shared across all three
Department of Electronics and Computer Engineering, academic year 2026-27. Artificial Intelligence, IA-2 Activity 1.
#10 / Questions
The things worth asking.
The model is not told which tools to call or in what order. It receives the goal, the tool descriptions and the growing scratchpad, then chooses the next single action itself. The order of calls differs between runs because it is derived from observations, not from a script. That choice, repeated until the goal is met, is what makes it agentic.
Weather and the encyclopedic lookups are live third-party calls. Budget arithmetic is executed locally by mathjs. Routes, lodging tiers and advisories are answered from maintained tables in the repository, because live fare and booking APIs are paid and rate limited. Every tool in the interface is labelled with which of the three it is.
Two kinds. Within a run it keeps a scratchpad: the ordered transcript of thoughts, actions and observations, which is re-read before every decision. Across runs it has an episodic store in MongoDB Atlas holding the full step list, tool payloads and timings of each completed run.
Figures are only permitted to enter the plan through a tool result, and the final answer attributes each number to the call that produced it. Totals are computed by mathjs rather than by the model, which is where invented arithmetic usually appears. If no tool can supply a figure, the agent is instructed to say so instead of producing a plausible one.
Yes, and that is deliberate for a lab demonstration. Without a Groq key the loop runs a deterministic planner over the same six tools, producing a real trace from live data. Without a Mongo URI it runs without persistence. Neither absence breaks the demo.
It is a genuine rule-based agent written for the same task, not a strawman: condition-action rules over a destination table with explicit branches for season, budget band and party size. It is fast, free and perfectly reproducible. The comparison section reports where it beats the ReAct agent as well as where it fails.
Between nine and sixteen loop iterations for the recorded runs, against a hard ceiling that stops runaway loops. Step count scales with how much of the goal is underspecified: a stated budget and fixed dates resolve in fewer iterations than an open brief.
Yes. demo_agent.py drives the same loop from the terminal and prints each thought, action and observation as it happens, which is the intended path for the lab viva.
Run it yourself
Give it a goal and watch it work.
The playground runs the same loop described on this page, against the same live tools, and streams every step as it happens.
python demo_agent.py