Forge experiment · AI receptionist

What can I help you with?

Local businesses miss calls and web messages, and a generic chatbot cannot answer real questions about their services or book an appointment. I built an AI receptionist that drops onto any site with one line of code. It answers from the business's own facts, captures the lead, and books straight into their calendar. The whole thing runs on Cloudflare.

A real product, shown here as a build writeup. A live receptionist runs in the demo below.

Try the live receptionist ↓

Live demo

The receptionist below is the real product, embedded here with the same one line of code a business would paste on their own site. For this demo I pointed it at this site, so you can ask it about the work on these pages. It runs in a Shadow DOM sandbox, isolated from the page, and captures a lead the same way it would for a business.

If it shows an offline card, the demo is not connected yet.

One line of code loads the widget. A visitor question goes to the multi-tenant Worker, which answers from that business KV config with Workers AI, then captures a lead or books a time.

How it works

A one-line widget puts an AI receptionist on a site. A multi-tenant Worker answers from that business KV config with Workers AI, captures leads, and books into the calendar.

💬
Visitor
asks a question
message
Worker + AI
answers from KV config
grounded answer
📅
Lead / booking
captured or booked
Grounded answers
Books to calendar

Key decisions

Config is the knowledge base
Each business is one KV config with its facts, hours, and services. The model answers from that, with no separate database or RAG.
Grounded and guarded
The assistant answers only from the business facts and follows guardrails, so it does not invent policies or prices.
Books without a vendor
Booking writes straight into the business Google Calendar from the Worker, with a KV lock so two people cannot take the same slot.
One brain, many channels
The same logic runs a voice agent on a Durable Object per call and an SMS channel, all sharing the KV config.
Built with:WorkersWorkers AIKVDurable Objects

On the edge

The whole system is Cloudflare Workers sharing one KV namespace. This is the part a platform engineer cares about.

VISITOR CLOUDFLARE EDGE EXTERNAL Widget Shadow DOM, one line of code Worker (multi-tenant) serves widget · routes chat, leads, booking · rate limited Workers AI grounded chat (Llama 3.1 8B) KV: tenant config the knowledge base · encrypted tokens Voice (Durable Object / call) · SMS described, not part of the public demo Google Calendar booking Telephony provider voice · SMS chat · leads · book reads facts book
One line of code, one multi-tenant Worker. The business config in KV is the knowledge base; booking writes to the business calendar; voice and SMS run on the same platform and are described here rather than demoed.

One Worker, many businesses

A single multi-tenant Worker serves every business. It serves the widget through the Assets binding, applies per-IP rate limiting from KV, and routes chat, lead capture, and booking. Each business is one slug.

The config is the knowledge base

There is no separate database and no retrieval pipeline. Each business is one KV record holding its facts, hours, services, and persona. Workers AI answers from that record, so replies are grounded in what the business actually offers.

Grounded chat on Workers AI

Chat runs on Workers AI (Llama 3.1 8B). The model is handed only the business facts and a set of guardrails, so it stays on topic and does not invent policies or prices. Internal control markers are stripped before anything reaches the page.

Voice and SMS on the same brain

The same logic runs two more channels: a voice agent that holds a Durable Object per call and streams Workers AI tokens back over the line for natural, interruptible speech, and an SMS channel for texts and missed-call follow-up. Both share the KV config. Described here, not part of the public demo.

Booking, without a scheduling vendor

When a business connects Google Calendar once, the Worker reads free and busy times and writes the appointment itself. There is no Calendly or third-party scheduler in the path, so there is no per-booking fee. A KV lock guards each slot so two people cannot take the same time, and the Worker re-checks availability before it writes.

Adaptive by business

Booking has three modes. A connected Google Calendar gets real self-serve slots. A business that already uses another tool hands off to their own booking link. Everyone else captures a preferred time as a lead. The widget shows the right one automatically.

Privacy and security

Little data on the server

The widget runs in a Shadow DOM sandbox on the visitor page. The server keeps conversation state briefly and the leads a business asks to capture. There is no visitor account and no tracking profile.

Encrypted, and no audio kept

KV is encrypted at rest, and a connected calendar token is encrypted again at the app layer with a separate key. The voice agent works from live transcript text, so no call audio is recorded or stored.

Guarded by construction

The assistant answers only from the business facts, internal control markers never reach the page, and inbound webhooks are verified by signature. Payments are handled by Stripe, so no card data touches the Worker.

To be precise: this is privacy by design, not a certification. It integrates two outside services, a business Google Calendar for booking and a telephony provider for the voice and SMS channels.

Where it fits

The honest summary

A real, multi-tenant AI receptionist running on Cloudflare Workers, Workers AI, and KV, with a Durable-Object voice agent and an SMS channel on the same platform. One line of code to embed, the config is the knowledge base, and booking writes straight into a calendar. Shown here as a build writeup; the prompt and guardrail internals stay under the hood.

Built on Cloudflare while prepping for a Solutions Engineer conversation. The demo above is a real embed against a sample business, last updated 2026-07-16.