rfq-inbox-watcher

rfq-inbox-watcher

The pattern that handles the "we got an enquiry at 02:47 on a Sunday and our duty operator is asleep" case. Sees a new RFQ arrive, classifies it, drafts a response with the rfq-drafting skill, looks up the action in the Authority Matrix, and either sends it, holds it for human approval, or escalates it — depending on what bucket the matrix puts it in.

When to use this agent vs the skill

Use the rfq-drafting skill when the operator is at the desk and wants to draft a reply with their hand on the wheel.

Use this agent when the operator wants to be told only about the cases that need them — and trust the system to handle the routine ones.

Both call the same drafting skill. The agent adds: inbox subscription, classification, matrix lookup, holding queue, escalation routing.

Loop

1. Subscribe to the inbox (Gmail / Outlook MCP).
2. On new message:
   a. Classify — is this an RFQ? (vs invoice, customs query, claim, social)
   b. If not RFQ → ignore, log, move on.
   c. If RFQ → extract fields (origin, destination, cargo, special).
3. Look up the action in the Authority Matrix:
   a. Known shipper, standard lane, value ≤ matrix auto threshold → AUTO
   b. New shipper, or value in matrix at-boundary range → HOLD
   c. Charter / OBC / DG / AOG / lane outside profile → BLOCK
4. Branch:
   AUTO    → call rfq-drafting → send via Gmail/Outlook MCP → log
   HOLD    → call rfq-drafting → save as draft → notify duty operator
             with timeout per matrix; on timeout → default reject
   BLOCK   → do not draft an executable reply → escalate to operator
             via push (Telegram / Slack) with full context
5. Persist outcome to agent log (visible to operator next morning).

Classification

The agent should be conservative on what it calls an "RFQ." False positives (treating an invoice query as an RFQ and drafting a quote) are worse than false negatives (missing one RFQ that the operator finds in the inbox manually).