TripPilot AI

A capstone on the agentic problem everyone demos and nobody ships

Status: graduate coursework. This was my capstone project for the BITS School of Management programme in Product Management with Generative AI and Agentic AI, September 2025 to June 2026. The repository is public, TypeScript, last pushed 5 June 2026, and its entire public description reads "BITSoM - Capstone Project".

What that means for this case study, stated up front. There is no README, no deployed instance, no screenshots and no design file published for this project. I am not going to describe features, architecture or results I cannot point at. What follows is the problem I was working on, why it is a genuinely hard problem class, and how I reason about it. Sections 06 to 11 are explicitly product thinking rather than an implementation record.

That is a thinner case study than the others in this archive, and the correct response to thin evidence is a thinner document rather than a fuller-sounding one.

---

01 · Context

Trip planning is the demo every agent framework reaches for. Give the model a destination, a budget and some dates, watch it call a flight API, a hotel API and a maps API, and return an itinerary. It presents beautifully in a two-minute video.

It is also, on inspection, one of the worst possible things to actually ship, and that contradiction is why it was worth a capstone.

The reason is that trip planning has every property that makes agents unreliable, all at once. Long multi-step tool chains where an early error propagates silently. Constraints that interact, so budget, dates, location and preference cannot be satisfied independently. Real-world data that goes stale between retrieval and use. Consequences that land on a person in an unfamiliar city with no fallback. And no clean definition of a correct answer, which means you cannot straightforwardly test whether the system is any good.

A programme about agentic AI product management is a programme about that gap: the distance between an agent that demos and an agent that can be trusted with something. Picking the canonical demo use case and taking its failure modes seriously was the point.

02 · Problem

The problem class, stated properly.

Multi-step tool chains compound errors and hide them. An itinerary requires flights, then accommodation constrained by the flight times, then activities constrained by the accommodation location, then transport between them. If step two returns a hotel in the wrong district, every later step is confidently wrong and internally consistent. The output looks like a plan. This is the defining reliability problem of agentic systems and it gets worse with chain length, not better.

Hallucinated entities are catastrophic here rather than merely embarrassing. A model that invents a restaurant has produced a small error in a chat context and a real failure in a travel context, because someone walks to an address that does not exist. Anything user-facing in this domain has to be grounded in retrieved data, and the interface has to be able to distinguish what was retrieved from what was generated.

Travel data decays fast. Prices and availability change between the moment the agent retrieves them and the moment the user acts. An itinerary is a snapshot presented as a plan, and the gap between those two things is invisible to the user unless the design makes it visible.

Preferences are mostly unstated and often contradictory. "Somewhere nice, not too expensive, good food." Every word there is unresolved. Worse, users do not know their own constraints until they see a violation of them, which means preference elicitation cannot be front-loaded into a form.

There is no ground truth, so evaluation is genuinely hard. For code you can run tests. For retrieval you can measure whether the right document came back. For an itinerary there is no correct answer, only better and worse ones, and quality is partly a matter of taste. This is the problem that makes trip planning a good teaching case: you cannot improve what you cannot evaluate, and evaluating open-ended generation is the central unsolved problem in shipping agents.

And the commercial problem underneath all of it. Travel planning is a task people enjoy parts of. Nobody enjoys comparing flight prices; many people enjoy choosing where to eat. An agent that automates the whole task removes the pleasant part along with the tedious part, which is a product framing error that no amount of engineering fixes.

03 · Why the problem mattered

Because it is the general problem wearing a specific costume. Long tool chains, stale data, unstated constraints, hallucinated entities and no ground truth describe every agentic product in a real domain: procurement, scheduling, research, support. Trip planning is a legible instance of a class, which is what makes it a good capstone and a bad product.

Because 2026 is full of agents that demo and do not ship, and the gap is not model capability. The models are good enough. What is missing is the surrounding product: grounding, verification, error recovery, permission boundaries and evaluation. Those are product management problems, and they are precisely the ones a programme like this exists to address.

