AI Cities für Tourismus-Apps: zwölf bereits verdrahtete Städte, eine Integration und das Reiseprodukt, das ihr ausliefern könnt

Seit AI Cities live ist, hat sich die Frage verändert, die ich gestellt bekomme. Früher hieß sie „Was ist ein Connector?“. Heute heißt sie „Kann ich darauf ein Produkt bauen?“, und die Fragenden sind keine Plattform-Leute. Sie führen Destination-Marketing-Organisationen, sie bauen Reiseplaner, sie betreiben Hotel-Concierge-Produkte, und alle kommen mit derselben Tabelle: der Liste der APIs, die sie integrieren müssten, um eine einzige Stadt ordentlich abzudecken.

Dieser Beitrag beantwortet das mit einem Inventar, einer Architektur und den Teilen, die schwer sind. Die Kurzfassung: Tourismus ist die Domäne, in der eine verkabelte Stadt fast eins zu eins auf ein Verbraucherprodukt abbildet. Ein Reisender berührt in den ersten 72 Stunden sechs der acht Systeme einer Stadt, jedes dieser Berührungen ist bereits ein Live-Read, und die Integration, die du für eine Stadt geschrieben hättest, ist dieselbe Integration für zwölf.

Warum Tourismus die erste Produktfläche für eine verkabelte Stadt ist

Auf AI Cities ist eine Stadt in acht Systeme organisiert: Mobilität, Energie, Umwelt, öffentliche Dienste, Kultur, Geografie, Handel und Sicherheit. So denkt eine Stadtregierung über sich selbst. So denkt ein Besucher nicht, und die Lücke dazwischen ist der Ort, an dem ein Reiseprodukt lebt.

Nehmen wir einen Besucher in Amsterdam, drei Tage. Mobilität ist das Fahrrad-Dock, die Straßenbahn, die Parkzone, die er nie zum zweiten Mal findet. Kultur ist, was heute Abend läuft und ob noch zwei Tickets existieren. Umwelt ist die Regenfront, die um neun ankommt, und die Luft am Wasser. Öffentliche Dienste sind die Adresse, der Denkmaldatensatz, der offene Datensatz dahinter. Geografie ist die Entfernung, die Höhe, die Route, die den Hügel umgeht. Handel ist der Preis und die Karte. Sicherheit ist die Baustelle, die die Kanalroute um sechs sperrt.

Sechs der acht Systeme einer Stadt, am ersten Tag gekreuzt, ohne dass der Besucher je den Namen eines Systems lernt. Keine andere Produktkategorie berührt eine Stadt so breit und so schnell.

Der zweite Grund ist die Form der Workload. Tourismus ist lesestark und schreibschwach. Ein Besucher stellt tausend Fragen und bucht eine Handvoll Dinge, was die ideale Workload für eine Datenebene ist, die zum Zeitpunkt der Anfrage live aus der Quelle liest und, wo ein Connector handeln kann, auf einen Dienst handelt und nicht auf die Stadt. Unser eigener Vertrag auf der AI Cities-Seite ist eindeutig: Nichts hier gibt einem Agenten Kontrolle über öffentliche Infrastruktur. Für ein Reiseprodukt ist das keine Einschränkung. Es ist der richtige Vertrag.

Der dritte Grund ist Arithmetik. Jedes Reiseprodukt, das ich geprüft habe, trägt dieselbe versteckte Position: die Integrationen. Eine Stadt ordentlich abdecken bedeutet Transit, Bikesharing, Parken, Wetter, Luftqualität, Events, Ticketing, Geocoding und das lokale offene Datenportal, jedes mit eigenem Key, eigener Rate-Limit, eigener Fehlerform und dem einen Tag, an dem es sich ändert. Multipliziere das mit den Städten, in denen du sein willst, und du hast den Grund, warum die meisten Reiseprodukte bei drei Märkten stoppen.

Das ehrliche Inventar: was wirklich verkabelt ist

Zwölf Städte sind in der Beta live: Amsterdam, Berlin, Lissabon, London, Madrid, Moskau, New York, Paris, Rio de Janeiro, San Francisco, Singapur und Tokio. Jede wird von Connectoren auf ihre eigenen Systeme gestützt, nicht von einem generischen Welt-Feed.

