One agent.
Four routing decisions.
A single monitoring agent watches every inbound system a case notification might land in, classifies the document it finds, and moves the deal to the correct stage — Won, Lost, Deferred, or no-change. Invoices for won cases are generated and queued for approval in the same pass.
Notifications arrive everywhere.
In most services firms, the "you won the case" notification does not arrive in a neat webhook. It arrives as a PDF a paralegal scans into a shared Drive folder. Or as a Trello card someone creates from an email. Or as an email forwarded to a shared inbox. The operator's job used to be: watch all three, read every PDF, match it to the right deal, figure out whether it's a dependent notification, an exam scheduling notice, a favorable decision, or a denial — and then do different things for each.
That is a pure classification + extraction problem, and it's the ideal shape for a dedicated agent. The framework gives you one.
We configure one agent per firm, but it watches every inbound system you operate. Adding a new trigger (say, a Dropbox folder) is a config change, not a new build.
Where the notifications actually arrive.
Typical deployment uses both. The agent treats them identically once the document is in hand — same classifier, same extractor, same routing table.
Board-based (Trello, Asana, ClickUp)
Operators still want a "recent notifications" board they can eyeball. The agent subscribes to card-created webhooks on that board.
- New card created by operator (from email, scan, or fax)
- Agent reads card title, attached PDF, and comments
- Classifies notification type, extracts client match by name + email
- Attaches PDF to the matched deal in the CRM
- Runs the routing decision (see below)
Folder-based (Drive, Dropbox, S3)
Paralegals and mailroom staff drop PDFs into a shared folder. The agent watches for new files with a debounced folder-watcher.
- New PDF lands in the Active Decision Letters folder
- Agent reads the full PDF, classifies it, extracts award amount if applicable
- Matches to the deal by client name + case reference
- Writes structured notes to the deal with favorably-resolved items, rates, dates
- Runs the routing decision (see below)
W10 — Notification Monitor + Deal Routing.
Single agent, dual triggers, four-way routing. Idempotent by deal + document hash — the same PDF dropped twice routes once.
Notification Classifier + Router
Watches inbound systems, classifies the document, generates invoices for won cases, routes the deal.
- 01AI
Read trigger source, identify client by name + email match against the CRM.
- 02AI
Download and parse the PDF notification / case file. Extract: notification type, effective date, items (with status + rate), award amount if present.
- 03IF/THEN
What type of notification?
- 04AI
DEPENDENT: Draft "dependent added" email. Generate invoice = award × contract fee %. Push invoice_amount to CRM. Email owner for approval. Task operator to send the client email.
- 05AI
EXAM SCHEDULED: Read items from deal notes, select matching prep-video clips (condition-specific library). Draft email with date, time, links. Task operator to review and send.
- 06AI
FAVORABLE DECISION: Extract award letter, calculate rate-percent increase. Generate invoice = award × contract fee %. Update deal notes with granted items + rates + dates. Draft congratulations email. Push invoice for approval.
- 07AI
ADVERSE DECISION: Update deal notes with denied items + dates + denial summary. Create task for senior operator: "Review denied case for [client] — appeal recommendation needed."
- 08ROUTE
Routing decision: Dependent or Exam → no stage change. ALL items favorable → Won. ALL items adverse → Lost. ANY item deferred → Deferred (hold).
- 09SET
Write invoice_amount, close_date, claim_decision to the deal. Downstream native workflows fire on stage transition.
- 10EXIT
Deal is in the correct stage. Rotting timers armed. Operator sees it on tomorrow's board.
Four outcomes. Deterministic from the classification.
The classification is AI; the routing from classification to stage is plain code. This keeps the "why did the deal move?" question always answerable.
| Classification | Stage move | What else fires |
|---|---|---|
| Dependent added | No change | Dependent-added client email drafted. Invoice generated + queued for approval. Operator task to send the client email. |
| Exam scheduled | No change | Prep-video selection run against the item list. Client email drafted with date, time, and links. Operator task to send. |
| All items favorable | → Won | close_date set. Invoice generated from award letter. Congrats email drafted. Sent to finance for approval. 15d rotting timer armed. |
| All items adverse | → Lost | close_date set. Deal notes updated with denial summary. Task to senior operator for appeal recommendation. 10d rotting timer armed. |
| Any item deferred | → Deferred (hold) | Deal holds until all items decided. Same classifier re-runs when the next notification arrives. No timer. |
AI classification, code routing.
The reliability trick is the split. Classification is a language problem — what does this PDF say? Routing is a policy problem — given what it says, which stage goes with which label? We give the first to the agent and keep the second in plain code, version-controlled in the workflow repo.
The practical effect: when a firm changes its routing policy (say, deferred cases now need a separate specialist review before the hold), we change three lines of code and ship. No prompt engineering, no eval sets, no regressions on unrelated classifications.
AI where judgment is needed. Code where determinism is needed. Never the other way around.
Stop triaging PDFs by hand.
If a senior operator is reading every inbound letter to decide what stage the case goes to, this is the framework. Works with whatever systems you already use — Trello, Drive, email, it does not matter.