Skip to content

Selected work · Backend · Integrations · 1 min read

The plumbing behind a voice agent

A signed, guarded hotel-booking migration that passed 313/313 route checks in staging, and a campaign pipeline that turned 25-minute loads into 2.

TL;DR

  • Moved a six-property hotel-booking agent to a new provider over 4 HMAC-signed Apache Camel routes: 313/313 route and 114/114 booking checks on staging, then the production cutover.
  • Automated a twice-daily campaign pipeline: 150K lead entries so far; batching cut ~10K-row loads from ~25 to ~2 minutes.
  • Honest limits included: the booking guard reduces duplicate risk but isn't exactly-once.
Role
Owner, as Forward Deployed Engineer
Team
Exotel
Timeline
Oct – Nov 2026
Links
Internal work; no public links

How it fits together

A · Booking routes (Apache Camel, HMAC-signed)

  1. Session setup
  2. Availability
  3. Booking + per-session guard
  4. Payment-link invoice

B · Campaign cycle (Jenkins, twice daily)

  1. Dump + reconcile
  2. PDF/Excel reports
  3. Archive + email
  4. Integrity check
  5. Delete reported batch
  6. Load queued batch
  7. Compare to source
Simplified view of both systems.

A. Hotel-booking provider migration

Six properties, English and Hindi callers. I owned provider discovery, route implementation, the bilingual conversation changes, layered testing and the production cutover.

  • 4 Apache Camel routes: session setup, availability, booking and payment-link invoices.
  • HMAC-SHA256 signing, pricing and promo rules, bounded retries and a per-session booking guard.

B. Campaign automation for an EV maker

A Marathi outbound sales bot. I owned the bot, the lead-table routes, reporting, daily campaign prep and production troubleshooting.

A twice-daily cycle with Python, Jenkins, AWS S3/SES and headless Chromium: dump and reconcile the lead table → generate PDF/Excel reports → archive and email → conditionally delete the reported batch → load the queued batch → compare against the raw client file.

Failed integrity checks block the destructive steps. There's a dry-run mode, UAT mocks and separate internal failure notices.

Build log: Booking migration

Hover a step to see where it happened in the diagram above.

  1. Oct 12–13step

    Initial integration build

  2. Oct 14pass· Session setup

    Live bot wired to provider staging

  3. Oct 23pass· Booking + per-session guard

    114/114 booking checks in staging

  4. → Nov 1fix

    Hardening and vendor feedback

  5. Nov 2, 14:31 ISTpass

    Production cutover; two check calls confirm bookings

Build log: Campaign loads

Hover a step to see where it happened in the diagram above.

  1. fail· Load queued batch

    Bursty writes hit rate limits

  2. fix· Load queued batch

    Moved to batching and pacing

  3. pass

    ~10,000 requests → ~150; ~25 → ~2 min for ~10K-row lists

Results

  • 313/313

    route comparisons

    Staging harness; plus 114/114 booking checks

  • ~7.5K → ~2K

    tokens per multi-room tool response

    One multi-room example

  • 2.0 → 0.6 s

    configured end-of-turn wait

    Configuration, not a latency benchmark

  • ~1 vs ~20 min

    14-scenario regression, local vs remote

    Local harness run time

  • 150K

    lead entries automated

    Cumulative entries across campaign cycles, not unique people

  • 7/7

    successful production builds

    First observation window

  • ~1 h

    manual work removed per cycle

    Estimate

What I'd do differently

  • The booking guard fails open after its own timeout, so it reduces duplicate risk but isn't exactly-once.
  • Cold provider calls can exceed the platform's tool deadline.
  • Next: an idempotency key at the provider, plus a warm-up path.

Stack

  • Java
  • Spring Boot
  • Apache Camel (YAML routes)
  • Python
  • Jenkins
  • AWS S3/SES
  • Headless Chromium
  • REST
  • HMAC