Loop Desk is an always-on business workspace that takes incoming signal (email, forms, feeds, notes) and turns it into briefs, watch items, and next actions.

Does Loop Desk send emails on my behalf?

Loop Desk can draft responses, but nothing sends until you approve and explicitly trigger it. The approval boundary is fundamental.

What signal sources does Loop Desk support?

Email, RSS/Atom feeds, form submissions, manual notes, and webhooks. The desk treats all sources equally in its processing loop.

rev 81 — Loop Desk changelog

rev 812026-05-02

v1 members + invites + outbound subscriptions, per-recipient digest quiet-hours, OpenAPI invites/members coverage

v1 members + invites surface — closes the longest-outstanding v1-vs-dashboard parity gap (66 revs old)The rev-15 invite flow has been dashboard-only for 66 revs. Until rev 81 an MCP host driving the desk programmatically could read every workspace surface but couldn't list the team or invite a teammate — the longest-outstanding v1 parity gap on the open list. Rev 81 closes it: `GET /api/v1/workspace/members` returns members + pending invites; `POST /api/v1/workspace/invites` invites by email (existing users join immediately, unregistered emails queue and auto-attach on signup); `DELETE /api/v1/workspace/members/{userId}` removes; `DELETE /api/v1/workspace/invites/{inviteId}` revokes. Each mutation accepts optional `asUserId` to attribute the action; defaults to workspace owner. The helper validates that asUserId is an owner/admin so v1 bearer-auth callers can't escalate via asUserId. **Strategic significance**: the upcoming MCP server's team-management tooling now has nothing left to design on the rev-15 surface — protocol-translation work only. The pattern across rev 37 onwards (ship the dashboard primitive + the v1 mirror in lockstep) finally catches up the oldest dashboard-only mutation surface on the codebase.
v1 outbound subscriptions surface — closes the rev-19 v1 parity gap on the subscription-management sideRev 19 turned outbound delivery into a real router (per-event subscriptions + delivery log + retry); rev 46 mirrored the *delivery log + retry* on v1; the *subscription management* surface (list, create, update, delete) was still dashboard-only. Until rev 81 an MCP host could see *what* fired but couldn't say 'wire `signal.created` to my CRM.' Rev 81 closes that: `GET /api/v1/outbound/subscriptions` lists subscriptions + the full ALL_OUTBOUND_EVENTS vocabulary; `POST` creates; `PATCH/DELETE /api/v1/outbound/subscriptions/{id}` updates and removes. The GET response carries the `availableEvents` array so MCP hosts can render an event picker without hardcoding the vocabulary. **Strategic significance**: pairs with rev-46 deliveries + retry as the full outbound observability + control surface on the protocol-bound side. The cost-axis MCP cluster has been complete for revs; the *integration* MCP cluster now closes too.
Per-recipient digest quiet-hours window — fourth axis of operator-respect on the daily digestRev 80 closed three axes of operator-respect: workspace on/off (rev 5), per-recipient personal-section opt-out (rev 79), per-recipient weekend mute (rev 80). The fourth — *hour-of-day* — was the missing edge. The digest cron fires once at 13:15 UTC; in NYC EST that's 8:15am, in Tokyo it's 22:15. Recipients in late-evening regions had no way to skip the cron without disabling the digest entirely. Rev 81 adds `digestQuietHoursStart` + `digestQuietHoursEnd` (both 0-23 in workspace timezone, both nullable) on `workspace_member.dashboardPrefs`. When BOTH ends are set AND the workspace's local hour at fire time falls inside the [start, end) window, the cron skips THIS recipient. Wrap-around windows supported (e.g. 22 → 7 means 22, 23, 0-6 inclusive). Activity log records exactly how many recipients were quiet-hour-muted so admins troubleshooting 'why didn't I get the digest?' have the answer in the audit trail. UI in the integrations panel directly under the rev-80 weekend-mute toggle so all four digest controls (workspace on/off, personal-sections opt-out, weekend mute, quiet-hours window) read as siblings. v1 mirror via the existing `/api/v1/workspace/dashboard-prefs` GET/PUT pair; OpenAPI 3.1 spec types both new fields. **Strategic significance**: especially load-bearing for cross-timezone teams. Rev-80 weekend mute + rev-81 quiet-hours together give recipients fine-grained control over WHEN the digest reaches their inbox without the workspace owner having to coordinate cron schedules across regions.
OpenAPI 3.1 spec expanded to invites/members + outbound subscriptions (closes the named rev-80 next-sprint candidate)Rev 80's running state explicitly named 'OpenAPI spec coverage expansion to the rev-15/16 invites + members surface' as the rev-81 candidate. Rev 81 closes that — and adds the rev-19 outbound subscription endpoints in the same cycle since they're the natural complement to the rev-46 deliveries log + retry endpoints that already had v1 parity. The spec now types: `/workspace/members` GET, `/workspace/invites` POST, `/workspace/members/{userId}` DELETE, `/workspace/invites/{inviteId}` DELETE, `/outbound/subscriptions` GET/POST, `/outbound/subscriptions/{id}` PATCH/DELETE, plus the rev-81 `digestQuietHoursStart` + `digestQuietHoursEnd` fields on dashboard-prefs. **Strategic significance**: the OpenAPI spec now covers the *team management* + *integration management* surfaces in addition to the previously-typed cost-axis, discussion, reactions, focus, and core CRUD clusters. MCP hosts wrapping `/api/v1` for collaboration + integration tooling now have typed contracts for the load-bearing 'add a teammate, route an event to my CRM' workflows. Coverage continues to grow rev-by-rev; the full self-describing index at `/api/v1` remains authoritative for the complete endpoint list.