DEV Community: Christopher Mburu

From AI Chatbots to AI Operators: Why Travel Doesn't Need Another Assistant

Christopher Mburu — Mon, 13 Jul 2026 08:55:07 +0000

Most AI tools in travel can answer questions. Very few can actually do the work.

A delayed flight.
A missed airport transfer.
A hotel overbooked at midnight.
A client changes destinations while already in transit.
These aren't customer support problems.
They're operations problems.

Yet much of today's AI conversation is still focused on building assistants that generate impressive responses instead of systems that execute reliable workflows.
After spending the last several months building autonomous travel agents, I've become convinced that we're asking AI the wrong question.

Instead of asking:
"Can AI answer this?"
we should be asking:
"Can AI own this process from start to finish?"

The Hidden Cost of Modern Travel Operations
Travel companies don't lose most of their time answering FAQs.
They lose it managing fragmented information.

A typical booking touches multiple systems:

CRM
Email
WhatsApp
Supplier confirmations
Flight updates
Hotel vouchers
Transfer schedules
Customer preferences
Internal spreadsheets

The problem isn't lack of data.
It's that every piece of information lives somewhere different.
Humans become the integration layer.
That doesn't scale.

The Shift: From AI Assistants to AI Operators
Most AI assistants work like this:

Question
        ↓
Large Language Model
        ↓
Answer

Useful?
Absolutely.
Finished?
Not even close.
An AI operator looks different:

Booking received
        ↓
Verify traveler profile
        ↓
Check supplier confirmations
        ↓
Monitor flights
        ↓
Detect risks
        ↓
Notify operations
        ↓
Rebook if required
        ↓
Update CRM
        ↓
Learn from outcome

Notice something?
The user may never even talk to the AI.
The work simply gets done.

Memory Changes Everything
One capability I believe remains underrated is persistent operational memory.
Most AI forgets everything after the conversation ends.
Operations cannot.
Imagine an agent remembering that a traveler:

always prefers aisle seats,
avoids overnight layovers,
celebrates anniversaries while travelling,
requires vegetarian meals,
usually books airport transfers after landing.

Now imagine it applying those preferences automatically across future bookings.
No prompts.
No repeated instructions.
Just accumulated operational knowledge.
That's where autonomous systems begin to create real value.

Building Hermes TravelOps
This idea led me to build Hermes TravelOps—an autonomous operations agent for travel businesses.
The goal wasn't another chatbot.
The goal was something that behaves more like an experienced operations coordinator.
An ideal operational agent should be able to:

monitor bookings continuously,
detect potential disruptions before customers notice,
preserve organizational knowledge,
coordinate multiple workflows,
improve after every completed trip.

The interesting engineering challenge isn't generating text.
It's designing systems that remember, observe, decide, and execute safely.

The Hard Part Isn't AI
Ironically, the hardest part hasn't been prompting large language models.
It's engineering everything around them:

state management,
workflow orchestration,
memory,
event handling,
recovery from failures,
trust,
human approval when needed.

The intelligence isn't a single model.
It's the architecture.

Where I Think Travel Tech Is Heading
Over the next few years, I expect travel companies to rely less on dashboards and more on autonomous operational systems.
Instead of logging into ten different platforms every morning, operations teams may simply review:

"Here's what happened overnight.
Here are the issues already resolved.
Here are the three decisions that still require human approval."

That changes the role of operations from reacting to supervising.

I'm Curious What Others Think
If you're building with AI or working in travel operations, I'd love your perspective.
A few questions to start the discussion:

Where do you see the biggest operational bottleneck today?
Would you trust an autonomous agent to handle customer bookings if every action were fully auditable?
What's the biggest challenge you've encountered when moving from AI demos to production systems?

I'm especially interested in hearing from engineers, travel operators, and founders building systems that go beyond chat.
The next generation of AI may not be the one that talks the best.
It may be the one that quietly gets the work done.

From Hidden Data Loss to Reliable Bookings: Finishing Demic Ride with GitHub Copilot

Christopher Mburu — Fri, 05 Jun 2026 12:33:35 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Demic Ride is a corporate taxi dispatch and ride-hailing platform for Demic Tours Africa, built on Next.js, Supabase, and Tailwind, deployed on Render at ride.demicafrica.com. It handles passenger booking, automatic driver dispatch, live GPS tracking, and a pay-after-ride flow.

The MVP was already live — but "live" hid a problem. A booking form that looked finished was silently throwing away data on every submission. Finishing this project meant catching the bug that nobody had noticed because it never produced an error.

Demo

Live: ride.demicafrica.com
Repo (challenge branch): Demic-Africa/demic-ride @ finish-up-athon

The Comeback Story

Before vs After

Before

Schedule data was collected but not stored
Missing database columns
Weak validation around booking schedules
Dispatch failures were not handled gracefully

After

Schedule data persists correctly
Database migrations are version controlled
Validation prevents incomplete bookings
Dispatch failures no longer break the booking workflow
Analytics dashboard provides operational visibility

What I changed:

Added the missing columns via a version-controlled migration (scheduled_date, scheduled_time, notes). The schema had only ever lived in the Supabase dashboard, so this also put it into git for the first time.
Added real validation for date/time, with an inline error instead of a native alert().
Wrapped dispatch in try/catch so a failure now saves the booking and shows an honest "driver will be assigned shortly" state instead of a fake success.

One honest note: the booking failure I first screenshotted turned out to be the Supabase project auto-pausing on the free tier, not a code bug — resuming it restored bookings. The real, code-level issue was the silent data loss above. I kept that distinction clear in my project journal.