Because consequence changes the design rules. A wrong suggestion in a chat interface costs a retry. A wrong booking costs money and a day. As consequence rises, the acceptable automation level falls, and the design has to shift from acting to proposing. Where exactly that line sits is the interesting question and it is domain-specific.

04 · Research

Method: literature and secondary-source review of agentic architectures, plus structured examination of existing travel-planning tools. No user research was conducted for this project. No interviews, no diary study, no usability testing. It was a capstone built by one person alongside coursework, and claiming a research programme would be an invention.

What the literature review covered. The ReAct pattern from Yao et al., interleaving reasoning traces with tool actions, which is the pattern nearly every current agent framework is a descendant of. Retrieval-augmented generation as formalised by Lewis et al., which is the mechanism by which factual grounding is supposed to happen. Toolformer and the subsequent line of work on models learning when to call tools. The chain-of-thought line from Wei et al., and the well-documented finding that a model's stated reasoning is not necessarily the process that produced its answer, which matters enormously if you are planning to show that reasoning to a user as justification.

What the product review covered. How existing travel tools divide the task. The consistent pattern: they are search interfaces, not planning interfaces. They are extremely good at answering a fully specified query and offer almost nothing for an underspecified intent, which is the actual state a person starts in. That is the gap an agent could occupy, and it is a narrower gap than the demos imply.

What I could not do and would need to. Any real version of this requires watching people plan actual trips, including the parts they enjoy. My entire section 02 claim about pleasant and unpleasant subtasks is a hypothesis derived from introspection. It is testable in an afternoon and I did not test it.

05 · Insights

The agent's job is elicitation, not planning. The hard part of trip planning is not producing an itinerary from a specification. It is producing the specification. A conversational interface is well suited to exactly that, because constraints surface through reaction rather than declaration: people recognise what they want when shown something adjacent to it. This reframes the product from an itinerary generator into a preference discovery tool that happens to output an itinerary.

Grounding must be visible, not just present. It is not enough that the system retrieved real hotels. The user has to be able to see which parts of the output came from retrieved data and which are the model's prose. Otherwise the confident tone of generated text is applied uniformly to facts and invention, and the user has no way to calibrate.

Long chains should be short chains with checkpoints. A ten-step autonomous chain has ten opportunities to go silently wrong. Three steps with a user confirmation between each has three, each of them caught immediately. The cost is more interaction. The benefit is that errors do not compound, and in a consequential domain that trade is obviously correct.

Latency budgets differ by phase and the interface should say which phase it is in. Conversation must feel immediate. Search can take seconds. Full itinerary generation can take longer if the user knows it is happening and can see progress. The failure is not slowness, it is unlabelled slowness, which reads as breakage.

Automation should stop before commitment. Retrieve, compare, propose, explain: all appropriate for an agent. Book, pay, cancel: not without an explicit human action. This is not a temporary limitation pending better models. It is a design principle about consequence, and the boundary belongs where a mistake becomes irreversible.

And the insight I find most useful outside this domain: evaluation design determines product quality more than prompt design does. Without a way to tell whether output B is better than output A, every change is a guess. Teams building agents routinely spend weeks on prompts and no time on evaluation, and then cannot tell whether they have improved anything.

06 · Product thinking

This section and the ones following are reasoning rather than an implementation record.

What the product should be scoped to. Not end-to-end trip planning. One phase, done properly: turning a vague intent into a small set of concrete, grounded, comparable options. That is the phase existing tools do worst and the phase where an agent has a real advantage. Booking, payment and itinerary management are separate, well-served problems.

Where the human stays in the loop, and why there. The elicitation loop is collaborative by design. Retrieval and comparison are automated. Proposal is agent output with visible provenance. Commitment is human, always. That boundary is drawn at irreversibility rather than at difficulty.

