Case study · Personal project · In active development
TripSoc
An AI operations console for travel agencies
TripSoc reads the operational emails travel agencies receive — cancellations, schedule changes, supplier notices — finds the booking each one is about, and hands the agent's evidence to a human. It's built so the AI can't invent a booking, be steered by an email, or reach another agency's data.
- Type
- Personal project
- Timeline
- Aug 2026 — present
- Role
- Sole engineer: product, API, console
- Structure
- pnpm monorepo: Fastify API + Next.js console
- Test files across API and console
- 76
- Test files across API and console
- Merged pull requests
- 13
- Merged pull requests
- Database migrations
- 21
- Database migrations
- Prompt-injection checks per email
- 4
- Prompt-injection checks per email
Why it exists
Agency operations teams live in their inbox. Every airline cancellation or schedule change has to be read, matched to the right booking, and acted on — fast, and without mistakes that strand a traveler.
An LLM can speed that up, but only if three things are impossible: inventing a booking that doesn't exist, being instructed by the email it's reading, and touching another agency's data. TripSoc is designed around those constraints.
“Narrow models make typed judgments. LLMs extract or reason. Application code validates, authorizes, and executes.”
What it does
Self-service email intake
Each agency gets a forwarding address and sets up a Microsoft 365 or Gmail rule — no backend change. A built-in relay simulator signs and posts realistic emails to test the full path locally.
Triage-first console
A Next.js console with Clerk organizations, invitations, role-based dashboards, incident cases, and an investigation panel that shows the agent's evidence next to the email.
Booking platform connections
System administrators connect a booking platform once and map each agency to its external ID. Credentials are encrypted and never returned by any endpoint or shown to the model.
Hotel cancellation exposure
Investigations assess hotel cancellation fees per policy period, with supplier and customer fees kept separate. Missing, overlapping, or timezone-ambiguous policies go to review instead of a guess.
Guarded platform teardown
System administrators can permanently remove a platform and every resource scoped to it, behind an exact-name confirmation and server-side authorization.
How a request flows
- 01
Receive
An HMAC-signed webhook (five-minute freshness window) resolves the agency from the recipient address.
- 02
Deduplicate
Provider message IDs and content fingerprints prevent reprocessing within 24 hours.
- 03
Classify
A narrow model returns the event type and operational relevance as typed answers.
- 04
Guard
Four checks look for instruction overrides, identity or scope substitution, unauthorized actions, and system-directed commands.
- 05
Extract & verify
An LLM extracts facts with source quotes; deterministic and model-based checks verify each field.
- 06
Investigate
A separate queue runs the constrained agent, which resolves the booking through one scoped lookup tool.
Key engineering decisions
The server binds identifiers, not the model
The model can't choose the platform, URL, tenant, credentials, or which booking identifier to use. The server selects them, and the adapter independently re-checks identity and agency ownership of whatever comes back.
Fail safe, never best-effort
Every run has a deadline and a bounded number of tool calls. Timeouts, tool errors, or answers that don't match the tool result produce INSUFFICIENT_EVIDENCE with requiresHumanAction — never a confident guess.
Shadow mode before enforcement
The injection guard starts in shadow mode, recording verdicts while extraction continues. Enforcement is opt-in once a labeled corpus shows acceptable false positives. Low-confidence or malformed guard answers route to review.
Lease and fencing tokens for runs
An atomic lease plus a fencing token prevents duplicate investigations and stops a slow, stale run from overwriting a newer result. Refreshing archives the previous attempt.
Adapters for booking platforms
The queue, persistence, authorization, and agent are shared. Each platform adapter owns its authentication, endpoint mapping, normalization, and ownership checks, so adding a platform doesn't duplicate the workflow.
Read-only by design
TripSoc only ever reads bookings, and it enforces that rather than assuming it.
- Refuses connection accounts that can administer the identity provider, checked on save and at every login
- Platform credentials encrypted with AES-256-GCM, bound to the platform
- Cached logins keyed by connection version, so rotated credentials never reuse old tokens
- Decision audit logs keep metadata without raw email text
- Clerk organization scoping and UUID validation on every resource
- Hashed invitation tokens and redacted structured logging
Outcome
An end-to-end pipeline from forwarded email to an evidence-backed booking investigation, with every AI decision persisted, versioned, and reviewable.
An evaluation harness measures accuracy, false acceptances, and unnecessary escalations on labeled emails, so automation is only switched on when the numbers justify it.
Next · Live pilot with a booking platform, then itinerary, flight-status, and rebooking tools.