AI Cities para apps de turismo: doze cidades já conectadas, uma integração e o produto de viagem que você pode entregar

Desde que a AI Cities entrou no ar, a pergunta que recebi mudou de forma. Antes era "o que é um Connector". Agora é "posso construir um produto em cima disso", e quem pergunta não é gente de plataforma. São pessoas que gerenciam organizações de marketing de destino, constroem planejadores de viagem, operam produtos de concierge de hotel, e todas chegam com a mesma planilha: a lista de APIs que teriam que integrar para cobrir uma única cidade como deve ser.

Esse post responde com um inventário, uma arquitetura e as partes que são difíceis. A versão curta: turismo é o domínio onde uma cidade conectada mapeia quase um para um com um produto de consumo. Um viajante toca seis dos oito sistemas de uma cidade nas primeiras setenta e duas horas, cada um desses toques já é uma leitura ao vivo, e a integração que você escreveria para uma cidade é a mesma integração para doze.

Por que turismo é a primeira superfície de produto para uma cidade conectada

Na AI Cities uma cidade é organizada em oito sistemas: mobilidade, energia, meio ambiente, serviços públicos, cultura, geografia, comércio e segurança. É assim que um governo municipal pensa sobre si mesmo. Não é assim que um visitante pensa, e a lacuna entre os dois é onde um produto de viagem vive.

Pegue um visitante em Amsterdã por três dias. Mobilidade é a estação de bicicletas, o bonde, a zona de estacionamento que ele nunca mais vai achar. Cultura é o que tem hoje à noite e se ainda existem dois ingressos. Meio ambiente é a faixa de chuva chegando às nove e o ar perto da água. Serviços públicos é o endereço, o registro do monumento, o conjunto de dados aberto por trás dos dois. Geografia é a distância, a elevação, a rota que evita a ladeira. Comércio é o preço e o cartão. Segurança é a obra que fecha a rota do canal às seis.

Seis dos oito sistemas de uma cidade, cruzados no primeiro dia, sem que o visitante jamais aprenda o nome de um sistema. Nenhuma outra categoria de produto toca uma cidade de forma tão ampla e tão rápido.

O segundo motivo é a forma da carga de trabalho. Turismo é leitura pesada e escrita leve. Um visitante faz mil perguntas e reserva um punhado de coisas, o que é a carga de trabalho ideal para um plano de dados que lê ao vivo da fonte no momento do pedido e, onde um Connector pode agir, age em um serviço em vez da cidade. Nosso próprio contrato na página da AI Cities é explícito: nada aqui dá a um agente controle sobre infraestrutura pública. Para um produto de viagem isso não é uma limitação. É o contrato correto.

O terceiro motivo é aritmética. Todo produto de viagem que eu revisei carrega a mesma linha de custo oculta: as integrações. Uma cidade coberta direito significa transporte público, bike sharing, estacionamento, clima, qualidade do ar, eventos, bilheteria, geocoding e o portal de dados abertos local, cada um com sua própria chave, seu próprio limite de taxa, sua própria forma de erro, e o seu próprio dia em que muda. Multiplique isso pelas cidades onde você quer estar e você tem a razão pela qual a maioria dos produtos de viagem para em três mercados.

O inventário honesto: o que está realmente conectado

Doze cidades estão no ar em beta: Amsterdã, Berlim, Lisboa, Londres, Madri, Moscou, Nova York, Paris, Rio de Janeiro, San Francisco, Singapura e Tóquio. Cada uma é sustentada por Connectors para os seus próprios sistemas, e não por um feed genérico mundial.

Amsterdã é a mais completa, então é a que vou citar com precisão: oito sistemas no ar hoje em 40 Connectors. Em mobilidade há CityBikes para o bike sharing ao vivo, TomTom Parking Availability, Google Maps, Mapbox, Uber, e o próprio conjunto de dados de Zonas de Estacionamento e Trânsito da cidade, sem chave. Em cultura há o acervo do Rijksmuseum, Eventbrite, Ticketmaster, Bandsintown, e o conjunto de dados da cidade com eventos registrados, locais e esportes. Em meio ambiente e segurança há AccuWeather, AirVisual, AQICN, OpenWeather, Open-Meteo, o próprio feed de incidentes da cidade para apagões e obras, e previsões de inundação do Global Flood Awareness System. Em serviços públicos há o explorador de dados abertos DSO com mais de 122 conjuntos de dados, o registro de endereços BAG, os calendários de coleta de resíduos e reciclagem, e o portal de dados abertos da UE.

