For seven years we planned trips only to places we had personally walked. Now we're rebuilding that instinct as software — not a chatbot, and not another itinerary generator, but a travel operating layer: an orchestrator directing ten specialist agents that research, plan, verify, and travel alongside you.
Most AI travel tools are one model with a search box. ZinsGo is being built as a reusable layer with seven parts that stay deliberately separate — because the moment durable knowledge and live availability get blended together, you can no longer tell which one was wrong.
Destination intelligence built from vetted sources — with the source, the retrieval date, and the licence retained alongside every claim.
Weather, transit, hours, closures, availability. Time-sensitive facts, always fetched — never remembered and re-served as truth.
How you actually travel: pace, budget bands, what you'll splurge on, what you refuse to overpay for, what you'd never do again.
Constraints and preferences resolved into a coherent route — with the reasoning for every destination, every extra night, exposed.
Plans meet weather, delays, closures and fatigue. The system replans in the moment rather than handing you a PDF and wishing you luck.
Claude, ChatGPT, Gemini, web, mobile, voice. One travel brain behind every surface — no rebuild per client.
Provenance, freshness class, corroboration count and confidence on every recommendation — so advice can be traced, not just trusted.
Each agent owns exactly one domain and hands off through a structured envelope. Specialists recommend; they do not silently overrule each other. A separate Verifier — with no stake in any recommendation — checks the plan before it reaches you.
Every recommendation carries its source, source type, retrieval date, freshness class, corroboration count and confidence. If we can't show where a claim came from, it doesn't ship as advice.
"The Prado is a major Madrid museum" is knowledge. "The Prado has tickets at 11:30 tomorrow" is live data. "You prefer smaller museums" is your profile. These are never silently mixed — mixing them is how confident AI travel advice quietly goes stale.
The planner asks for a capability — search_flights, search_lodging, route_between_places — never for a named supplier. A capability router picks the best provider available. When an API dies or a better one appears, nothing upstream changes.
Two countries done properly beats forty done shallowly. The architecture makes adding France, Italy or Japan a data expansion — not a rewrite. But we're not adding them until Spain and Portugal are genuinely good.
Autonomy is a setting, not a personality. Launch sits at L1–L2: it recommends and it prepares. It does not spend your money.
In October we take it on the road — one real trip, planned and run by the system, with the people who built it living inside the result. A demo can be staged. A trip cannot: the train is late or it isn't, the restaurant needed booking or it didn't.
The travel intelligence is the product; the interface is just an adapter. Which means it can reach you as an app, as a voice on a call, or as a tool inside the AI assistant you already talk to every day.
The full planning surface — routes, maps, evidence, and the reasoning behind every night allocated.
After the field testInterruptible, multilingual, short answers by default. Built as an interface adapter, so the travel brain never depends on one speech provider.
PrototypeConnect ZinsGo directly to Claude, ChatGPT or Gemini and give your own assistant a normalised travel brain — instead of every client wiring every provider itself. This is the piece we think matters most.
Subscription — plannedPublished up front, so you can hold us to it.
No autonomous purchasing. Nothing gets bought without your explicit confirmation.
It is not becoming an online travel agency, and it does not issue tickets.
No payment card data stored. Ever.
No scraping sites in violation of their terms — sources have a rights gate.
Source attribution is never replaced with a confident model summary.
No native mobile app before the backend is genuinely stable.
Building in public means publishing the honest position, not the flattering one. Right now that position is: the architecture is finished and the code is not started. Here's the whole sequence, and we'll move these markers as we go.
Data contracts, the MECE domain split, the agent catalog, the provider registry, the planning engine, the evaluation plan. Written before a line of code, deliberately.
Travel core scaffolding, trip state, traveler memory, the capability registry, and the provider adapter framework. Contracts before agents; deterministic before agentic.
The knowledge store, the ingestion pipeline behind a source rights gate, and the retrieval layer. Spain and Portugal only — depth before breadth.
Destination Researcher, the deterministic planning core, the Itinerary Planner, the Verifier, and the Travel Orchestrator that directs them.
End to end: a profile, a request, a defensible multi-city Spain and Portugal plan, conversational revision, preserved trip state, and golden tests that pass. This is the bar for the October trip.
Places and maps, weather, ground transport, lodging, flights, activities and food — each behind a capability the planner asks for by name, never a supplier it depends on.
Reservation risk, budget optimisation, the replanning engine, and the in-trip companion that adapts the day when the day stops cooperating.
The Travel Gateway, an external AI client adapter, the ZinsGo MCP server, the voice prototype, and the full web client. The travel brain stays in one place; only the adapters multiply.
Actually booking things is a different product with a different risk profile. It waits until everything above is genuinely trustworthy.
We're documenting this one in public — the architecture, the wrong turns, and what the Spain and Portugal trip actually exposes. Leave your email and we'll write when there's something real to show.