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. It's 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. One (RBT cert) didn't match the record, so it's set aside as 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)
For example, across a few of Treetop's states:
| State | Who they hire | Insurance | What's different there |
|---|
| Texas | RBT | Tricare | Tricare clearance before they can work |
| Georgia | RBT | Tricare | Tricare-credentialed techs in Savannah, Columbus, Hinesville |
| North Carolina | RBT & 40-hour | Medicaid, Tricare | Extra state background check (DHSR) |
| Arizona | Behavior Technician | BCBS, UHC, Aetna | Clinic staff also need TB test + fingerprinting |
| Utah | RBT | Tricare | TB test and fingerprinting for everyone |
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
Next step
We'd love the team's read on this
If the direction feels right, let's talk through the open questions together
and get aligned on what to build first. The natural starting point is the piece that helps
most: the agent reaching out and following up on its own.
Full requirements document ›