Offer & Onboarding · Prototype review
The Onboarding Agent
After a candidate is offered, an agent collects every required document,
chases the candidate automatically, validates what comes in — and only escalates the
exceptions. Recruiters watch progress instead of working a checklist.
Maigrate · Treetop · screens captured from the running prototype
Why
The problem we're removing
- Document chase-down is the slowest, most manual step to making a hire billable — recruiters texting candidates and tracking certs by hand.
- Requirements genuinely differ by state, role, and payer (Tricare, Medicaid, BCBS…) — a static checklist doesn't fit.
- Competitors lean on candidate upload portals. Our wedge: a conversational agent that chases and first-pass-validates over SMS, human-on-exceptions only.
Recruiter home
The fleet view
➚ click to zoom
- Sorted exceptions-first · red = needs you, spinner = agent working, green = done
- Each line is the value prop: "Agent is following up with Maria — waiting on 3 documents"
Case · exception path
The agent flags what needs a human
➚ click to zoom
- Agent auto-validated 8 docs; 1 (RBT cert) didn't match the record → Needs you
- Readiness gates · view/download per doc · full agent activity log
Case · in-flight path
The agent is chasing — on its own
➚ click to zoom
- Following up via SMS on a schedule · queued vs awaiting vs validated, per item
- Activity log reads as a narrative: "Agent sent Maria a reminder for Supervisor Name"
Admin config
Per-tenant requirements — Settings › Hire requirements
➚ click to zoom
- Each credential: gate · required↔optional · expiry handling · per-state default role
- This is Treetop's default; a second customer gets its own config
The model
Requirements are resolved, not fixed
required_docs, gates = resolve(state × role × payer × location × setting)
Role types
Tricare RBT · RBT · ABAT · 40-Hour Certificate · BT
Readiness gates
Offer → Training clearance → Scheduling clearance
Per-tenant storage
Treetop → Lumary · Bright → Rippling · via adapter
Honest status
Real vs. seeded vs. not built
| Requirements resolver · config · admin screen · data model · recruiter UI | Built & tested |
| Agent lifecycle + activity shown on screen | Seeded fixtures |
| Sending SMS/email · scheduled follow-ups · doc validation (LLM/OCR) · inbound capture | Not built yet |
For discussion
Decisions to make
- Background-check gating — block the offer, or collect post-acceptance?
- Storage target — confirm Lumary / Rippling + adapter contract
- Follow-up cadence & hours — how aggressive? STOP / quiet hours
- Validation autonomy — auto-accept vs. always route to a human
- ABAT / QABA — own role or RBT variant?
- NM RBT timing — company 30-day vs. state 6-month
- Recurring checks — OIG monthly / CAQH 120-day ownership
- Documents tab? — inline view/download (now) vs. all-files view
To make it real
Build outline
- Trigger — create a case when an offer is accepted
- Request — agent sends the doc request per resolved requirement
- Follow-up loop — scheduled nudges on cadence (STOP/hours aware)
- Ingest — inbound attachment → stored document → queued
- Validate — LLM/OCR classify + extract → accept or flag
- Escalate + recompute — flags surface in Needs you; gates rerun
- Writeback — push accepted docs to Lumary / Rippling
Proposed next step
Lock the top decisions, then build one real slice
Decide background-check gating + storage target + cadence — then build
trigger → request → scheduled follow-up against the fake clients, so the
prototype actually moves on its own end-to-end before we wire live SMS and validation.