MAVE AI Customer Service
A WhatsApp chat that books the slot for you.
An AI agent on the studio’s WhatsApp that answers availability and price questions and books a slot by calling the real booking tools, with a human handover whenever it is unsure.
5 booking tools, with human handover built in
From a question to a booked slot01 / 01A recreation of one conversation: the chat on the left, the tool calls the agent makes on the right.
From a question to a booked slot
A customer asks about tomorrow on WhatsApp. The agent looks them up, checks availability and price, then creates the booking with a deposit link. Tool names come from the agent’s registry; the chat itself is an example.
Rebuilt from the agent’s code; the chat is an example
- Real booking tools, not free text
- Swap the AI model, keep the tools
- Flag-gated, with human handover
Next.js / TypeScript / Drizzle / Turso
Designed and built by Alexanders Schwartzmann · start to finish
- Messaging gateway architecture
- Typed tool runner & API ports
- Provider adapters & handover
- Execution guards & observability
I can build one around how your business works.
- Agent
- Tool-calling
- Adapter
- Provider-agnostic
- Safety
- Execution modes
- Handover
- Human-in-the-loop
I designed and built this project from start to finish.
Alexanders Schwartzmann
From the product idea and design to the code behind the features below.
- Messaging gateway architecture
- Typed tool runner & API ports
- Provider adapters & handover
- Execution guards & observability
How the main flow works
- 01
Provider verifies & normalizes input
- 02
Gateway checks execution mode
- 03
Validated tool runner & business ports
- 04
Formatted result or human handover
Proof of the work
What was built, how it works, and why it was built that way.
const mode = AGENT_MODE();
if (mode === "off") return { ok: false, tool: call.tool, error: "agent disabled" };Execution is gated before a tool runs
The preserved agent gateway checks AGENT_MODE before dispatching a tool. Off, passive, shadow, and live modes have different execution paths.
Validation and simulated mutations can be separated from live execution before activating the agent.
"Availability": "checkAvailability",
"Booking": "createBooking",
"Human Handover": "handoverToHuman",
"Reschedule": "rescheduleBooking",Business tools map to real implementations
The registry resolves public tool names to existing internal tools. The runner validates inputs and outputs around the API-backed execution.
Provider vocabulary is kept in the adapter and registry, leaving the domain tools independent of the messaging provider.
The proof is the agent’s own code and rules, not a customer chat. No real customer was messaged and no live tool was run.
Rebuilt from the agent’s code; the chat is an example ·
Implementation reviewed · October 2026
This case study presents the preserved MAVE agent module: a messaging gateway, provider adapters, and typed business tools. The evidence documents the implementation and its execution contracts; current production activation is not established by this review.
Problem
A booking assistant needs to connect a customer request to availability, booking, or rescheduling. Generating a reply alone cannot perform those operations. The gateway separates message handling from the business APIs.
Implementation
- Provider adapters verify and normalize incoming requests before invoking the gateway.
- The registry resolves public tool names such as Availability and Reschedule to internal implementations.
- The tool runner validates inputs and outputs and applies bounded retries, timeouts, and audit reporting around execution.
- API ports connect tools to booking operations; human handover has a separate tool.
Execution design
The gateway checks AGENT_MODE before dispatch. Off disables execution; passive simulates tools; shadow separates reads from simulated mutations; live uses the production ports. These paths let validation and review happen separately from customer-facing execution.
Provider verification and parsing
→ Gateway execution mode
→ Registry and validated tool runner
→ Booking API ports or human handover
→ Formatted resultEvidence
The implementation evidence above contains selected excerpts from the actual gateway and registry. It demonstrates execution guards and business-tool mappings without using customer conversations or claiming a currently active production agent.
Implementasi ditinjau · Oktober 2026
Studi kasus ini menampilkan modul agent MAVE yang tersimpan: gateway messaging, adapter provider, dan tool bisnis bertipe. Buktinya menjelaskan implementasi dan kontrak eksekusi; review ini tidak menetapkan status aktivasi produksi saat ini.
Masalah
Asisten booking perlu menghubungkan permintaan pelanggan ke ketersediaan, booking, atau reschedule. Membuat balasan saja belum menjalankan operasional tersebut. Gateway memisahkan penanganan pesan dari API bisnis.
Implementasi
- Adapter provider memeriksa dan menormalkan permintaan sebelum memanggil gateway.
- Registry menghubungkan nama tool publik seperti Availability dan Reschedule ke implementasi internal.
- Tool runner memvalidasi input dan output, dengan retry terbatas, timeout, dan pelaporan audit di sekitar eksekusi.
- Port API menghubungkan tool ke operasional booking; handover manusia memiliki tool tersendiri.
Desain eksekusi
Gateway memeriksa AGENT_MODE sebelum dispatch. Off menonaktifkan eksekusi; passive mensimulasikan tool; shadow memisahkan pembacaan dari simulasi perubahan; live memakai port produksi. Jalur ini memisahkan validasi dan review dari eksekusi yang menyentuh pelanggan.
Verifikasi dan parsing provider
→ Mode eksekusi gateway
→ Registry dan tool runner tervalidasi
→ Port API booking atau handover manusia
→ Hasil terformatBukti
Bagian bukti implementasi di atas memakai cuplikan terpilih dari gateway dan registry asli. Cuplikan tersebut menunjukkan guard eksekusi dan pemetaan tool bisnis tanpa memakai percakapan pelanggan atau mengklaim agent sedang aktif di produksi.