The MVP scope I would defend. One destination type, one trip length, three constraints. A narrow enough problem that grounding can be verified by hand and evaluation can be done by reading the outputs. Breadth is what makes agents impossible to evaluate, and evaluation is the bottleneck, so narrowness is not a compromise here, it is the enabling condition.

Why this is a bad first product regardless of execution. Travel is seasonal, expensive to acquire in, dominated by incumbents with supplier relationships, and the transaction is infrequent, so retention is structurally poor. The problem is excellent for learning agentic systems and unattractive as a business. Being clear about that distinction is itself product thinking: a capstone is supposed to teach you the mechanism, and mistaking a good teaching case for a good market is a common and expensive error.

07 · Strategy

Optimise for correctness over coverage. A system that handles a narrow case reliably teaches you more, and could eventually ship, in a way that a system that handles everything unreliably cannot.

Ground everything user-facing. No entity in an output that did not come from a retrieval step. This is a hard constraint rather than a quality goal, because in this domain a hallucinated entity is not a degraded answer, it is a wrong one.

Design for the failure case first. What the interface does when retrieval returns nothing, when a price has changed, when the constraints cannot all be satisfied. In agentic products the failure path is not an edge case, it is a substantial fraction of real sessions, and it is usually designed last.

Build the evaluation before the features. Even a manual rubric scored by hand on twenty cases is worth more than none. It converts opinion about output quality into something comparable across changes.

Keep the model swappable. Model capability and pricing moved substantially over the period of this programme. Any architecture that assumes a specific model is a liability, and treating the model as a replaceable component is now basic hygiene rather than a design flourish.

08 · Information architecture

For a conversational agent, the architecture is a state machine over a conversation rather than a page tree.

Intent            vague input, agent elicits
  ↓               user can revise at any point
Constraints       explicit, visible, editable as a set
  ↓               checkpoint: user confirms before retrieval
Options           grounded, comparable, provenance shown per field
  ↓               checkpoint: user selects
Plan              assembled, with what is fixed and what is provisional marked
  ↓
Handoff           to booking, outside the system

Two decisions worth stating.

Constraints must be a visible, editable object, not conversation history. If the user's constraints exist only as things they said earlier in a chat, they cannot inspect or correct them, and they cannot tell what the agent believes. Surfacing the constraint set as a persistent editable panel is the single most useful structural choice in a conversational planning tool, because it makes the agent's model of the user auditable.

Provisional and confirmed must be visually distinct throughout. A price that was retrieved forty minutes ago is provisional. The design has to carry that distinction all the way to the final view, or the user reads a snapshot as a commitment.

09 · UX and design

No interface artifacts from this project are published, so this section is design reasoning rather than a description of screens. Stating that plainly matters more than filling the section.

The core design problem is showing uncertainty without paralysing the user. Everything in this output has a confidence level: retrieved and current, retrieved and possibly stale, inferred, generated. Surfacing all of it produces an unreadable interface. Surfacing none of it produces a confident-sounding system the user cannot calibrate. The workable middle is to mark only the distinctions that change what the user should do: this is a live price, this is from an hour ago, this is a suggestion rather than a listing.

Waiting is a designed state, not a spinner. An agent doing multi-step work has genuinely different phases, and showing which step is running converts an opaque wait into visible progress. This costs nothing and it is the difference between an interface that feels like it is working and one that feels like it has stalled.

Interruption must always be available. A long-running chain that cannot be stopped is a product that has taken control from the user. Cancel has to be present and it has to leave the system in a coherent state.

Errors should be specific about which step failed. "Something went wrong" is unacceptable in a system with five distinguishable stages. "I could not find availability for those dates" is actionable and it tells the user what to change.

Editing beats regenerating. A user who wants one thing changed should be able to change that thing. Systems that respond to any correction by regenerating everything destroy the parts the user had already accepted, and they teach the user not to ask for changes.

10 · Technology

