| name | vendor-doc-intake |
| description | Daily vendor-onboarding intake for {{request_label}}. Validates the W-9, banking form, and signed contract for every new vendor request against a fixed checklist, records every vendor's status in {{vendor_register}}, drafts a follow-up for anything missing or invalid, and posts the batch to {{review_channel}}. Load this before checking a single vendor so every one is held to the same standard and the agent never approves a vendor or touches payment or banking setup. |
Process every new vendor request landing in `{{request_label}}` without missing
a missing or invalid document, and without ever moving toward approval or
payment. A cron fires every `{{cadence}}` against a fresh session; the session
has no memory of the last run, so it reads `{{vendor_register}}` first, pulls
new request email, checks the W-9, banking form, and signed contract against a
fixed checklist, records the result, and posts the batch to Slack. Recording
and flagging are the agent's job; approving a vendor and setting up payment or
banking are not — those stay with a person, on every vendor, complete
paperwork or not.
- The `{{cadence}}` cron fires the intake run.
- A human asks the agent to re-check a specific vendor's document status.
- A human asks why a vendor was flagged or what's still missing.
Step 0 — Orient from the register, not from memory
This is a fresh session — there is no prior turn to resume. {{vendor_register}}
is the memory.
Open {{vendor_register}} and read every existing row: vendor name, contact,
date received, status of each of the three documents, overall flag, and the
Gmail thread ID recorded in the last column. This is what this run's new
requests get checked against so nothing is processed twice.
Step 1 — Pull new vendor requests
Check {{request_label}} in Gmail for threads not yet reflected in
{{vendor_register}} (match on Gmail thread ID). For each one, identify the
vendor name, the contact email, and every attachment.
Step 2 — Validate against the fixed checklist
Every vendor gets the same three checks, no exceptions:
- W-9 — a completed IRS Form W-9: legal name, TIN or EIN filled in, and a
signature with a date. Missing any field, or unsigned → invalid.
- Banking form — bank name, account number, and routing number all
present, and the form signed. Check completeness only; do not extract or
transcribe the account or routing number anywhere. Missing a field or
unsigned → invalid.
- Signed contract — a signature present, dated, and the vendor's legal
name matching the name on the W-9 and the banking form. A name mismatch,
missing signature, or missing date → invalid.
If any of the three documents is absent entirely, record it as missing
rather than invalid — don't guess at content that isn't there.
Step 3 — Cross-check vendor identity
Compare the legal name across all three documents and the contact email's
domain against the vendor name. A mismatch (different entity name on the
contract than the W-9, or a contact email that doesn't plausibly belong to the
vendor) is its own flag, even if each document is individually complete —
note it as name-mismatch.
Step 4 — Record every vendor, flagged or clean
Append or update one row per vendor in {{vendor_register}}: vendor name,
contact email, date received, W-9 status, banking form status, contract
status, overall flag (clean / missing / invalid / name-mismatch, or a
combination), and the Gmail thread ID. Never leave a request unrecorded for
being incomplete — an incomplete vendor is still a row, flagged.
Step 5 — Draft a follow-up for anything missing or invalid
For every vendor with any flag, create a Gmail draft addressed to the vendor's
contact naming exactly what's missing or needs correction (e.g. "the W-9 is
unsigned," "the contract lists a different legal entity than the W-9"). Save
it as a draft only — never send it.
Step 6 — Post the batch for review
Post to {{review_channel}}: every vendor processed this run, grouped clean
vs. flagged, each with its register row and, for flags, the specific document
and issue. Note that a draft follow-up exists for each flagged vendor, waiting
to be reviewed and sent.
Step 7 — Stop — never approve, never touch payment or banking
Your last action is the Slack post. You never mark a vendor approved, and you
never schedule, configure, or write to any payment method, ACH setup, or
banking profile in any system — not even for a vendor whose three documents
are fully complete and consistent. That decision, and the setup that follows
it, is always a person's.
- **No approval, ever.** The agent has no connector or instruction that marks
a vendor approved — not even for a fully clean, matched set of documents.
That step is always a human's.
- **No payment or banking action, ever.** The agent never sets up, schedules,
or writes to a payment method, ACH enrollment, or banking profile in any
system, regardless of document completeness.
- **No sensitive data at rest in the register.** Bank account and routing
numbers are checked for presence and completeness on the source form but
never transcribed into `{{vendor_register}}` — only a status.
- **Record, don't discard.** A vendor with a missing or invalid document is
still recorded in `{{vendor_register}}` with its flag — never silently
dropped or skipped.
- **No force-validating.** Don't infer a signature, a TIN, or a name match
that isn't actually on the document. Flag it as missing or invalid instead
of assuming it's fine.
- **Drafts, never sends.** Every outbound email to a vendor is created as a
Gmail draft. A human reviews and sends it.
- **Scoped, brokered credentials.** Gmail and Google Sheets access are
injected into the sandbox at runtime and never shown to the model or
written to logs.
- **Idempotent per run.** Match new requests against `{{vendor_register}}`'s
Gmail thread IDs before processing so the same request is never recorded
twice across runs.
