Masapalu
Eine Hotel-Companion-App mit eigenen KI-Agents — von Personas und Scope bis zum funktionierenden Multi-Agent-System.
Eine Hotel-Companion-App, in der unsere eigenen KI-Agents Zimmer zuweisen, Aktivitäten und Restaurants empfehlen und freie Buchungsslots finden. Zu viert sind wir von Research und Scope bis zu einer funktionierenden React-Native-App mit Multi-Agent-Backend gekommen.
- Rolle
- Entwickler — KI-Agents & Mobile App
- Team
- Marcia Perez, Sara Schramm, Paul Wipper
- Kontext
- Mobile Applications — HM München
- Tools
- React Native / Expo, FastAPI, CrewAI, Ollama · Llama 3.1, MongoDB, Figma
Das Problem
Hotelgäste jonglieren zwischen Rezeption, gedruckten Speisekarten, Buchungsschaltern und Stadtführern — und das Erlebnis ist für alle gleich. Wir haben die Challenge so formuliert: How might we allen Gästen einfachen Zugang zu sämtlichen Hotelservices bieten, damit sich jeder Aufenthalt angenehm und persönlich anfühlt?
Zwei sehr unterschiedliche Nutzer
Wir haben für die Extreme gestaltet, damit alle dazwischen mit abgedeckt sind:
- Hildegard, 68 — pensionierte Lehrerin, wenig technikaffin. Braucht direkten Kontakt, Kulturtipps und keine versteckten Kosten. „Bitte belästigen Sie mich nicht mit komplizierter Technik.“
- Marcus, 44 — Vertriebsleiter, sehr technikaffin, erwartet ein Kind. Will kontaktlosen Check-in, Zimmerservice ohne Anruf und familienfreundliche Angebote.
Wir haben rund 30 Jobs-to-be-done in vier Clustern erfasst (Essen & Getränke, Entspannung & Freizeit, Concierge, Entdecken & Mobilität) und eine Stakeholder-Map erstellt, von den Gästen über Housekeeping und IT bis zu Buchungsplattformen.
Scope
Drin: Check-in/-out, Buchung von Aktivitäten, personalisierte Empfehlungen, Restaurants, Transport, Abrechnung, lokale Events. Draußen: Flug- und Hotelbuchung, echte Zahlungen, VIP-Status — wertvoll, aber nicht nötig, um das Konzept zu beweisen.
KI dort, wo sie Mehrwert schafft
Wir haben keinen Chatbot gebaut. Jeder Agent erledigt genau einen Job, von dem der Gast profitiert, mit Geschäftsregeln direkt in den Prompts:
| Agent | Job |
|---|---|
| Concierge | Weist beim Check-in ein Zimmer zu und macht wenn möglich ein Upgrade (Penthouse → Suite → Deluxe …) |
| Aktivitätsberater | Wählt fünf Aktivitäten, die zu Alter, Barrierefreiheitsbedürfnissen und Besonderheiten des Gastes passen — erfindet nie Aktivitäten |
| Buchungskoordinator (meine Crew) | Zerlegt den Aufenthalt in einzelne Tage und gibt nur Zeitslots zurück, die sich nicht mit bestehenden Buchungen überschneiden |
| Gastronomie | Empfiehlt ein Restaurant im Hotel anhand von Vorlieben, Ernährung und Öffnungszeiten — keine Bars für unter 18-Jährige |
Ein lokales Modell statt einer kostenpflichtigen API. Die Agents laufen auf Llama 3.1 über Ollama. Kleine lokale Modelle sind weniger zuverlässig, deshalb haben wir sie mit strikten JSON-Output-Verträgen und expliziten Regeln gesteuert — und die Daten deterministisch in Python abgerufen, bevor das Modell den Kontext bekommt.
16 Agents geplant, 4 ausgeliefert
Das Konzept sah fünf Crews mit rund 16 Agents vor. Ausgeliefert haben wir vier Crews mit je einem Agent, die end-to-end funktionieren. Die Crews „Explore“ und „Relax“ habe ich selbst zu einer Aktivitäts-Crew zusammengelegt — wenige gute Agents schlagen viele halb funktionierende.
Mein Anteil
- Repository und Projektstruktur für App und Backend aufgesetzt.
- Die Buchungskoordinator-Crew (Utility) und die Explore-Crew gebaut und anschließend Explore und Relax zur Aktivitäts-Crew zusammengeführt.
- Die Datenbank sowie die APIs für Zimmer und Aktivitäten aufgesetzt.
- In der App: den Home-Screen (Wetter, Termine, Empfehlungen), Termindetails und Stornierung, den Profilbereich und die eigene Navigationsleiste.
- Das Feedback aus unseren Nutzertests in den finalen Build eingearbeitet.
Was ich gelernt habe
KI-Features sind Produkt-Features: Sie brauchen einen klaren Job, Leitplanken und einen Fallback. Und zu viert waren Issues, Branches und Pull Requests keine Bürokratie — sie waren unser Weg, ein gemeinsames Bild vom Produkt zu behalten.