The Agent That Makes Calls While You Sleep

At 3:07am on a Tuesday, a patient fills out a contact form on your website. She has a toothache and wants a callback to book an emergency appointment.

By 3:09am — 90 seconds later — your AI agent has called her back. She answers, books the first available slot at 8am, and goes back to sleep with a confirmation number.

You wake up at 7am to a notification: one appointment booked overnight, one patient contacted, confirmation sent.

You didn't set an alarm. You didn't have an after-hours answering service. You don't pay for a call center. This is what autonomous mode actually delivers — not a demo, not a proof of concept, but a business outcome that happened while you were asleep.

Here's how it works under the hood.

The Event → Call Chain

Autonomous mode starts with an event. Something happens in your system — a form is submitted, an appointment threshold is crossed, a record changes state — and that event triggers a call.

The chain looks like this:

Event source (your CRM, scheduling software, web form, webhook) → Event bus (WFW ingestion endpoint) → Policy engine (should we call? when? with what context?) → POST /v2/calls/initiate → Outbound call → Transcript and extractions → Review queue (if needed)

Each step is logged. Each step is auditable. Nothing in this chain happens without a policy that you or your administrator has configured and approved.

The Policy Engine

The policy engine is where the logic lives. You define rules that describe what should trigger a call, what parameters the call should have, and what should happen afterward.

A simple policy for appointment recall looks like this:

{
  "policy_id": "pol_recall_form_submit",
  "name": "After-Hours Form Submission Recall",
  "trigger": {
    "event_type": "form.submitted",
    "conditions": [
      { "field": "event.data.intent", "operator": "eq", "value": "appointment_request" },
      { "field": "event.data.source", "operator": "in", "values": ["website_contact", "landing_page"] }
    ]
  },
  "call_config": {
    "agent_id": "agt_xyz789",
    "to": "{{ event.data.phone_number }}",
    "context": {
      "patient_name": "{{ event.data.name }}",
      "reason_for_contact": "{{ event.data.message }}",
      "form_submitted_at": "{{ event.timestamp }}"
    },
    "max_attempts": 2,
    "retry_delay_minutes": 15
  },
  "compliance": {
    "tcpa_mode": "strict",
    "calling_hours": {
      "start": "08:00",
      "end": "21:00",
      "timezone": "{{ event.data.timezone | default: 'America/New_York' }}"
    },
    "hold_until_compliant": true
  }
}

Let's walk through what matters here.

trigger — the event type and conditions that must match. In this case: a form submission where the intent field is appointment_request. Your web form posts to the WFW events endpoint; WFW evaluates every incoming event against your active policies.

callconfig — the agent to use, the number to call (resolved from the event payload), and the context to inject into the call. The agent gets patientname, reasonforcontact, and the form timestamp as part of its context window before the call connects. When the patient answers, the agent already knows why it's calling.

compliance — this is the section you don't skip. tcpamode: strict means the policy engine checks calling hours before every attempt, even if that means delaying a call. holduntil_compliant: true means a form submitted at 11pm doesn't trigger a call until 8am the next morning in the recipient's timezone. The call doesn't get lost — it gets queued and fires when it's legally permissible.

What Happens in the Call

When the call connects, the agent isn't starting blind. The context injected by the policy appears in the agent's working memory for that call session. It knows:

• The patient's name (and uses it in the greeting)
• Why the patient reached out
• That this is a callback, not a cold call
• What the agent's goal is: book the appointment

From the patient's perspective, the agent sounds like someone who read the form. "Hi, this is Aria from Lakeside Family Dental — I'm calling because you left us a message about scheduling an appointment. Is now a good time?"

The agent then handles the booking using the same tools it uses for inbound calls: availability check, appointment creation, confirmation. Anything it can't resolve — an unusual insurance situation, an escalation request — goes to the review queue rather than leaving the patient without a next step.

What Doesn't Happen Automatically

Autonomous mode has clear limits by design.

High-value transactions go to review. The platform extracts fields from the call (was an appointment booked, did the patient decline, what did they say about insurance). If an extraction field has low confidence, or if the call outcome is ambiguous, it enters the review queue for a human to verify before any downstream action fires.

Opt-outs are permanent. Any caller who says "don't call me again" or "remove me from your list" during a call triggers an immediate opt-out record. That number is suppressed from all future autonomous calls — no exceptions, no override. This is not just best practice; it's required.

The policy must be active to fire. Policies have active/inactive states. If you're on vacation and don't want the recall policy running, you deactivate it. The event queue doesn't fire policies that aren't active.

The Review Queue

Every autonomous call generates a record. Most records require no action — the call completed, the appointment was booked or declined, the outcome is clear. These close automatically.

Some records go into the review queue for human attention:

• Low-confidence extractions — the agent wasn't sure whether the patient said they confirmed or cancelled
• Escalation requests — the patient asked to speak to someone
• Failed attempts — two tries, no answer; does the practice want to try a third time manually?
• Unusual outcomes — anything the agent flagged as outside normal parameters

The review queue is not a failure mode. It's the human layer in an automated workflow. The goal isn't to remove humans from the loop; it's to route only the interactions that actually need human judgment to a human, and handle the rest automatically.

The Stats That Made Us Take This Seriously

When we started measuring contact rates on autonomous callback vs. manual next-day follow-up, the numbers were stark:

• 85% contact rate on callbacks placed within 2 hours of form submission
• 23% contact rate on next-day manual follow-up calls
• 3.6x higher booking rate on the 2-hour callbacks vs. the next-day ones

The reason isn't complicated. People fill out forms when they're thinking about the problem. Two hours later, they're still thinking about it. The next day, they may have called somewhere else, decided to wait, or just moved on. Timing is most of what makes a callback effective — and autonomous mode eliminates the timing problem entirely.

Initiating a Call via the API

If you want to trigger an outbound call programmatically rather than from an event policy, the endpoint is direct:

curl -X POST https://api.workforcewave.com/v2/calls/initiate \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: recall-sarah-jones-0612" \
  -d '{
    "agent_id": "agt_xyz789",
    "to": "+18435551234",
    "context": {
      "patient_name": "Sarah Jones",
      "reason": "appointment_recall",
      "appointment_date": "2026-06-20"
    },
    "compliance": {
      "tcpa_mode": "strict"
    }
  }'

# Returns 202 immediately:
# { "call_id": "call_abc456", "status": "queued", "estimated_start_seconds": 5 }

The 202 means the call is queued and compliant with calling hours. If you POST at 11pm, you get a 202 with estimatedstartseconds pointing to the next compliant window. The call doesn't fail — it waits.

What You're Actually Buying

Autonomous mode isn't a feature. It's a business process redesign. It moves the callback from "something a staff member does when they get to it" to "something that happens automatically, within two hours, at any hour, with full audit trail."

For any practice or service business that generates leads through web forms, appointment requests, or referrals, that shift is worth more than any specific technology detail.

The technology is just what makes it possible without adding headcount to make it happen.

---

Next in this series: What Actually Makes a Voice Bot Smart (It's Not the LLM) — why the model is a commodity and where the real intelligence comes from.