Trip Cortex

AI corporate travel assistant that enforces company policies via RAG, books flights with browser automation, and keeps humans in the loop all serverless on AWS.

Comment

Inspiration

Corporate travel booking is painful — employees waste time navigating policies manually, and admins struggle to enforce compliance. We wanted to build an AI assistant that handles the entire flow: understanding natural language requests, enforcing travel policies automatically, and booking flights — with humans always in the loop for final decisions.

What it does

Trip Cortex is an AI-powered corporate travel booking assistant. Employees describe their trip in plain English via a chat interface. The system retrieves relevant company travel policies using RAG, reasons over constraints with Amazon Nova 2 Lite (Extended Thinking), and executes flight search and booking through browser automation with Nova Act — all while keeping the employee informed with real-time WebSocket updates and requiring human confirmation before completing any booking.

How we built it

Architecture

Trip Cortex is an event-driven, agentic RAG system with a clear separation: the reasoning layer (Nova 2 Lite) produces validated JSON plans, and the execution layer (Nova Act) consumes them — browser automation never operates on unvalidated intent.

Architecture Diagram

Everything runs serverless — Lambda for compute, Step Functions for orchestration (supports HITL pauses at zero cost and handles Nova Act's 30–120 second browser sessions), DynamoDB for state/audit, and Aurora PostgreSQL (pgvector) for vector search.

1. Policy Ingestion (BDA + Nova MME)

Policy PDFs are uploaded to S3, which triggers the ingestion pipeline:

Policy Ingestion Pipeline

BDA parses PDFs into structured entities with reading order, page numbers, and section titles. Text and tables get text embeddings; figures get image embeddings. We use 1024 dimensions and embeddingPurpose: "GENERIC_INDEX" at index time, "GENERIC_RETRIEVAL" at query time for asymmetric search.

2. Reasoning Engine (Nova 2 Lite)

Retrieved policy chunks are fed to Nova 2 Lite via the Bedrock Converse API with Extended Thinking:

  • Default: maxReasoningEffort: "medium"
  • Escalates to "high" when retrieval confidence is low (similarity < 0.70) or the request involves international travel
  • Output: structured BookingPlan JSON validated by Pydantic (retry max 2, then strictest defaults)
Similarity Confidence Action
> 0.75 High Standard reasoning
0.65–0.75 Low Escalate to high effort
< 0.65 None Strictest defaults + human review

3. Browser Automation (Nova Act)

Nova Act takes the validated BookingPlan and autonomously controls Chrome to search flights, fill passenger details, enter payment, and capture the confirmation. It uses its own frontier computer-use model trained via RL in synthetic web environments — not Nova 2 Lite.

Production deployment: Nova Act CLI → container → ECR → AgentCore Runtime (serverless browser sessions, no infra to manage).

Error recovery: retry with re-orientation → deep link fallback → human handoff. Circuit breaker (DynamoDB) protects against portal outages.

4. Frontend & Auth

React SPA on S3 + CloudFront with custom Clerk auth UI (no prebuilt components). Backend auth is behind a provider-agnostic AuthProvider interface — swapping Clerk for Cognito means changing one class.

WebSocket flow: Clerk JWT → API Gateway $connect → Lambda authorizer → employeeId stored in DynamoDB. All downstream Lambdas read employeeId from the connection record, never from the token.

5. HITL Orchestration

Step Functions' waitForTaskToken pauses the workflow at zero cost while the user reviews flight options. User picks a flight → Lambda calls SendTaskSuccess → workflow resumes → Nova Act completes the booking. Every step logs to a separate AuditLogTable for compliance.

Challenges we ran into

  • Tuning RAG retrieval thresholds to balance precision and recall on policy chunks
  • Handling Nova 2 Lite schema validation failures gracefully with retry logic and strictest-default fallbacks
  • Managing WebSocket connection lifecycle and correlating messages to active bookings
  • Building a realistic dummy travel portal with deterministic seed data for reliable browser automation testing

What we learned

  • Bedrock Data Automation is powerful for structured document parsing across text, tables, and figures
  • Extended Thinking significantly improves reasoning quality for complex policy constraint evaluation
  • The thin-handler / thick-core pattern keeps Lambda functions testable and maintainable at scale

What's next

  • VPC hardening with private subnets and VPC endpoints for all AWS services
  • CloudWatch observability dashboard with X-Ray tracing for end-to-end visibility
  • RAG evaluation framework using Ragas metrics for continuous retrieval quality monitoring
  • E2E canary tests running on a daily schedule via EventBridge

Built With

  • alembic
  • amazon-bedrock
  • amazon-nova-2-lite
  • api-gateway-websocket
  • aurora-postgresql
  • aws-lambda
  • aws-sam
  • aws-step-functions
  • bedrock-data-automation
  • clerk
  • cloudfront
  • docker
  • dynamodb
  • github
  • nova-act
  • nova-multimodal-embeddings
  • pgvector
  • pydantic
  • python
  • react
  • s3
  • sqlalchemy
  • typescript
Share this project:

Updates