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
Top comments (0)