The instinct, when a conversational assistant underperforms, is to reach for a bigger model. On this engagement, the fix was the opposite: work out what the user is actually asking for, and then do less.
How Rapyder built an intent-routed pilgrimage itinerary agent on Amazon Bedrock AgentCore, using six intents, purpose-built agents, semantic caching, and structured outputs to keep agentic AI useful, cost-aware, and production-ready.
Rapyder recently delivered an agentic assistant on AWS for an India-focused spiritual travel platform, helping devotees discover and plan multi-day pilgrimage journeys. The interesting part was not the model alone. It was the routing layer in front of it and the one agent behind it that was allowed to be expensive.
The customer is not named here at their request. Everything below is architecture and approach.
The Problem: The Platform Had the Data, the Pilgrim Did the Assembly
Planning a pilgrimage is genuinely hard work, and very little of that difficulty is about finding a temple. A devotee heading out for a multi-day journey has to decide which sacred sites to visit and in what order, look up darshan timings, understand available rituals and costs, find a stay nearby, arrange transport between towns, and estimate how much of each day disappears on the road.
The platform already held much of that information across temples, sacred sites, rituals, stays and transport. But it sat behind separate APIs and separate screens, so the assembly work landed on the pilgrim.
Five problems followed:
• Building the itinerary was left to the user. Every data source became one more tab, creating high effort before booking and drop-off before conversion.
• Cost only became clear at the end. Ritual fees, accommodation, and transport were priced separately after the plan was assembled.
• Travel time between sites was guesswork. Nothing sequenced a day against actual road distance.
• Every question was treated identically. Factual queries, discovery, emotional guidance, event-safety questions, and full planning requests all met the same search box.
• There was no clear visibility into AI behavior or cost. Telemetry existed as raw logs, not as agent-level insight.
The Principle: Classify the Intent Before Doing Anything Else
An orchestrator on Amazon Bedrock AgentCore classifies every incoming message by voice or text, in English, Hindi, or a mix of the two, then routes it to the agent, toolset, and response contract built for that intent. Nothing else runs.
This is the decision the rest of the architecture hangs off. Separating the intents meant each path could be optimized independently. More importantly, only one path had to pay the cost of six live API calls.
Two sub-agents sit behind that router. A RAG agent handles informational intents grounded in the platform’s verified knowledge base. A travel planner agent handles itinerary creation and booking. A third internal handler maintains a rolling conversation summary so context survives across turns without re-sending the whole history to the model.
Model selection follows the same logic as routing: match the model to the job. Intent classification runs on a fast classifier model, orchestration and plan assembly on a stronger reasoning model, and high-volume retrieval on a deliberately lightweight model. Emotional-guidance responses invoke no tools at all.
RAG Agent vs Travel Planner Agent: Two Agents, One Multi-Agent AI Architecture on AWS
Once AI intent classification routing is doing its job, the natural question is why route to two agents at all instead of asking one model to do everything.
The answer sits in how differently the two agents behave.
The RAG agent is built for retrieval and grounding. It handles general Q&A, discovery, emotional guidance, and event-safety information by drawing from the platform’s verified knowledge base, falling back only when needed. Its job is to be fast, inexpensive, and honest, including refusing to answer when the available sources cannot support a response.
The Travel Planner agent is built for orchestration across live systems. It does not retrieve an answer; it assembles one. It calls six live sources in parallel: temple, sacred-site, ritual, stay and transport data, plus real distance and drive time through Google Maps. It then returns the result as structured, priced, editable itinerary data.
That split is the heart of the multi-agent AI architecture on AWS. The RAG agent handles the majority of traffic cheaply. The Travel Planner agent is allowed to be expensive because only true planning and booking requests reach it.
This is the broader lesson for Amazon Bedrock AgentCore agentic AI builds: agentic AI is not about making one model do everything. It is about designing the right routes, assigning the right agents, and making only the complex paths pay the complex cost.
The Travel Planner: The One Agent Allowed to Be Expensive
When the intent is “plan my journey,” the assistant has to do real work.
The Travel Planner agent parses the route, duration, budget, ritual preferences, and party size from plain language. It then calls six live sources in parallel, each with its own retry, so one slow dependency degrades a line item rather than failing the plan, and assembles a day-wise plan with per-item and total cost. The response returns as structured JSON against a defined contract that the platform’s canvas interface renders as an interactive, editable itinerary.
Two design decisions mattered most.
First, real distance changed the quality of the plan. Sequencing days against live drive time rather than assumed proximity was the difference between an itinerary that reads well and one that works on the ground.
Second, the itinerary was treated as a data contract, not a message. Returning JSON kept the agent responsible for planning and the interface responsible for presentation. Had the agent returned prose, every UI change would have become a prompt change.
How It Fits Together on AWS
The architecture used Amazon Bedrock AgentCore for orchestration, with API Gateway for authentication, routing, and throttling. Voice interactions used AWS Lambda with Amazon Transcribe and Amazon Polly. The data layer included Amazon S3, Amazon OpenSearch, Amazon DynamoDB, and Bedrock Knowledge Bases.
The system also used platform APIs, partner travel APIs, Google Maps and web search where needed. Backend services ran inside a customer-controlled Amazon VPC.
The important part was not the number of services. It was the separation of responsibility: channels, orchestration, agents, models, integrations, data and observability each had a defined role.
Semantic Caching Ahead of Inference
Before any model is invoked, the runtime embeds the incoming query and checks it for similarity against recent queries held in Amazon ElastiCache for Valkey. On a high-confidence hit, it returns the cached response.
On repeated, high-frequency questions, this reduced inference cost by roughly 30 to 40% on semantically cached queries and improved latency noticeably.
The caveat matters: similarity thresholds need tuning. Set them too loose and the system may serve a near-miss answer. Set them too tight and the cache stops paying for itself. Semantic caching is a production dial, not a one-time switch.
Keeping Answers Current and the System Legible
Two pipelines ran alongside the agent runtime.
The first kept the knowledge base fresh. Change streams on the source content database captured inserts, updates, and deletes. Amazon EventBridge routed those events, AWS Lambda materialized incremental deltas, and the Bedrock Knowledge Base re-embedded only what changed.
The second made system behavior visible. Every agent, tool, and function emitted structured JSON with session ID, agent, tool, latency, token count, and error code. Amazon CloudWatch captured the logs, Athena queried them in place, and Amazon QuickSight turned them into dashboards.
The single most important factor was not the dashboard. It was deciding on one log schema before analytics existed. Retrofitting a log schema across a multi-agent system later is painful. Agreeing it in the first sprint is cheap.
Five Lessons for Any Agentic AI Build
1. Classify intent before doing anything else. Routing is cheaper than reasoning.
2. Match the model to the job. Uniform model selection is almost always overspending.
3. Return a contract, not a message. If an agent output feeds a UI, it should return structured data.
4. Keep tool schemas non-overlapping. Overlapping schemas are a common reason agents choose the wrong path.
5. Use semantic caching carefully. It can reduce cost and latency, but it needs active threshold tuning.
Designed for Peak, Not Average
Religious tourism does not arrive evenly. Demand concentrates around large pilgrimage events, which is exactly when an assistant is most useful and most likely to fail.
The design targets reflected that reality: a designed capacity of 3 to 5 lakh conversations a month, around 1,000 concurrent users at peak, an 8 to 10 second response target for text and 12 to 15 seconds for voice, and full multilingual support across English and Hindi by voice or text.
Reliability and degradation were designed in. The retrieval agent had to fetch context before answering, fall back when the knowledge base was thin, and refuse politely when neither source could support the answer. External API calls used retries and graceful degradation. Requests were authenticated and throttled at the gateway.
Voice accuracy carried an honest caveat: the 85% target assumed minimal ambient noise at the user’s end. That assumption was documented as a planning input instead of buried.
Where This Pattern Applies Next
Strip out the pilgrimage vocabulary and the blueprint is general: classify the request, route it to a purpose-built agent, let exactly one path be expensive, return structured data, cache what repeats, and emit one log schema from every component.
That pattern applies anywhere a single input box hides several different jobs: insurance servicing, retail and travel planning, field-service dispatch, benefits guidance, healthcare navigation, B2B quoting, and customer support.
Rapyder is an AWS Premier Tier Services Partner. This engagement drew on our expertise in Amazon Bedrock AgentCore orchestration, retrieval-augmented generation on Amazon OpenSearch, voice-first interaction design, semantic caching, and GenAI observability.
If your assistant is answering every question the same way, and costing the same for all of them, the fix probably is not a bigger model.
Frequently Asked Questions
Amazon Bedrock AgentCore helps teams build and operate agentic AI applications with orchestration, tools, runtime, memory and observability patterns. In this build, AgentCore helped classify user intent and activate the right agent instead of sending every request through one generic path.
Intent routing helps the system understand what kind of job the user is asking for before invoking tools or models. That matters because each intent may need a different agent, data source, model and response format.
AI intent classification routing is the process of classifying a user request, such as Q&A, discovery, itinerary planning, booking or safety guidance, and sending it to the correct agent and toolset.
A RAG agent retrieves grounded information from verified knowledge sources and uses it to answer factual or guidance questions. A Travel Planner agent performs a more complex task: it parses constraints, calls live APIs, sequences stops, calculates travel time and returns a structured itinerary with pricing.
Multiple agents make sense when one input box hides different kinds of work. Some requests need retrieval, some need live APIs, some need structured output and some need no tools at all. A multi-agent design lets each route have its own tools, model, guardrails and cost profile.
Semantic caching checks whether a new query is similar to a recent one before invoking a model. If the match is strong enough, the cached response can be returned directly, reducing both inference cost and latency.
Structured JSON keeps the agent responsible for reasoning and planning while the interface handles presentation. This makes the system easier to validate, render and maintain.
The same pattern can apply to insurance servicing, retail assistance, healthcare navigation, field-service dispatch, benefits guidance, B2B quoting and customer support.
Rapyder helps enterprises design and build agentic AI systems on AWS using intent routing, RAG, tool orchestration, semantic caching, structured outputs and GenAI observability. The goal is to move beyond demos and build production-ready AI systems that are measurable, reliable and cost-aware.
