Alex Metelli
Technical writing

Designing evidence-bounded recommendations for an AI travel agent

Let the model choose tools, synthesize evidence, and write the recommendation, but require it to return a structured proposal that references completed tool calls. Deterministic code should validate the decision kind, required evidence, source freshness, claim boundaries, and public artifacts before anything reaches the traveler. When a required check fails, return a bounded needs-confirmation state instead of upgrading uncertainty into a confident answer. Sources: Ask Siargao Reality Check contract, OpenAI function-calling guide.

AI agent systems

How to let an AI travel agent choose tools and make useful judgments while deterministic code owns evidence sufficiency, source labels, privacy, and degraded states.

10 min readPublished Last reviewed

Validation scope
The article is checked against Ask Siargao's public runtime, contract tests, developer references, and deployed surface; it does not claim that external providers are always available or that recommendations guarantee safety or availability.

This guide answers

  • How should an AI agent prove which tools support a recommendation?
  • How do you stop a travel chatbot from inventing live or checked facts?
  • What should happen when an AI recommendation is missing required evidence?

When to use this / when not to use this

Use this when

  • An agent recommends actions from current, external, or location-sensitive evidence.
  • You need model flexibility without allowing generated source labels or unsupported confidence.

Do not use this when

  • The task is deterministic and a normal rules engine can produce the complete result.
  • You cannot define what evidence is required, stale, unavailable, or safe to expose.

Separate model judgment from server-owned proof

A tool-using model should decide which evidence it needs and explain the final recommendation in natural language. It should not create public source objects or declare its own tool calls trustworthy; its structured proposal should reference completed call IDs that the server can independently verify. Sources: Ask Siargao agent routing and source governance, OpenAI function-calling guide.

The server can then derive source labels, decision IDs, and displayable artifacts from the audited tool transcript. This preserves the model's ability to synthesize a useful answer while giving deterministic code the final say over which evidence can appear publicly.

Ownership boundary

  • Model: understand the request and choose typed tools.
  • Model: synthesize checked evidence and write the recommendation.
  • Server: validate tool completion, source sufficiency, and claim boundaries.
  • Server: derive public sources, IDs, and allowlisted artifacts.

Encode evidence requirements by decision kind

A named accommodation, a surf session, and a disrupted itinerary do not need the same evidence. Ask Siargao requires place-identity evidence for named properties, current condition evidence for immediate plans, and both marine or tide evidence and a condition judgment for surf recommendations. Sources: Ask Siargao Reality Check contract, Google Places API policies.

The validator should know whether a source can support a decisive result, whether it is current enough for the request, and whether a dependent check ran after its prerequisite. Merely counting tool calls makes a busy transcript look like proof even when the required fact is missing.

Evidence contract checks

  • The proposed decision kind matches the server-recognized request kind.
  • Every referenced tool call completed and was used by the final answer.
  • At least one verifying source supports a decisive keep, change, or avoid result.
  • Decision-specific current evidence and semantic ordering requirements are satisfied.
System diagramEvidence-bounded recommendation lifecycle

The model proposes a judgment from governed tools, then server validation converts only supported evidence and artifacts into a public answer.

Source: Ask Siargao on-demand Reality Check lifecycle
  1. 01RequestRecognize the decision kind and missing context
  2. 02EvidenceModel selects governed tools
  3. 03ProposalStructured judgment references completed calls
  4. 04ValidationServer checks sources, claims, and artifacts
  5. 05AnswerReturn a checked, partial, or bounded result

Degrade without turning a provider failure into confidence

External evidence is partial by nature. Weather may succeed while a place lookup fails, or current marine evidence may exist without enough detail for a surf-safety claim. Preserve successful evidence, mark the result partial when it still supports the action, and use needs confirmation when the missing check blocks a decisive call. Sources: Ask Siargao on-demand Reality Check lifecycle, Open-Meteo weather API documentation.

A failure source can explain a limitation but cannot verify a positive claim. The response should give the traveler one practical next step—call ahead, confirm locally, or keep the plan flexible—without promising background monitoring or a later intervention.

