Origin
Not in Dishant's original list. Emerged from the realisation 2026-05-07 that nearly every module needs the same outbound pattern: read context, compose something, get approval, dispatch via the right channel.
Dishant's words:
"imagine our A1 tasks, it would need the support of cowork to make the posts and post them on my linkedin, how other tasks can automate themselves by sending whatsapp to specific numbers or groups including birthday and holidays wishes."
Without this pattern, every module that touches the outside world (A1 posts, A3 network touches, B3 compliance reminders, C5e deliverable dispatch, E7 email send, E8 WhatsApp send) would have to reinvent its own dispatch logic. That's wasteful and brittle. Build the pattern once, locked, and let every module invoke it.
What this is
A reusable Cowork-task pattern. The mechanism that turns "Dishant has approved something to go out" into "the right thing has been delivered to the right recipient via the right channel and logged."
This is platform-level infrastructure, not a feature of any one module.
The pattern (the same across all consumers)
- Read context. Read from Notion / Drive / Calendar / Gmail / a specific input → understand what is being dispatched, to whom, via which channel.
- Compose. Generate the actual content (post body, message text, email, attachment caption) using locked templates per consumer.
- Stage for approval. Present to Dishant in a single approval surface: "about to send these N things, confirm or edit each."
- Dispatch on approval. Drive the appropriate Cowork-controlled channel: LinkedIn web, WhatsApp web (1-to-1 or group), Gmail web, or composite (e.g., post to LinkedIn AND notify WhatsApp).
- Log the trail. Write the send record back to Notion: timestamp, recipient(s), channel, content hash / message ID. So we can prove what was sent, when, and where.
Consumers (modules that invoke this pattern)
<table header-row="true">
<tr>
<td>Consumer</td>
<td>What it dispatches</td>
<td>Channels</td>
</tr>
<tr>
<td>**A1. Social media**</td>
<td>Posts (drafted in chat or batch)</td>
<td>LinkedIn, WhatsApp Status, others</td>
</tr>
<tr>
<td>**A3. Network**</td>
<td>Birthday wishes, festival greetings, periodic touches</td>
<td>WhatsApp 1-to-1</td>
</tr>
<tr>
<td>**B3. Compliance reminders**</td>
<td>Pre-deadline client reminders (GST 11/13/20, TDS 7, etc.)</td>
<td>WhatsApp 1-to-1, Gmail</td>
</tr>
<tr>
<td>**C5e (dispatch)**</td>
<td>Approved client deliverables (monthly reports etc.)</td>
<td>Gmail with attachment, WhatsApp 1-to-1 / group</td>
</tr>
<tr>
<td>**E3. Morning briefing**</td>
<td>The daily briefing itself (delivers to Dishant)</td>
<td>Gmail to self, or in-chat</td>
</tr>
<tr>
<td>**E7. Email integrator**</td>
<td>Triaged drafts of replies</td>
<td>Gmail</td>
</tr>
<tr>
<td>**E8. WhatsApp integrator**</td>
<td>Triaged replies, outbound messages</td>
<td>WhatsApp web</td>
</tr>
</table>
Each consumer brings its own *content generation* logic and its own *recipient lookup.* The shared E9 pattern handles the staging, approval, dispatch, and logging.
## Dependencies (must exist before E9 can launch)
1. **C4 Clients DB with contact/preference data** — for client-targeted dispatches (B3, C5e). Without this, recipients are hardcoded, which doesn't scale.
2. **A3 Network/Contacts data with channel preferences** — for personal-network dispatches (A3). NGA Connect may be the source.
3. **A locked content template per consumer** — each module that uses E9 must have its content templates documented and locked, the way HSIPL's report template is locked.
4. **A single approval surface** — likely a Notion page "Outbound queue" that batches everything pending approval, OR a daily Cowork-driven email to Dishant listing pending sends with reply-to-approve. To be designed during E9 v1.
## Channel risk profile (informs build order)
- **Gmail (low risk):** Build first. Robust, well-understood, has Gmail thread IDs to log against.
- **LinkedIn posts (low-medium risk):** Build second. Public-facing, so a misfire is visible, but personal account web automation is well understood.
- **WhatsApp 1-to-1 (medium risk):** Third. Works but requires WhatsApp web open and authenticated. Can break silently if a contact's number changes or the chat is renamed.
- **WhatsApp groups (highest risk):** Last. Misfires are publicly visible to other group members. Names change, file confirmations sometimes manual. Build only after the channels above are stable.
## The deliberate-delay safety net
For any high-stakes dispatch (client deliverables, compliance reminders), insert a 12-24 hour queue between approval and send. Catches the "oh wait, I noticed something at midnight" moment. Cost: one day of latency. Benefit: a class of mistakes you'll never make.
For low-stakes dispatch (a LinkedIn post, a personal birthday wish), instant send is fine.
## Build sequence (not started)
1. **E9-v1: Gmail dispatch with single approval.** Take an approved item (one PDF or one email body), send via Gmail, log. Reference implementation: HSIPL May 2026 report dispatch.
2. **E9-v2: LinkedIn post dispatch.** Take a drafted post, post on LinkedIn, log. Reference implementation: A1 first scheduled post.
3. **E9-v3: WhatsApp 1-to-1 dispatch.** Take a drafted message, send via WhatsApp web, log. Reference implementation: A3 birthday wish or B3 compliance reminder.
4. **E9-v4: Outbound queue with deliberate delay.** A single Notion view or Cowork-driven email that batches pending sends, lets Dishant approve as a batch.
5. **E9-v5: WhatsApp groups + multi-channel composite sends.** Last, only after v1–v4 are stable.
## Notes
*To be added.*