Amsterdam ist am vollständigsten, also ist es die Stadt, die ich präzise zitieren werde: acht Systeme heute live über 40 Connectoren. Bei der Mobilität gibt es CityBikes für Live-Bikesharing, TomTom Parking Availability, Google Maps, Mapbox, Uber und den eigenen Datensatz für Park- und Verkehrszonen der Stadt, ohne Key. Bei der Kultur das Rijksmuseum-Archiv, Eventbrite, Ticketmaster, Bandsintown und den registrierten Event-, Veranstaltungsort- und Sportdatensatz der Stadt. Bei Umwelt und Sicherheit AccuWeather, AirVisual, AQICN, OpenWeather, Open-Meteo, den eigenen Störungs-Feed der Stadt für Ausfälle und Baustellen und Hochwasserprognosen vom Global Flood Awareness System. Bei den öffentlichen Diensten den DSO-Open-Data-Explorer mit mehr als 122 Datensätzen, das BAG-Adressregister, Abfall- und Recyclingpläne und das EU-Open-Data-Portal.

Lies dir diese Liste noch einmal durch, denn die Mischung ist der Punkt. Etwa die Hälfte sind kommerzielle APIs mit einem Konto dahinter. Etwa die Hälfte sind die eigenen Aufzeichnungen der Stadt, erreichbar ganz ohne API-Key. Ein Reiseprodukt braucht beides: die kommerziellen Feeds liefern Abdeckung und Qualität, die städtischen Feeds liefern die Fakten, die nur eine Stadt kennt, wie welcher Kai gesperrt ist oder welcher Baum im Sturm umgefallen ist.

Zwei Regeln kommen mit diesem Inventar, und ich würde jedes Team daran festhalten. Die erste: die Stadtseite sagt, welche Systeme heute verkabelt sind und welche noch angebunden werden, damit du Features an dem ausrichtest, was es gibt, und nicht an einer Roadmap. Die zweite: Alles auf dieser Seite ist ein Live-Read zum Zeitpunkt deiner Anfrage. Nichts ist vorab gecacht, damit dein Produkt keinen veralteten Fahrplan ausliefern und die Plattform dafür verantwortlich machen kann.

Das ist keine weitere Travel-API

Reisen hat seit Jahrzehnten APIs. Die Welt von Amadeus und Duffel, die GDS-Linie, löst Inventar: Sitze, Tarife, Buchierungen, Umbuchungen. Sie ist exzellent in der Transaktion und weiß nichts über den Ort. Diese APIs können dir sagen, welcher Flug um 14:00 landet. Sie können dir nicht sagen, dass die Straße zum Hotel um sechs sperrt, dass der AQI entlang des Korridors steigt oder dass das einzige Konzert heute Abend drei Stationen entfernt liegt.

Die Stadt-Schicht beantwortet diese zweite Gruppe von Fragen, und die zwei sind Ergänzungen statt Konkurrenten. Ein Produkt, das den Tarif hat, aber nicht die Straße, ist eine Buchungsmaschine. Ein Produkt, das die Straße hat, aber nicht den Tarif, ist ein Guide. Das interessante Produkt hat beides, und beides zu haben bedeutete bisher, zwei Integrationsprogramme mit zwei verschiedenen Wartungskurven zu besitzen.

Das ist der eigentliche Wechsel. Die Transaktions-APIs wären sowieso eine Commodity geblieben, die du mietest. Die Stadtseite war nie als Commodität verfügbar: Du hast eine Kommune integriert, oder du hattest die Daten nicht. AI Cities macht die Stadtseite auf dieselbe Weise mietbar, mit demselben Aufrufmuster, für jede Stadt, die verkabelt ist.

Die Architektur: eine Integration, zwölf Städte

Unter der Haube wird jeder Connector über MCP exponiert, das offene Protokoll, das die Assistenten sprechen, die du bereits nutzt. Deine Anwendung wird über ein Paar Keys identifiziert, das du einmal im Dashboard erstellst: eine öffentliche App-ID und ein geheimer Application-Key. Du addressierst deine eigenen Reisenden über die ID, die du ihnen bereits zuweist, und für jeden von ihnen gibt das SDK ein auf den Scope begrenztes Handle auf die Stadtsysteme zurück, die sie verbunden haben. Vinkius richtet die Verbindung ein, hält die Zugangsdaten und führt sie hinter einer gesteuerten Datenebene aus. Dein Code trägt keinen Upstream-Key, keinen OAuth-Flow, keine Retry-Schleife pro Stadt.

