Workforce Wave AI: The Engine Behind Auto-Provisioning

Every time a partner's client enters a business URL into the WFW admin interface, the same sequence of events kicks off automatically. No human at WFW reviews the submission. No queue of manual configuration steps waits on the other end. Within 90 seconds, a fully configured voice agent is live.

This is Workforce Wave — the AI provisioning engine that turns a URL into a deployed agent. From a partner's perspective it looks like magic. From an engineering perspective it's a carefully sequenced async pipeline with explicit failure modes and observable progress at every step.

Here's what actually happens.

The 5-Step Pipeline

Step 1: Crawl

Workforce Wave fetches the business URL and follows internal links up to a configurable depth (default 3 hops, up to 40 pages). The crawler respects robots.txt, applies rate limiting, and handles common edge cases: JavaScript-heavy SPAs get a rendered crawl via headless browser, PDF-heavy sites get content extraction from accessible PDFs, and sites with minimal content trigger the fallback path early rather than wasting crawl time.

The crawl produces a normalized content corpus — cleaned text, structured metadata, extracted entities — that feeds every subsequent step.

Step 2: Classify

The extracted content is scored against a classification model that covers 12 industry verticals. The top match sets the compliance context for the entire provisioning run: a dental practice gets HIPAA guardrails, a real estate agency gets Fair Housing filters, a law firm gets Bar advertising constraints.

Vertical classification happens in parallel with full content extraction, shaving several seconds off the total pipeline time. By the time the extraction LLM finishes processing the full content corpus, the vertical is already known.

Step 3: Construct

The prompt construction pipeline runs. This is 4–6 sequential LLM calls, each building on the output of the previous:

1. Business identity and persona extraction
2. Services and offerings enumeration (terminology-enriched by the vertical classification)
3. Compliance block injection (non-negotiable, vertical-specific rules)
4. Escalation logic construction (vertical defaults + site-specific signals)
5. KB document generation (services, hours, FAQ, staff/team)
6. Final prompt assembly and coherence check

The output is a purpose-built system prompt for the specific business — typically 140–180 lines — and four seeded KB documents. This is not a template fill. It reads like a well-briefed human agent guide because that's essentially what it is.

Step 4: Deploy

Workforce Wave calls the ElevenLabs API to create the agent record, uploads the KB documents, and configures the voice selection based on the vertical archetype and any partner-level voice preferences. Phone number assignment happens here too — either linking an existing number from the partner's Twilio subaccount pool or provisioning a new one.

Step 5: Activate

The operation record flips to active. Webhooks fire. The agent is live and able to take calls.

The whole pipeline takes 75–120 seconds depending on site complexity and LLM call chain latency.

Why You Get an operationId, Not a Wait

When a partner's client submits a business URL, the API responds immediately — not with a provisioned agent, but with an operation ID:

POST /v2/agents
Content-Type: application/json

{
  "payload": {
    "name": "Sunrise Physical Therapy",
    "business_url": "https://sunrisept.com",
    "template_id": "medical_receptionist"
  }
}

# Response: 202 Accepted — immediate
{
  "operation_id": "op_7f3a91bc",
  "status": "pending",
  "estimated_seconds": 90
}

This is the async operation pattern, and it's the right design for several reasons.

A 90-second HTTP request is a broken HTTP request. Load balancers time out. Mobile connections drop. Browser tabs get closed. Building a UI that waits on a 90-second synchronous response is a bad experience that produces unreliable results. The async pattern separates "I submitted this" from "this is done," and both states are handled gracefully.

Batch provisioning needs parallelism. A partner onboarding 12 clients at once should not have to wait 90 seconds per client sequentially — that's 18 minutes of sequential waiting. With the async pattern, all 12 POST /v2/agents calls fire in parallel, each returns an operation_id immediately, and the partner checks results in one pass a few minutes later. Fleet onboarding is the core use case here.

The operation record is observable. Not just "pending or done" — the operation record carries structured progress data that feeds the dashboard.

How ww_operations Powers the Progress Bar

The ww_operations table is the backbone of the fleet dashboard's real-time progress indicators. Every Workforce Wave provisioning run writes to this table throughout its execution.

-- ww_operations record during active provisioning
{
  "operation_id": "op_7f3a91bc",
  "partner_slug": "meridian-staffing",
  "operation_type": "agent_provision",
  "status": "running",
  "progress": {
    "current_step": "construct",
    "steps_completed": ["crawl", "classify"],
    "steps_total": 5,
    "percent_complete": 40,
    "current_step_label": "Building system prompt"
  },
  "created_at": "2026-05-12T14:23:01Z",
  "updated_at": "2026-05-12T14:23:19Z",
  "estimated_completion": "2026-05-12T14:24:31Z"
}

The fleet dashboard polls GET /v2/operations/{operation_id} every 3 seconds while an operation is in pending or running status. Each poll response updates the progress bar and the step label visible to the partner.

When the operation completes — or fails with a structured error — the record updates and the UI reflects the final state. Partners who provision many agents simultaneously see a fleet view with individual progress bars, each updating in real time as their respective pipelines advance through the steps.

The progress bar isn't cosmetic. Partners with high-volume onboarding days use it to triage: if several operations stall at the same step, that's a signal worth investigating. The operation record's provisioning_notes field carries the detail needed to act.

What Happens When It Fails

Workforce Wave fails gracefully, not silently.

If the crawl returns insufficient content, the operation falls back to a vertical-only system prompt rather than erroring out. The agent goes live with a high-quality generalist prompt for the detected vertical, and the operation record flags the fallback:

{
  "status": "active",
  "provisioning_notes": {
    "scout_confidence": "low",
    "fallback_used": true,
    "fallback_reason": "insufficient_crawl_content",
    "recommendation": "Provide a richer business URL or manually seed the KB"
  }
}

If a hard failure occurs — ElevenLabs API unavailable, phone provisioning fails — the operation moves to failed with a specific error code and a recommended recovery action. Most hard failures are retryable; Workforce Wave supports idempotent re-provisioning using the same operation_id once the underlying issue is resolved.

Partners see all of this in the fleet dashboard. Failed operations surface with their error reasons and retry buttons. The partner doesn't need to contact WFW support to understand what happened — the operation record tells the story.

---

Next in this series: Brand Voice at Scale: Teaching AI to Sound Like Your Business — how brand voice profiles work, how Workforce Wave extracts a voice profile from sample content, and how feedback loops improve future generation.