04 / Project / Agentic AI

JourneyMeshMulti-Agent AI Travel Planner LangGraph + MCP + LLMOps

Supervisor-routed multi-agent travel planning with guardrails, evaluation and human review

Type
Live product
Category
AI / LLM
Focus
Agentic AI · LLMOps

01 / Overview

What this project is.

JourneyMesh is a production-shaped multi-agent AI travel planner. A single sentence such as “plan a relaxing 5-day family trip from Dhaka to Singapore with a budget of $2,000” becomes a reviewable plan: routes, a hotel shortlist, a forecast, a cost breakdown that separates confirmed prices from estimates, and a day-by-day itinerary. A LangGraph supervisor picks only the specialist agents a request needs, every external call goes through an MCP client and an authorisation guard, every draft is guarded and evaluated, and nothing is final until a human approves it - with request-changes re-running only the affected agents.

The problem

Turn a free-text trip request into a trustworthy, editable travel plan without hallucinated prices or flights, without running agents a request does not need, and without leaking PII or letting a model act unchecked.

Approach

A LangGraph supervisor routes each request to only the specialist agents it needs (flight, hotel, weather, budget, itinerary). Every external call passes an MCP tool guard; input and output guardrails screen prompt injection, unlawful intent and PII; a ten-dimension evaluator scores each draft; a human approves or requests changes, and only the affected agents re-run. State is checkpointed in PostgreSQL, traced with structured logs and optional LangSmith, and shipped as one Docker image through GitHub Actions to an OVHcloud VPS.

Measured outcome

Deployed live with an open-source codebase covered by 218 backend tests, 21 frontend tests and an offline evaluation suite gated in CI. Evidence

12
Technologies
7
System layers
2
Related projects

02 / Architecture

How the piecesfit together.

Grouped from the stack recorded for this project. Scroll to walk the layers, or hover one for its components.

  1. User

    Where a request or upload enters the system.

  2. Interface

    Handled by React, TypeScript.

    • React
    • TypeScript
  3. API & services

    Handled by FastAPI.

    • FastAPI
  4. AI layer

    Handled by LangGraph, LangChain, Groq.

    • LangGraph
    • LangChain
    • Groq
  5. Tools & integrations

    Handled by MCP.

    • MCP
  6. Data & vector stores

    Handled by PostgreSQL.

    • PostgreSQL
  7. Cloud & monitoring

    Handled by Docker, GitHub Actions, LangSmith.

    • Docker
    • GitHub Actions
    • LangSmith
  8. Other components

    Handled by Python.

    • Python

03 / Tech stack

Everything it runs on.

Interface

  • React
  • TypeScript

API & services

  • FastAPI

AI layer

  • LangGraph
  • LangChain
  • Groq

Tools & integrations

  • MCP

Data & vector stores

  • PostgreSQL

Cloud & monitoring

  • Docker
  • GitHub Actions
  • LangSmith

Other components

  • Python

04 / Case study

The full write-up.

Overview

JourneyMesh - every journey, intelligently connected. It is built as an agentic system rather than a chatbot: a supervisor decides which specialists a request actually needs, every external call is authorised before it leaves the process, every draft is measured, and nothing is final until a human approves it.

The whole workflow runs end to end with no third-party credentials: without an API key each provider falls back to a deterministic adapter whose output is labelled ESTIMATE, so nothing is ever presented as a live price unless a provider confirmed it.

JourneyMesh trip planner interface

Architecture

  • Interface: React 18, TypeScript, Vite, TanStack Query, Tailwind CSS, i18next (English, Bengali, Hindi)
  • API: FastAPI and Pydantic v2 behind security middleware (request id, size limit, rate limit, headers)
  • Orchestration: LangGraph + LangChain with PostgreSQL checkpoints, so the workflow pauses at review and resumes later
  • Tools: Model Context Protocol client with aviation, search and custom weather MCP servers
  • Storage: PostgreSQL, SQLAlchemy 2.0 and Alembic for trips, results, reviews, conversations and audit events
  • Delivery: one multi-stage Docker image, GitHub Actions quality gate → GHCR → OVHcloud VPS behind a shared Caddy proxy

Dynamic supervisor

The supervisor reads the request and returns a routing decision; it never plans the trip itself. A weather question runs one agent, a full journey runs five. A stated budget pulls in flights and hotels, a multi-night itinerary pulls in hotels, and weather is opt-in. Routing is deterministic by default; a configured model may widen or narrow the selection but only within the known agent set.

Specialist agents

  • Flight agent - resolves airports and normalises routes, never inventing flight numbers or fares; every price is labelled LIVE, SEARCH_DERIVED, ESTIMATE or UNAVAILABLE.
  • Hotel agent - derives a nightly ceiling from budget, trip length and travel style, then ranks candidates on price fit, rating, party size, distance and interests.
  • Weather agent - forecast for the travel window turned into packing and activity guidance.
  • Budget agent - structured cost picture with per-line provenance and within_budget / near_limit / over_budget status.
  • Itinerary agent - deterministic day structure with pacing, rest and indoor swaps when rain or heat is likely.
  • Final response agent - assembles the approved slices into one validated journey in the traveller's language.

Human-in-the-loop and selective re-execution

Each specialist owns exactly one slice of a shared TravelState and agents never call each other. When the reviewer requests a change (“find a cheaper hotel but keep my flights”), the supervisor re-runs only the affected agents - hotel, budget, itinerary - and every other slice stays byte-for-byte identical, up to a revision limit.

Guardrails and security

  • Input guard: payload size, unsafe markup, weighted prompt-injection rules, unlawful-intent screening, travel relevance and semantic checks.
  • PII redaction (passports, IDs, Luhn-checked card numbers, IBANs, emails, phones) before anything reaches a model, MCP server, log or audit trail.
  • MCP tool guard on every call: allowlist, calling agent, arguments, risk and budget.
  • Output guard: schema validation, completeness, credential and unsafe-URL detection, budget arithmetic and itinerary length.

LLMOps: evaluation and observability

A ten-dimension evaluation module - relevance, completeness, groundedness, consistency, tool correctness, schema validity, safety, language correctness, itinerary feasibility and budget consistency - decides everything decidable by rule and uses an LLM-as-judge only where necessary. Structured JSON logs with PII redaction, in-process tracing and metrics are always on; optional LangSmith tracing shows each graph run, agent, model call and MCP tool call as one nested trace, named by revision.

Quality

218 pytest tests, 21 Vitest + React Testing Library tests and an offline evaluation suite, enforced by a GitHub Actions gate before any release.

Try the live demo · View the source on GitHub

Next step

Building something similar?Let’s talk it through.

Tell me what you’re working on and where it gets difficult. I’ll share how this project’s approach would apply to your case.

Let’s chat