Layer 0 — Platform Services
Multi-tenancy, RBAC, audit log, approval workflow engine, credential vault, observability, billing.
Every other layer assumes this exists. Roles (agent / senior_agent / accountant / admin / auditor) are scoped per domain and per action. Every side-effect tool call is recorded immutably for CA/auditor review.
Layer 1 — Canonical Domain Model
One internal vocabulary. Enquiry, Passenger, Itinerary, Fare, PNR, Booking, VisaFile, Voucher, Invoice, JournalEntry, BSPReport, Reconciliation.
Vendor fields never leak upward. Adding a new GDS means writing a driver that maps its API to the canonical Fare / PNR / Booking — no agent change required. The model is versioned strictly.
Layer 2 — Driver / Adapter Layer
FareSearch, PNR, Hotel, Transport, VisaPortal, Accounting, Payment, BSP, Card, Bank, Messaging, Document, Statutory.
One driver per external system. Each publishes a capability manifest declaring exactly what it supports. The orchestrator selects drivers at runtime based on tenant configuration and capability availability — so if a tenant's accounting system can't auto-post, Voyagent gracefully falls back to a Tally-importable XML.
Layer 3 — Tool Runtime
Canonical tools with side_effect, reversible, and approval_required flags.
Irreversible side-effects — issue_ticket, post_journal_entry, submit_visa, disburse_payment — always require explicit human confirmation. Reversible actions (hold PNR, draft quote) run freely.
Layer 4 — Agents
Orchestrator, three domain agents (ticketing_visa, hotels_holidays, accounting), cross-cutting agents (document_verifier, reconciler, reporter).
The Anthropic Python SDK with prompt caching enabled from day one, wrapped in our own orchestrator and per-domain state machines: enquiry → quote → book → deliver → post-sale.
Layer 5 — Clients
Web (Next.js), Desktop (Tauri 2), Mobile (Expo / React Native).
Desktop is the power-user client — it hosts integrations that need local OS access (GDS terminals, Tally ODBC/XML, smart-card readers, local printers). Web is the thin SPA. Mobile handles reports, approvals, and a remote-control relay paired to a desktop session over WebSocket.
Read the full architecture doc
The detailed version — driver contracts, canonical-model design rationale, invariants — lives in the repo alongside the code.