Case Study Skeleton: Client Document Collection Agent for Onboarding
Status: SKELETON. Sections marked [PILOT DATA] are populated only with measured results from an actual engagement — never estimated.
Dry-run evidence (simulated). Our deterministic pilot simulator already exercises this exact agent stack end-to-end: over a 14-day simulated dry run it requested and reviewed 79 client documents, drafted 37 chase reminders across the request→nudge→firm ladder (every touch logged to docs_chase.jsonl, every draft passed a banned-phrase tone gate), paused 9 chases on client extension promises, auto-skipped 4 documents that had already been received, and escalated 29 documents to the human onboarding owner (14-day-plus aging, 30-day-plus aging, or exhausted touch cap). All figures are from a simulated dry-run against synthetic data. No real clients or documents were involved.
The client
Small accounting/legal/professional-services firm (fictional persona used for this skeleton), an onboarding owner whose week leaks away chasing clients for tax documents, signed engagement letters, and KYC files. Each new client gets a checklist; each checklist becomes a string of reminder emails drafted by hand, tracked in a spreadsheet, and dropped the moment things get busy. [CLIENT NAME PENDING CONTRACT]
The problem
- The onboarding owner chases every missing document by hand — hours each week spent remembering who owes what, composing nudges, and re-sending checklists instead of doing billable work
- Chasing is inconsistent: some clients get polite weekly nudges, others hear nothing for weeks, and onboarding stalls silently — the awkward "we still need your tax form" email is always the one that slips
- The failure modes are human-hostile: clients who promise "I'll send it Friday" get chased anyway, documents that already arrived get chased again, and after weeks of nagging the relationship — not just the checklist — is what suffers
What we deployed
A DocCollectionAgent running our standard loop on top of a deterministic chase policy whose guardrails live in code, not in the prompt:
- a deterministic request→nudge→firm ladder in code: each outstanding document moves from first request, to friendly nudge, to firm reminder on computed days-outstanding — tier chosen by the checklist state, never by LLM judgment
- received/waived documents are NEVER chased again: once a document arrives or is waived off the checklist it is permanently out of scope — the agent cannot nag you for something you already sent (4 already-received arrivals were auto-skipped in the simulated dry run)
- extension-promise pause: if the client promises documents by a given date, the ladder pauses until that date instead of hounding someone who already committed
- hard human escalation at day 14+: any document still outstanding past 14 days escalates to the human onboarding owner (and again past 30 days, or when the touch cap is exhausted) — the agent hands off at the right moment rather than escalating the tone
- a 4-touch cap per document in code: no client can ever be nagged more than four times for the same item, whatever the ladder computes
- a banned-phrase tone gate on every draft: accusatory, threatening, or deadline-ultimatum language can never reach a client — anything that would trip the gate is escalated to a human instead of sent
- an auditable
docs_chase.jsonllog: every drafted touch recorded with timestamp, document, checklist, tier, and message text
Results framework (fill during/after pilot)
| Metric | Before | After | Source |
|---|---|---|---|
| Onboarding-owner hours spent chasing documents per month | [PILOT DATA] | [PILOT DATA] | client timesheets |
| Average days-to-collect per requested document | [PILOT DATA] | [PILOT DATA] | checklist system reports |
| % of outstanding documents touched on schedule | [PILOT DATA] | [PILOT DATA] | docs_chase.jsonl audit log |
| Documents escalated to humans before relationships strained | — | [PILOT DATA] | escalation records |
| Cost per chase touch | [PILOT DATA] | [PILOT DATA] | token ledger |
Pricing fit
Document collection runs on our platform-fee-plus-usage model: $450/mo platform fee + $4.00 per collected document (a requested document received after an agent touch within the cycle). Because each touch is a small deterministic decision with a tiny token footprint, the internal simulated worked example clears our enforced 30%-margin floor easily — at roughly 86% contribution margin per collected document in the simulated dry-run estimate (see reports/pricing_model.md §7, and pricing). Documents a client declines to send never bill, so revenue only accrues on clean, successful collections — the pricing aligns our incentive with the client's onboarding velocity.
Why the deterministic chase policy matters
In document collection, one nagging message too many can cost the client relationship the onboarding was meant to start. The ladder tier, the received/waived exclusion, the extension pause, the day-14 handoff, and the touch cap all live in deterministic code the language model cannot override — the LLM only drafts within a tier the planner has already chosen, and every draft must clear a banned-phrase tone gate before it exists as a candidate. A client who promises Friday is left alone until Friday, a document already received is never mentioned again, and every touch is attributable to its checklist record, its aging rule, and a loop cycle.
Lessons learned section
[POST-PILOT: list top 3 lessons from data/loops/<project>/ — real ones, verbatim.]
SIMULATED DATA — every dry-run figure on this page is a simulated estimate against synthetic data; none comes from a real engagement yet.