The repository is TypeScript and public. I am not going to characterise its internals, because there is no documentation I can point a reader at, and describing code from memory in a document about verifiability would be the wrong choice. What I can set out is the architecture the problem demands, which is what the capstone was about.

Orchestration. A ReAct-style loop, reasoning interleaved with tool calls, is the appropriate pattern and it is what the current generation of frameworks implements. The important design decision inside it is not the loop, it is the stopping condition: how many steps before the system hands back to the user. Uncapped loops are how agents burn tokens and produce confidently wrong output.

Tool calling. Structured function calling into typed tools rather than parsed free text. Each tool needs a narrow schema, validation on the way in and on the way out, and an explicit failure representation. The most common practical failure in agentic systems is not the model choosing the wrong tool, it is the tool returning something the orchestrator did not anticipate and the loop continuing as if it had succeeded.

Grounding. Retrieval-augmented rather than parametric. The model must not be the source of any factual entity in the output. Lewis et al.'s formulation of retrieval-augmented generation is the reference point, and the practical requirement it implies is a provenance record per field so the interface can honour section 09.

Model selection. A capable model for planning and decomposition, a cheaper and faster one for classification, extraction and routing. Mixed-tier routing is the standard cost architecture for agentic products, and the reason is arithmetic: an agent makes many calls per session, so per-call cost multiplies in a way it does not for a single-shot chat product.

Cost and latency as first-class constraints. A multi-step agent session costs meaningfully more than a chat turn and takes meaningfully longer. Both facts have to be in the design conversation from the beginning, because they determine what the product can charge and how it must communicate while working.

Evaluation, which is the part I would now treat as the actual deliverable. A fixed set of test intents. A rubric with dimensions that can be scored independently: is every entity real, are the stated constraints satisfied, is the geography coherent, is the output usable without further work. Scored by hand at first, then by a model with human spot-checking. This is what turns agent development from tuning into engineering, and it is the single most transferable thing the programme taught me.

11 · Marketing and GTM

None. This was coursework. It had no launch, no users, no positioning and no distribution, and there is nothing further to report.

The one thing worth recording commercially is the negative finding in section 06: this problem is excellent for learning and unattractive as a business. Knowing which of those you are doing is the difference between a capstone and a wasted year.

12 · Execution

What exists and is verifiable:

• A public TypeScript repository, trippilotai, described as "BITSoM - Capstone Project", last pushed 5 June 2026
• Completion of the capstone requirement within the BITSoM Product Management with Generative AI and Agentic AI programme

What does not exist publicly:

• A README, documentation or architecture description
• A deployed instance
• Screenshots or design files
• An evaluation record

The gap between those two lists is the honest summary of this project's current state as a portfolio artifact.

13 · Results

No outcome metrics exist. This was a capstone project with no users and no instrumentation.

The result is the repository and the completed programme requirement. The learning is in sections 05, 10 and 15, which is what coursework is for.

I want to be explicit that this document deliberately does not attempt to make a student project sound like a product. The reason it is in this archive is that the agentic reliability material is the most current and most commercially relevant thinking I have, and the capstone is where it comes from. Presenting it as anything more would undermine the case studies where I do have artifacts.

14 · What went wrong

I shipped a repository with no README on my most credential-relevant project. This is the only public artifact tying me to a graduate programme in agentic AI product management, and its entire public description is four words. Anyone assessing whether I understand this material has nothing to read. It is the highest-value hour of writing available to me and I have not spent it.

I never deployed it. An agentic trip planner is a product that has to be seen working. A demo URL, even a rate-limited one on free hosting, would be worth more than any description of it, including this document.

I built no evaluation harness, on a project whose central lesson was that evaluation is the bottleneck. I can articulate why evaluation matters. I did not do it. That gap between understanding and practice is the most honest criticism in this case study.

I chose the demo use case. Trip planning is the standard agent example, which means it was well-trodden and I was not forced into the harder parts of the problem. A less obvious domain, with real constraints and a real user I could talk to, would have taught me more. Picking the familiar case is comfortable and I picked it.

