Autonomous Travel Operations Agent

Inspiration

Rwanda's intercity bus network moves millions of people every week, but booking a seat still means showing up at a bus park, negotiating in person, or navigating fragmented WhatsApp groups. We wanted to change that — build something that works in the language the traveler actually speaks, handles the full booking flow end-to-end, and never makes up information.

What it does

SmartBus is a conversational AI agent that automates bus travel booking in Rwanda from start to finish. A traveler sends a message like "I want to go from Kigali to Musanze tomorrow" — in English, Kinyarwanda, French, or Swahili — and the agent:

Searches real routes and schedules from the database Compares prices across operators Holds a specific seat to prevent double-booking Asks the traveler to confirm before doing anything irreversible Creates the booking and generates a PDF receipt

Every piece of data — trip times, prices, seat counts — comes from real database queries. The agent never invents numbers.

How we built it

Multi-agent architecture: An intent classifier routes each message to a specialised sub-agent — Search Agent, Booking Agent, or Pricing Agent — each with its own system prompt persona and tool priorities. This means a price comparison question gets a different reasoning strategy than a booking confirmation.

Server-side state machine: The booking flow (search → hold → confirm → book) is enforced in Python, not just in the LLM prompt. If the model tries to call create_booking without first calling hold_seat, the orchestrator blocks it and injects an error back into the conversation, forcing self-correction.

Persistent memory: After every completed booking, the traveler's preferred route and bus type are stored. On their next session, the agent loads this memory and personalises suggestions: "You usually travel VIP — shall I look for VIP buses?"

Graceful fallbacks: Every LLM call is wrapped with retry logic — exponential backoff on rate limits and timeouts, with user-friendly messages per error type so the agent never shows a raw 500 error to travelers.

Tool-grounded truth: 10 deterministic tool functions handle all real-world operations. The LLM reasons and routes; the tools execute. This separation makes the system testable — 23 automated tests run with zero API tokens consumed by mocking all LLM calls.

Challenges we ran into

Hallucinated seat counts: Early versions grouped trips by bus type and invented per-type seat counts that looked accurate but weren't. We fixed this with an explicit system prompt rule and per-trip reporting from tool results.

Kinyarwanda vocabulary drift: The model kept inventing Kinyarwanda phrases that sounded plausible but were wrong. We solved this with a strict forbidden-words list and mandatory exact phrases in the system prompt.

State machine vs. LLM: Getting the model to reliably follow the hold-before-book order required both prompt engineering and server-side enforcement. Prompt alone wasn't enough — the orchestrator now actively blocks illegal transitions.

Free tier quota: During development the free tier ran out mid-testing. We solved this by switching to qwen-plus-latest (which had remaining quota) and building a mocked test suite so development could continue without API calls.

Accomplishments that we're proud of

Built a fully tool-grounded agent — zero hallucinated trip data, prices, or seat counts Enforced a booking state machine server-side, not just in prompts — the orchestrator physically blocks illegal transitions Achieved 4-language support (English, Kinyarwanda, French, Swahili) with strict vocabulary constraints for Kinyarwanda 23 automated tests pass with zero API tokens consumed — full mock test suite Persistent cross-session memory that genuinely personalises suggestions based on past bookings Built and iterated the entire system to production quality within the hackathon window

What we learned

Deterministic tool functions + LLM reasoning is a more reliable architecture than LLM-only State machines belong in code, not just in prompts Multilingual agents need explicit vocabulary constraints, not just language detection Graceful degradation matters more than peak performance for production agents