Die Scope-Einheit ist der Reisende, nicht der Mandant, und das ist die Designentscheidung, die ich in einem Reiseprodukt am härtesten verteidigen würde. Ein Concierge, der die Buchung von jemandem ändern kann, ist nur dann sicher, wenn die Buchung, die er anfasst, der Person gehört, die fragt. Die Connectors jedes Reisenden sind isolierte Verbindungen mit eigenen Tokens, aufgezählt und ausgeführt in ihrer eigenen Runtime, getrennt abgerechnet und getrennt gestoppt. Die Isolation wird durch die Form des Datenpfads erzwungen, nicht durch ein Richtliniendokument.

Hier ist die Schleife, direkt aus dem SDK-Beispiel, mit den Stadtsystemen des Reisenden als Tool-Set:

import OpenAI from 'openai';
import { Vinkius } from '@vinkius/connect';
import { toOpenAITools, runOpenAIToolCall } from '@vinkius/connect/openai';

const openai = new OpenAI();
const MODEL = process.env.OPENAI_MODEL ?? 'your-model-id';

const vinkius = new Vinkius({
  appId: process.env.VINKIUS_APP_ID!,
  apiKey: process.env.VINKIUS_APP_KEY!,
});

export async function concierge(userId: string, question: string) {
  const caps = await vinkius.user(userId).capabilities();
  if (caps.length === 0) {
    return 'Connect a city first and I can answer that live.';
  }

  const tools = toOpenAITools(caps);
  const messages = [{ role: 'user', content: question }];

  for (let step = 0; step < 4; step++) {
    const reply = await openai.chat.completions.create({ model: MODEL, messages, tools });
    const msg = reply.choices[0]?.message;
    if (!msg?.tool_calls?.length) break;

    messages.push(msg);
    for (const call of msg.tool_calls) {
      const result = await runOpenAIToolCall(caps, call, {
        idempotencyKey: `${userId}:${call.id}`,
      });
      const text = result.content.map((c) => c.text).join('\n');
      messages.push({
        role: 'tool',
        tool_call_id: call.id,
        content: result.isError ? `The tool reported an error: ${text}` : text,
      });
    }
  }

  return reply?.choices[0]?.message?.content ?? '';
}

In dieser Funktion gibt es keinen stadtspezifischen Code. Sie weiß nicht, dass sie in Amsterdam ist. Die Stadt kommt über die Capabilities, die der Reisende verbunden hat, weshalb dieselbe Funktion zwölf Städte und die dreizehnte ohne einen Zweig bedient.

Durchgerechnetes Beispiel: eine Frage, fünf Systeme

„Wir landen um 14:00 mit einem Kind und einem Kinderwagen. Wo essen wir heute Abend in der Nähe des Museums, und wie kommen wir hin, wenn es regnet?“

Verfolge, was passieren muss, bevor diese Antwort ehrlich ist:

1. Hotel und Museum auf Koordinaten auflösen. Geografie: LocationIQ oder OpenCage.
2. Regenfront und Luftqualität für dieses Fenster lesen. Umwelt: Open-Meteo und AccuWeather, AQICN für den Korridor.
3. Lesen, was heute Abend in der Nähe dieser Adresse läuft, und ob zwei Tickets existieren. Kultur: der Event-Datensatz der Stadt, Eventbrite, Ticketmaster.
4. Den Störungs-Feed für die Route prüfen, die du gerade empfehlen wolltest. Sicherheit: der eigene Status- und Incidents-Connector der Stadt.
5. Die Bewegung wählen: Räder am Dock, die Straßenbahn oder Parken in der Nähe des Veranstaltungsortes. Mobilität: CityBikes, TomTom, Google Maps.

Fünf Systeme, ein Gespräch, und der Reisende hat nie etwas installiert. Jeder Schritt ist ein Tool-Call, den das Modell gewählt hat, jedes Ergebnis ist ein Live-Read, und jeder Call landet im Audit-Trail mit der Reisenden-ID. Wenn Schritt vier mit einem gesperrten Kai zurückkommt, ändert sich die Antwort, bevor du sie sendest, nicht erst, wenn der Gast dort steht.

Was schwer ist, klar gesagt

