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 154 — Loop Desk changelog

rev 1542026-05-07

Memory auto-archive primitive closes the named rev-153 next-sprint candidate at the defensive-action axis — descriptive→defensive loop on the memory usage story now closes (rev 153 detect → rev 154 act) — 76th unbroken cadence rev

staleMemoryAutoArchiveDays column + sweepStaleMemoryAutoArchive helper — load-bearing primitive opens the auto-action surface on memoryCloses the named rev-153 next-sprint candidate ('memory auto-archive primitive'). New `workspace.staleMemoryAutoArchiveDays` integer column (nullable = off, opt-in by design, valid range 30-365 days). New `setStaleMemoryAutoArchiveDays()` helper + `sweepStaleMemoryAutoArchive()` per-workspace sweep helper that finds non-pinned, importance < 9 memory entries unused for the configured threshold and deletes them via DELETE row (memory entries are write-many-read-many, not lifecycle-bearing the way tasks are; the activity log carries the audit trail). Capped at 25 entries per sweep so a long-quiet desk that suddenly enables the feature can't archive 500 memory entries in one cron tick — operators see progress over multiple days, can pause, can re-pin entries they want kept. Mirrors the rev-49 stale-task auto-archive opt-in pattern at the per-memory axis exactly. Pinned (rev 5) and importance >= 9 entries are excluded server-side via getStaleMemoryEntries — they remain the operator's veto. Closes the descriptive→defensive loop on the memory usage story (rev 153 detect + read → rev 154 act).
Per-workspace sweep wired into runDailyDigest — runs alongside rev-49 task auto-archive on the same cron tickNew `runStaleMemoryAutoArchive()` cron sweep added to `runDailyDigest()` immediately after `runStaleTaskAutoArchive()` so the workspace's two working-set axes (in-flight work + durable knowledge) self-clean uniformly on the same cadence. For each onboarded workspace with staleMemoryAutoArchiveDays set, the sweep calls `sweepStaleMemoryAutoArchive()` then dispatches the new `memory.auto_archived` outbound webhook event + posts the new `buildMemoryAutoArchivedSlackPayload()` block to Slack with the same dead-Slack-webhook auto-clear path as `notifyBriefToSlack()`. Default null (off) preserves rev-153 diagnostic-only behaviour for every workspace until the operator explicitly opts in.
memory.auto_archived outbound event + Slack push — closure-receipt event mirrors task.auto_archived at the per-memory axisNew `OutboundEvent` value `memory.auto_archived` plus matching `dispatchMemoryAutoArchivedWebhook()` dispatcher in `src/lib/outbound.ts`. Mirrors the rev-49 `task.auto_archived` event at the per-memory axis. Lets external integrations (knowledge-base mirror, FinOps dashboard tracking AI-cost-of-knowledge, CRM tagging unused brand assets) reconcile 'the desk just self-cleaned its working set' without polling workspace state. Slack post via the new `buildMemoryAutoArchivedSlackPayload()` block with `:books: Stale knowledge cleared` header + listing each archived entry with 'Nd unused' / 'never used' + kind + title + recommendation copy ('Pin entries or raise importance >= 9 to keep'). Pairs with the rev-153 stale-memory dashboard chip + GET /api/v1/memory/stale read primitive so operators see both the diagnostic surface and the closure receipt across every channel — dashboard, Slack, outbound webhook.
PATCH /api/workspace/memory-archive-config + v1 mirror in lockstep + OpenAPI 3.1 typed coverage — 76th unbroken cadence revAdmin-only `PATCH /api/workspace/memory-archive-config` route + bearer-auth `GET/PUT /api/v1/workspace/memory-archive-config` v1 mirror in lockstep delegate to the same `setStaleMemoryAutoArchiveDays()` helper. Integrations panel UI section under the rev-49 'Queue hygiene' grouping renders the new threshold input (30-365 days, blank = off) with Enable / Update / Disable buttons matching the rev-49 stale-task auto-archive shape exactly so the two queue-hygiene primitives (stale-task auto-archive + stale-memory auto-archive) read as siblings on every operator-loaded surface. The OpenAPI 3.1 spec types both new endpoints with full request/response schemas (staleMemoryAutoArchiveDays integer 30-365 nullable). The cadence pattern from rev 78 onward (every dashboard primitive gets typed in the OpenAPI 3.1 spec in the same cycle it ships) reaches its 76th unbroken rev with rev 154. MCP-host code generators reading the spec see typed contracts for the rev-154 auto-archive primitive immediately. The MCP server's memory-axis cluster on the protocol-bound surface is now eight axes deep (read rev 12 + write rev 12 + bulk-update rev 35 + reactions rev 33 + tags rev 21 + export rev 125 + stale rev 153 + auto-archive rev 154) with full v1 parity to the dashboard surface across every axis.