I did no user research at all, then made a user-behaviour claim. The argument in section 02 that people enjoy parts of trip planning and resent others is central to the whole product framing, and it comes from introspection. It is a hypothesis presented in a position where a finding belongs.

15 · What I learned

Evaluation is the discipline that separates agent products from agent demos. Everything else is downstream. If you cannot say whether today's output is better than last week's, you are not developing a product, you are exploring.

Chain length is the reliability variable you control most directly. Shorter chains with human checkpoints beat longer autonomous ones in any domain with consequences. The instinct to increase autonomy is usually the wrong instinct.

Grounding is a hard boundary, not a quality dial. In domains with real-world entities, the model may compose and explain and must not originate facts. Designing so that boundary is enforced structurally, rather than requested in a prompt, is the difference between a system that is usually right and one that can be trusted.

Provenance has to reach the interface. Retrieval is worthless to a user who cannot tell what was retrieved. This is a design requirement generated by an architectural decision, which is a pattern I now look for.

The automation boundary belongs at irreversibility. Not at difficulty, not at model capability. Ask what a mistake costs and stop there.

A good learning problem and a good business problem are different things, and being clear about which one you have chosen prevents a lot of wasted effort.

16 · What I would do differently

Write the README this week. What the project is, what problem it addresses, the architecture, what works, what does not, what I would do next. One page. It is the cheapest and highest-return item in this entire archive.

Deploy something, even rate-limited and narrow. One destination, one trip length, three constraints. A working link changes the artifact from a claim into a demonstration.

Build the evaluation harness before touching the agent again. Twenty fixed intents, a four-dimension rubric, scored by hand. Then improvements become measurable.

Narrow the domain drastically. One city, one trip type. Correctness verifiable by hand. Breadth is what makes agents unevaluable.

Talk to ten people who plan trips. Specifically to test whether the enjoyable-versus-tedious split is real, because the entire product framing depends on it and it is currently an assumption.

Publish the constraint panel idea as an interface, not a paragraph. Making the agent's model of the user visible and editable is the most useful design idea in this project and it exists only as text.

17 · Current status

Complete as coursework. Undocumented as an artifact. Not deployed.

Item	Status
Repository	Public, TypeScript, last pushed 5 June 2026
Public description	"BITSoM - Capstone Project"
README	None
Deployment	None
Screenshots or design files	None
Evaluation harness	None
Users	None
Programme	BITSoM, Product Management with Gen AI and Agentic AI, September 2025 to June 2026

The fastest way to make this a real portfolio asset is a README and a rate-limited demo. Neither requires new engineering.

---

Related reading in this archive

• What AI-native product management actually means: evaluation as a product management responsibility
• Agents, autonomy and the human in the loop: where the automation boundary belongs
• Designing products when AI is part of the interface: provenance and uncertainty in the interface
• Agentic workflows and the human in the loop: the architecture argument in research-note form
• The Build Archive: where this repository sits in the wider record

Sources

1. GitHub, TheDevChopra/trippilotai: description "BITSoM - Capstone Project", TypeScript, last pushed 5 June 2026. https://github.com/TheDevChopra?tab=repositories
2. devchopra.life education section: BITSoM, BITS School of Management, Product Management with Gen AI and Agentic AI, September 2025 to June 2026, and its stated coursework coverage. https://devchopra.life/about
3. S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan and Y. Cao, "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. https://arxiv.org/abs/2210.03629
4. P. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. https://arxiv.org/abs/2005.11401
5. J. Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. https://arxiv.org/abs/2201.11903
6. T. Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. https://arxiv.org/abs/2302.04761
7. M. Turpin, J. Michael, E. Perez and S. Bowman, "Language Models Don't Always Say What They Think", NeurIPS 2023: on the unreliability of stated reasoning as an explanation. https://arxiv.org/abs/2305.04388