Die Varianz pro Stadt ist real. Amsterdam hat acht Systeme über 40 Connectoren verkabelt. Eine andere Stadt auf der Liste kann bei Mobilität und Umwelt live sein, während die öffentlichen Dienste noch angebunden werden. Die technische Antwort ist, Capabilities zur Laufzeit aufzuzählen und für eine Menge zu entwerfen, die sich ändert, statt eine Stadt-Matrix in deine Config zu hardcoden. Die Antwort für den Nutzer ist Ehrlichkeit: sagen, was verfügbar ist und wo.

Frische ist das ganze Versprechen. Ein Reiseprodukt lebt oder stirbt daran, ob die Straßenbahn tatsächlich fährt. Reads passieren zum Zeitpunkt der Anfrage, also ist der Fehlermodus, für den du entwickest, nicht veraltete Daten, sondern die kurzzeitige Nichtverfügbarkeit des Upstream. Behandle Tool-Level-Fehler als Ergebnisse statt als Ausnahmen und lass das Modell klar sagen, dass es es jetzt nicht weiß, statt eine Abfahrtszeit zu erfinden.

Aktionen sind absichtlich schmal. Wo ein Connector handeln kann, handelt er auf den Dienst: eine Buchung halten, einen Platz reservieren. Er handelt nie auf öffentliche Infrastruktur. Baue um Reads und eine kleine Zahl expliziter Writes, und du wirst die Grenze nie treffen. Entwirfst du ein Produkt, das davon ausgeht, dass es die Taktung des städtischen Verkehrsnetzes umstellen kann, dann hast du etwas entworfen, das nicht ausgeliefert werden kann.

Jeder Call ist protokolliert. Alles läuft auf Vinkius: isolierte V8-Ausführung pro Verbindung, mehr als 34 Sicherheitsregeln, ein signierter Audit-Trail jeder Aktion, Ausgabenlimits, die pausieren statt zu überraschen, und ein Schalter, der jeden Agenten stoppt. Für ein Verbraucher-Reiseprodukt ist das der Unterschied zwischen „Unsere AI hat letzte Nacht etwas Seltsames gemacht“ und einem Beleg, der das Tool, den Reisenden und den Zeitstempel benennt. Die Control Plane ist abgedeckt mit Quelltext in AI Governance: Die Control Plane hinter jedem Tool Call Ihrer Agenten, und die Sandbox selbst in Zero Cold Starts für nicht vertrauenswürdigen Code.

Vier Produkte, die du in diesem Quartal ausliefern kannst

Ein Tages-Concierge für Reisen. Zuerst Chat, kein Download, kein Login pro Service. Regen um neun, Räder am Dock beim Büro, Tickets für zwei vor dem Essen, der letzte Zug um 22:50. Jede Eingabe in dieses Gespräch ist ein Live-Read, den du bereits hast.

Ein Router, der Komfort und Barrierefreiheit berücksichtigt. Die Route, die den Hügel, den Korridor mit hohem AQI, den gesperrten Kai und die Treppen am Bahnhof umgeht. Luftqualität, Höhe, Incidents und Routing sind getrennte Connectoren, sie zu kombinieren ist das Produkt, und keine etablierte Karten-App kombiniert sie.

Ein Backoffice für Destinationen. Für eine Destination-Marketing-Organisation oder eine Hotelgruppe: die Events von heute, die Veranstaltungsorte von heute Abend, die offenen Datensätze und der Störungs-Feed, die eine Seite oder einen Messaging-Assistenten speisen, der in der Sprache des Besuchers antwortet, statt einer statischen Seite, die zuletzt im Frühjahr aktualisiert wurde.

Eine Stadt-Schicht für eine bestehende Travel-Plattform. Wenn du bereits die Nutzer und die Buchungen hast, ist der Hebel ein anderer: eine Integration, und jede Stadt, die verkabelt wird, wird zu einem Markt, den du öffnen kannst, ohne ein neues Integrationsprojekt auszuliefern.

Der Build beginnt dort, wo die Verkabelung endet

Die Demo von AI Cities ist, deinen Assistenten nach einer Stadt zu fragen und eine Live-Antwort zu bekommen. Das ist nicht das Produkt. Das Produkt ist das, was du auf denselben Connectoren baust, für Reisende, die nie wissen werden, dass es darunter ein Protokoll gab.

Starte beim AI Cities-Index, öffne die Stadt, die dich interessiert, und lies, welche Systeme heute live sind. Dann verkabel sie mit dem AI Connect SDK und baue die lokale App, die es hätte geben sollen.