Reservedge — Intent-to-Action booking agent

Reservedge turns one natural-language travel request into coordinated flight, hotel and parking actions using Strands Agents SDK and Amazon Bedrock, with human approval at every consequential step.

Comment

Inspiration

Trip planning often turns into a chain of small but time-consuming tasks: find a flight, compare hotels, arrange airport parking, check dates, repeat details, and then start over when one part changes.

We wanted to explore a different interaction model: instead of starting from a domain picker or separate booking forms, the buyer should be able to say what they are trying to do in natural language and let one agent coordinate the work.

That became Reservedge — an Intent-to-Action booking agent.

The goal is not to let an AI silently transact on someone’s behalf. The goal is to make the agent useful while keeping the buyer in control of every consequential step.

What it does

Reservedge turns one conversational travel objective into a coordinated Booking Chat containing multiple domain tasks.

In the competition build it can coordinate:

  • Flights — LiteAPI sandbox research, not a ticket
  • Hotels — LiteAPI sandbox research, not a reservation
  • Airport parking — simulated Curated offers with a governed simulated reservation flow and simulated receipt
  • Experiences — Prioticket adapter with provider-limited catalog availability
  • Rental cars — requirement capture only; no production inventory adapter

A buyer can start with a messy sentence such as a trip involving a flight, hotel and airport parking. Reservedge extracts what is already known, asks only for missing facts, creates the relevant domain tasks, and waits for conversational authorization before searching.

The buyer can then refine the journey naturally. For example, changing the travel dates can update the relevant work without restarting the whole conversation.

The parking demonstration also shows a second interaction model: 'Curated offers'. Instead of only searching a public catalog, the product can support a future model where providers respond to a buyer’s requirements and preferences. In this competition build those provider replies are simulated so the complete human-authorization flow can be demonstrated safely.

How we built it

The conversational agent is built with the Strands Agents SDK and Amazon Bedrock.

The browser does not call Bedrock directly. The path is:

Browser → /v1/agent/** → /v1/aws/plan-turns|execute-turns → Strands Agents SDK → Amazon Bedrock

Strands and Bedrock handle interpretation, clarification and refinement.

We deliberately keep consequential state outside the model. Deterministic application code owns:

  • requirement provenance: 'Explicit / Inferred / Proposed'
  • capability routing
  • search authorization
  • disclosure and supplier isolation
  • deterministic ranking
  • offer-selection state
  • money-sensitive and simulated transaction state

This lets the model remain flexible with language while closed tools and application rules control what can actually happen.

The hosted competition staging environment uses live Amazon Bedrock. A local clone defaults to a credential-free fake model mode so judges can run the repository without AWS credentials.

Human control and simulation

A core design principle is that the agent should not quietly cross important boundaries.

Provider search waits for the buyer to authorize it conversationally.

For the simulated parking flow, the buyer remains involved through requirement confirmation, disclosure, offer selection and the final simulated authorization.

The end result is explicitly labelled:

'SIMULATED — NO REAL CHARGES OR RESERVATIONS'

Flights and hotels shown in the demo are sandbox research only. The parking Curated offers and receipt are simulated. No real card is charged and no real supplier reservation or flight ticket is created.

Amazon Bedrock AgentCore is not deployed or claimed in this submission.

Challenges we faced

The hardest part was not generating natural-language responses. It was keeping conversational understanding and deterministic application state consistent.

A change such as “move the flight to the 19th” sounds simple, but the system has to decide whether that applies only to the flight or should also affect the hotel and parking. We had to separate shared trip context from domain-specific requirements and preserve the buyer’s intent rather than letting one change silently overwrite the whole journey.

Dates were another challenge. We added trusted handling for yearless and month-inherited dates, plus airport-local parking times so local wall-clock values are not accidentally treated as UTC.

We also spent significant effort keeping search authorization separate from booking or payment authorization, preventing stale results from being presented as current, and ensuring the model cannot promote a proposed task into an explicit buyer request by itself.

What we learned

The biggest lesson was that an effective buyer agent needs both probabilistic and deterministic components.

The model is very good at understanding a sentence like a human would, recognizing implied tasks, and handling conversational refinements.

But provenance, authorization, provider isolation, ranking and transaction state benefit from deterministic ownership.

For us, the useful architecture was therefore not “let the LLM do everything.” It was:

language intelligence from Strands + Bedrock, bounded by code-owned state and human authorization.

What's next

The competition build demonstrates the interaction model safely with sandbox and simulated provider paths.

The next stage is to deepen each domain behind the same Booking Chat: production provider connectivity, durable sessions and authentication, real booking capabilities where appropriate, and a broader Curated-offer ecosystem.

The product direction remains the same: one conversational buyer agent coordinating multiple travel tasks while the human stays in control of consequential decisions.

Built With

Share this project:

Updates

Submission history