My Experience with GitHub Copilot

I used Copilot in two distinct ways, and I want to be precise about which was which.

As a reviewer for the fixes above. I'd written the migration, validation, and error handling, then ran them past Copilot with my repo as context to check my work and confirm root cause. In one session I asked it to update the date/time validation — and it correctly told me the validation was already right, pointed at the exact line, and suggested a more granular per-field error pattern instead. In another it walked the booking-failure root cause and explained exactly why the missing columns caused silent data loss. Having an AI confirm or push back on a fix you've already made is underrated: it caught nothing catastrophic, but it tightened my reasoning and my dispatch error-handling pattern.

As an author for net-new code: the fleet analytics dashboard. This one Copilot built. I gave it my real bookings and drivers columns and asked for an admin analytics component using the app's existing styles. It generated the component; I corrected the one thing it guessed wrong (the driver-status query column), wired it into an /admin/dashboard route, and it rendered live data on the first build.

Example: Database Migration

Prompt:

"Generate a Supabase migration to add scheduled_date, scheduled_time, and notes columns using IF NOT EXISTS."

Copilot Output:

Generated migration structure
Suggested safe ALTER TABLE statements
Explained rollback considerations

Outcome:

The missing fields were added and booking schedule data now persists correctly.

Links

Repository:
https://github.com/Demic-Africa/demic-ride/tree/finish-up-athon

Live Demo:
https://ride.demicafrica.com

Hermes TravelOps: An Agent That Learns From Every Trip

Christopher Mburu — Sun, 31 May 2026 17:13:27 +0000

What I Built

Hermes TravelOps Agent — an autonomous travel operations manager built natively on Hermes Agent. It remembers each traveler's preferences without prompting, researches flights and hotels via web search, flags risks, and runs a post-trip debrief that rewrites its own memory so the next trip plan is automatically different. No external backend: memory, skills, and scheduling are all Hermes's own.

The Problem

Travel coordinators repeat the same operational loop for every trip: research flights and hotels against a traveler's quirks, check visas, assemble an itinerary, monitor for disruptions, and — the part every tool ignores — learn from how the trip actually went. Most AI travel tools answer a question and forget you. I wanted one that operates and remembers.

Architecture: Hermes IS the Stack

~/.hermes/
├── skills/
│   ├── travel-plan-request/SKILL.md   ← Multi-step planning
│   └── post-trip-debrief/SKILL.md     ← Learning loop
├── context/
│   └── TRAVEL_OPS_CONTEXT.md          ← Domain knowledge
├── memories/
│   └── MEMORY.md                      ← Persistent memory (FTS5)
└── SOUL.md                            ← Agent persona

Hermes handles memory, web search, skill execution, and scheduling natively. It's model-agnostic — this demo runs on gemini-3-flash-preview through Hermes's provider layer, and nothing in the project depends on which model sits underneath.

Demo data is seeded. I loaded two traveler profiles and one prior-trip record into memory before recording, so the learning loop has history to work against. Trip dates are fixture data, not live calendar events. What the agent does — recall, research, debrief, re-plan — is real and unscripted.

The Demo

Command 1 — Plan a trip: Plan a trip for Sarah to Dubai next week

Hermes loaded the planning skill, fired three web searches, and returned one recommendation with every stored preference already applied — without me restating any of them: Emirates EK720, window seat (enforced), vegetarian (matched), non-stop, Marriott Palm Jumeirah, WiFi 5/5, visa valid to 2027-03-15, ~$850, ending at "pending approval."

Command 2 — Visa check: Check visa for Sarah going to UAE → Valid, multi-entry, expiry 2027-03-15, no action required.

Command 3 — Post-trip debrief: Sarah is back from Dubai. Emirates was 4/5 but the layover in DXB was 6 hours and she was frustrated.

This triggered the post-trip-debrief skill. The memory tool fires repeatedly in the recording — including failed lookups before the write lands, which is what a real agent retrying looks like. It marked the 6hr layover "strictly unacceptable," added a directive to enforce direct Emirates flights for NBO-DXB, and wrote the lesson to memory.

Command 4 — Prove the memory changed: cat ~/.hermes/memories/MEMORY.md | grep -A2 "Sarah Chen"

The file now reads max 3hr layover and carries the dated lesson. It changed because the agent rewrote it — no update script, no external database.

Command 5 — Re-plan, watch it apply what it learned: Plan another trip for Sarah to Dubai next month

With zero prompting, the new plan enforced the constraint the debrief created: non-stop only, "EK720 selected explicitly to avoid the 6-hour layover friction reported in June," and Marriott Palm Jumeirah prioritized over Business Bay on a previously-logged WiFi rating.

Why This Uses Hermes Properly

Build criterion #1 is "effective use of Hermes Agent's agentic capabilities." I used Hermes native memory (FTS5 + MEMORY.md) instead of a database, Hermes skills instead of custom orchestration, Hermes built-in web search instead of a bolted-on service, and a skill-driven post-trip loop that writes back to memory and changes future behavior. A handful of files, no infrastructure, model-swappable underneath.

Try It Yourself

git clone https://github.com/tourswithchris/hermes-travel-ops-native.git
cd hermes-travel-ops-native
cp -r skills/* ~/.hermes/skills/
cp context/TRAVEL_OPS_CONTEXT.md ~/.hermes/context/
cp memories/* ~/.hermes/memories/
cp SOUL.md ~/.hermes/
hermes chat
# Then: Plan a trip for Sarah to Dubai next week

Repo: https://github.com/tourswithchris/hermes-travel-ops-native