Leia essa lista de novo, porque a mistura é o ponto. Aproximadamente metade são APIs comerciais com uma conta por trás. Aproximadamente metade são os próprios registros da cidade, acessíveis sem chave de API nenhuma. Um produto de viagem precisa dos dois: os feeds comerciais dão cobertura e qualidade, os feeds municipais dão os fatos que só uma cidade conhece, como qual cais está fechado ou qual árvore caiu na tempestade.

Duas regras vêm com esse inventário, e eu exigiria isso de qualquer time. A primeira: a página da cidade diz quais sistemas estão conectados hoje e quais ainda estão sendo ligados, então você compromete features com o que existe e não com um roadmap. A segunda: tudo naquela página é uma leitura ao vivo no momento em que você pergunta. Nada está em cache prévio, então seu produto não pode publicar um horário desatualizado e culpar a plataforma por isso.

Isso não é só mais uma API de viagem

Viagem tem APIs há décadas. O mundo da Amadeus e da Duffel, a linhagem do GDS, resolve inventário: assentos, tarifas, reservas, trocas. É excelente na transação e não sabe nada sobre o lugar. Aquelas APIs podem dizer qual voo pousa às 14:00. Não podem dizer que a estrada para o hotel fecha às seis, que o AQI ao longo do corredor está subindo, ou que o único show de hoje à noite fica a três paradas.

O lado da cidade responde a esse segundo conjunto de perguntas, e os dois são complementares, não concorrentes. Um produto que tem a tarifa mas não tem a rua é um motor de reservas. Um produto que tem a rua mas não tem a tarifa é um guia. O produto interessante tem os dois, e até agora ter os dois significava manter dois programas de integração com duas curvas de manutenção diferentes.

Essa é a mudança real. As APIs de transação sempre vão ser um commodity que você aluga. O lado da cidade nunca esteve disponível como commodity de jeito nenhum: você integrava uma prefeitura, ou não tinha os dados. A AI Cities torna o lado da cidade alugável da mesma forma, com o mesmo padrão de chamada, para toda cidade que estiver conectada.

A arquitetura: uma integração, doze cidades

Por baixo dos panos cada Connector é exposto sobre MCP, o protocolo aberto que os assistentes que você já usa falam. Sua aplicação é identificada por um par de chaves que você cria uma vez no dashboard: um app id público e uma application key secreta. Você endereça os seus próprios viajantes pelo id que já lhes atribui, e para cada um deles o SDK devolve um handle com escopo para os sistemas da cidade que eles conectaram. A Vinkius provisiona a conexão, guarda as credenciais e executa por trás de um plano de dados governado. Seu código não carrega nenhuma chave upstream, nenhum fluxo OAuth, nenhum loop de retry por cidade.

A unidade de escopo é o viajante, não o tenant, e essa é a decisão de design que eu defenderia com mais força em um produto de viagem. Um concierge que consegue alterar a reserva de alguém só é seguro quando a reserva que ele toca pertence à pessoa que perguntou. Os Connectors de cada viajante são conexões isoladas com seus próprios tokens, enumeradas e executadas dentro do próprio runtime, medidas separadamente e paradas separadamente. O isolamento é imposto pela forma do caminho dos dados, não por um documento de política.

Aqui está o loop, direto da amostra do SDK, com os sistemas da cidade do viajante como o conjunto de ferramentas:

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 ?? '';
}

Não há código específico de cidade nessa função. Ela não sabe que está em Amsterdã. A cidade chega através das capacidades que o viajante conectou, e é por isso que a mesma função serve doze cidades e a décima terceira sem um branch.

Exemplo prático: uma pergunta, cinco sistemas

"Pousamos às 14:00 com uma criança e um carrinho. Onde jantamos hoje perto do museu, e como chegamos lá se chover?"

Rastreie o que precisa acontecer antes dessa resposta ser honesta:

1. Resolva o hotel e o museu para coordenadas. Geografia: LocationIQ ou OpenCage.
2. Leia a faixa de chuva e a qualidade do ar para aquela janela. Meio ambiente: Open-Meteo e AccuWeather, AQICN para o corredor.
3. Leia o que tem hoje à noite perto daquele endereço, e se existem dois ingressos. Cultura: o conjunto de dados de eventos da cidade, Eventbrite, Ticketmaster.
4. Verifique o feed de incidentes para a rota que você estava prestes a recomendar. Segurança: o próprio conector de status e incidentes da cidade.
5. Escolha o deslocamento: bicicletas na estação, o bonde, ou estacionamento perto do local. Mobilidade: CityBikes, TomTom, Google Maps.

Cinco sistemas, uma conversa, e o viajante nunca instalou nada. Cada passo é uma chamada de ferramenta que o modelo escolheu, cada resultado é uma leitura ao vivo, e toda chamada cai na trilha de auditoria com o id do viajante anexado. Se o passo quatro voltar com um cais fechado, a resposta muda antes de você enviá-la, não depois que o hóspede já está lá em pé.

O que é difícil, dito de forma direta

A variação por cidade é real. Amsterdã tem oito sistemas conectados em 40 Connectors. Outra cidade da lista pode estar no ar em mobilidade e meio ambiente enquanto serviços públicos ainda está sendo conectado. A resposta de engenharia é enumerar capacidades em runtime e projetar para um conjunto que muda, não hardcodar uma matriz de cidades na sua config. A resposta para o usuário é honestidade: dizer o que está disponível, e onde.

A frescura é a promessa inteira. Um produto de viagem vive ou morre com o fato de o bonde estar de fato operando. As leituras acontecem no momento do pedido, então o modo de falha para o qual você projeta não é dado desatualizado, é o upstream ficar brevemente indisponível. Trate falhas de nível de ferramenta como resultados e não como exceções, e deixe o modelo dizer claramente que ele não sabe agora, em vez de inventar um horário de partida.

As ações são propositalmente estreitas. Onde um Connector pode agir, ele age no serviço: segurar uma reserva, reservar um lugar. Nunca age em infraestrutura pública. Construa em cima de leituras e um número pequeno de escritas explícitas e você nunca vai encontrar o limite. Projete um produto que assume que pode reprogramar o transporte de uma cidade e você projetou algo que não pode ser publicado.

Toda chamada fica registrada. Tudo roda na Vinkius: execução V8 isolada por conexão, mais de 34 regras de segurança, uma trilha de auditoria assinada de cada ação, limites de gasto que pausam em vez de surpreender, e uma única chave que para todos os agentes. Para um produto de viagem de consumo isso é a diferença entre "a nossa IA fez uma coisa estranha ontem à noite" e um recibo que nomeia a ferramenta, o viajante e o timestamp. O plano de controle está coberto com código em AI Governance: o plano de controle por trás de cada chamada de ferramenta que seus agentes fazem, e a sandbox em si em Zero cold starts para código não confiável.

Quatro produtos que você pode publicar neste trimestre

Um concierge de viagem de um dia. Chat primeiro, sem download, sem login por serviço. Chuva às nove, bicicletas na estação perto do escritório, ingressos para dois antes do jantar, o último trem às 22:50. Toda entrada nessa conversa é uma leitura ao vivo que você já tem.

Um roteador consciente de conforto e acessibilidade. O itinerário que evita a ladeira, o corredor com AQI alto, o cais fechado e os degraus da estação. Qualidade do ar, elevação, incidentes e roteirização são Connectors separados, compô-los é o produto, e nenhum app de mapas existente os compõe.

Um back office de destino. Para uma organização de marketing de destino ou um grupo de hotéis: os eventos de hoje, os locais de hoje à noite, os conjuntos de dados abertos e o feed de incidentes, alimentando um site ou um assistente de mensagens que responde no idioma do visitante em vez de uma página estática atualizada pela última vez na primavera passada.

Uma camada de cidade para uma plataforma de viagem existente. Se você já tem os usuários e as reservas, a alavanca é diferente: uma integração, e toda cidade que for conectada vira um mercado que você pode abrir sem lançar um novo projeto de integração.

A construção começa onde a conexão termina

O demo da AI Cities é perguntar ao seu assistente sobre uma cidade e receber uma resposta ao vivo. Isso não é o produto. O produto é o que você constrói sobre os mesmos Connectors, para viajantes que nunca vão saber que havia um protocolo por baixo.

Comece pelo índice da AI Cities, abra a cidade que te interessa, e leia quais sistemas estão no ar hoje. Depois conecte-a com o AI Connect SDK e construa o app local que deveria ter existido.