Useful degraded states

  • Checked: sufficient verifying evidence and no terminal required gap.
  • Partial: usable verifying evidence plus a relevant failed or unavailable check.
  • Unavailable: no verifying evidence supports the requested decision.
  • Needs confirmation: the product names the missing fact and a bounded next action.

Persist public artifacts instead of private tool transcripts

The durable product record should contain traveler-visible messages, sanitized source summaries, and explicitly selected cards, itineraries, or decision summaries. Exact browser coordinates, raw provider payloads, private tool arguments, and internal caveats should stay outside authenticated history and public share surfaces. Sources: Ask Siargao routes and surfaces reference.

Artifact selection needs the same evidence boundary as prose. An unrelated recommendation card or an artifact produced by a failed provider should not become public merely because the model knows its identifier. Build an allowlist from successful, used tool results before persisting or sharing anything.

Persistence boundary

  • Store traveler-visible message content and sanitized public sources.
  • Store only artifacts selected from successful, used evidence calls.
  • Derive ownership from the authenticated session rather than request-body user IDs.
  • Exclude exact coordinates, raw tool arguments, and provider response bodies.

Reality Check evidence state machine

This state machine keeps an explicit traveler request separate from evidence collection, server validation, public completion, and bounded degradation when a required source is unavailable.

State machineDerived from Ask Siargao Reality Check contract
  1. Requestedmutable

    The decision kind and essential traveler context are being resolved.

    • complete context → Collecting
    • missing context → Requested
  2. Collectingmutable

    The agent selects governed tools and records completed evidence calls.

    • propose result → Validating
    • provider gap → Validating
  3. Validatingderived

    The server checks kind, source sufficiency, claim limits, and artifacts.

    • sufficient → Checked
    • mixed evidence → Partial
    • required gap → Needs confirmation
  4. Checkedimmutable

    A decisive result is backed by the required verifying evidence.

    • return public summary → Completed
  5. Partial / Needs confirmationderived

    The answer preserves usable evidence and exposes the blocking limitation.

    • return bounded summary → Completed
  6. Completedterminal

    The sanitized answer and selected public artifacts have been returned.

    Implementation examples

    Concrete commands and data shapes you can adapt.

    Validate a model-proposed Reality Check before publishing ittypescript
    const proposal = parseRealityCheck(modelOutput);
const evidence = resolveCompletedCalls(proposal.evidenceToolCallIds);

const result = validateRealityCheckProposal({ proposal, evidence, recognizedKind });
if (!result.valid) {
  return buildNeedsConfirmationSummary(result.reason, evidence);
}

return buildPublicDecisionSummary(result.value, evidence);

    Decision log

    The choices that shape the design—and what each choice costs.

    1. Let the model choose tools

      Natural-language requests do not map cleanly to one fixed provider or evidence path.

      Tradeoff: The runtime needs strict typed tools, bounded turns, and audited call references.
    2. Derive public sources on the server

      Source identity and success state must come from executed provider results, not generated prose.

      Tradeoff: Every new provider or source label requires validation and persistence updates.
    3. Keep Reality Checks synchronous and on demand

      One request contains the trigger, evidence time, cost, result, and failure state.

      Tradeoff: The product does not promise monitoring, proactive alerts, booking, or operator intervention.

    Failure cases

    What breaks, how it presents, and the recovery boundary.

    The model references a tool call that did not complete
    Signal

    The proposed evidence ID has no matching successful call and result pair.

    Response

    Reject the proposal and return a bounded result from the evidence that actually completed.

    A current surf recommendation lacks marine or tide evidence
    Signal

    The answer proposes a decisive surf verdict from place or memory context alone.

    Response

    Fail the evidence contract and state which current condition must be confirmed.

    A failed provider artifact is selected for display
    Signal

    The final payload names a card or itinerary produced by an unsuccessful or unused call.

    Response

    Drop or reject the artifact through the server-built allowlist before persistence.

    Repositories and primary references

    Read the implementation, specifications, and tool documentation behind the article.

    Inspect the systems that ground this guide in implementation work.

    Last updated: