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

rev 1562026-05-07

Per-tag memory archive scoping closes the named rev-155 next-sprint candidate at the per-workstream axis on every channel — `?tag=` query param on `/api/v1/memory/stale` + per-tag breakdown line in the rev-155 digest section + tag filter chip row on dashboard StaleMemoryPanel + inline retrieval-count chip on every memory row — 78th unbroken cadence rev

`?tag=` query param on `GET /api/v1/memory/stale` — closes the named rev-155 next-sprint candidate at the protocol-bound axisCloses the named rev-155 next-sprint candidate ('per-tag memory archive scoping'). Rev 153 opened the diagnostic surface on the memory entity at the workspace axis (GET /memory/stale + StaleMemoryPanel), rev 154 closed the descriptive→defensive loop (auto-archive sweep), rev 155 closed the per-entry warning push surface — but the rev-21 memory-tag corpus was the missing fourth axis. Operators tagging memory by workstream (#q3-launch, #brand-voice, #pricing) had no way to ask 'which knowledge in *this* workstream is about to fall stale?'. New optional `?tag=` query param on `GET /api/v1/memory/stale` filters via JSONB `@>` array containment so a tag like `q3` doesn't over-match `q3-launch` (mirrors the rev-39 cross-entity tag drill-down semantics + the rev-29 focus-tag boost predicate). `getStaleMemoryEntries()` accepts an optional tag normalised lowercase + length-bounded server-side. Pure additive — undefined returns the workspace-wide list (existing rev-153 behaviour). MCP hosts on multi-workstream desks can now answer 'which #q3-launch knowledge is about to disappear?' programmatically. Mirrors the rev-49 per-recipient `?assignedToUserId=` filter on `/tasks/stale` at the per-tag axis.
Per-tag breakdown line in the rev-155 memory archive warning digest section — closes the named rev-155 candidate at the email channelExtended `MemoryArchiveWarningEntry` with optional `tags: string[]` field; the `buildMemoryArchiveWarningSection()` helper now renders an inline 'By tag: #q3-launch (3) #brand (2)' breakdown line above the per-entry rows so operators see *which workstream's* knowledge is about to disappear at-a-glance without scrolling every per-entry row. Top 4 tags by warning count, ties broken alphabetically for deterministic ordering. Brand-purple chip palette distinguishes the breakdown from the existing brand-amber per-entry rows. Hidden when fewer than two distinct tags appear — the breakdown reads tautologically as 'everything is #foo' otherwise. Both the production cron path (`runMemoryArchiveWarnings`) and the rev-36 admin preview path (`previewMemoryArchiveWarnings`) project tags so admins iterating on configuration see the same surface they'll receive in production. Pairs naturally with the rev-156 `?tag=` v1 filter — operators read the per-tag breakdown in the digest, then drill into the matching tag via the dashboard or v1 surface.
Tag filter chip row on dashboard StaleMemoryPanel — closes the named rev-155 candidate at the dashboard surfaceThe rev-153 dashboard `StaleMemoryPanel` listed every stale entry workspace-wide; until rev 156 operators with multi-workstream tagged memory had to read every row to find #q3-launch ones. New tag filter chip row above the list lets operators answer 'which #q3-launch knowledge has gone stale?' in one click. Pure client-side filter on top of the existing server-rendered `entries` payload (the rev-156 v1 `?tag=` filter is the load-bearing primitive on the protocol-bound side; this UI surfaces the same scoping on the dashboard side without an extra round-trip). Each chip shows the per-tag count for at-a-glance triage. Hidden when fewer than two distinct tags appear on stale entries. New `.ld-stale-memory-tag-row` + `.ld-stale-memory-tag-chip` CSS uses the brand-purple palette matching the rev-156 digest breakdown chips so the per-tag surface reads with one consistent visual vocabulary across dashboard + email channels.
Inline retrieval-count chip on the rev-153 memory usage pill — surfaces load-bearing memory entries at-a-glanceThe rev-153 `MemoryUsageChip` showed 'used Nd ago' or 'never pulled' but the per-entry retrieval count (the column rev 153 added) was only visible in the tooltip — operators reading the memory list couldn't distinguish *load-bearing* memory entries (used many times) from *drive-by* ones (used once) without hovering each row. Rev 156 closes that gap with a small inline `· N×` chip alongside the existing label, hidden when retrievalCount is 1 (the implicit majority — surfacing it would read as visual noise). Tabular-num typography keeps multi-digit values vertically aligned across rows. Cumulative micro-polish — every rev 22+ has carried at least one — and rev 156's polish is load-bearing because it makes the operator's mental model of 'which memory entries is the AI actually using' visible without expanding the rev-153 tooltip on every row. Pairs with the rev-153 stale-memory panel + rev-154 auto-archive + rev-155 warning + rev-156 per-tag scoping for the complete usage observability surface across every read horizon.