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

rev 1532026-05-07

Memory retrieval tracking + stale-memory dashboard panel + GET /api/v1/memory/stale opens the diagnostic surface on the memory entity at the usage axis — 75th unbroken cadence rev

memoryEntries.lastRetrievedAt + retrievalCount columns + pulse engine plumbing — load-bearing primitive opens the usage axis on memoryUntil rev 153 the memory entity was *write-only* on the usage axis — operators added memory through 'Teach the desk' (rev 6), bulk import (rev 22), promote-from-output (rev 26), or auto-saved on artifact approval, but the workspace had no read surface answering 'which memory entries is the AI actually still using?'. Rev 153 closes that gap. Two new columns on `memory_entry`: `lastRetrievedAt` (timestamp, nullable) + `retrievalCount` (integer, default 0). The pulse engine's `workNextTask` already calls `retrieveRelevantMemory` once per cycle and stamps the result on `task.sourceMemoryIds` (rev 44); rev 153 also stamps every retrieved memory entry's `lastRetrievedAt` + bumps `retrievalCount` via a SQL `+1` clause that rides the same UPDATE — no extra round-trip on the retrieval path. Mirrors the rev-47 stale-task pattern at the memory axis: lastRetrievedAt is to memory what task.updatedAt is to tasks; retrievalCount is the sessionCount equivalent.
Stale-memory detector + dashboard StaleMemoryPanel — surfaces durable knowledge the AI cycle hasn't pulled in 30+ daysNew `getStaleMemoryEntries()` helper + `StaleMemoryPanel` client component rendered as a slate-purple-accented sidebar panel above the existing rev-47 StaleTasksPanel. Surfaces durable knowledge entries the AI cycle hasn't pulled in `thresholdDays` (default 30, range 7-365), either never (when the entry is older than the threshold) or last retrieved before the cutoff. Pinned (rev 5) and high-importance (≥9) entries excluded server-side because they're load-bearing regardless of usage. Each row shows a 'Nd ago' / 'never' pill with three-tone treatment (slate for never, brand-purple for warm, amber for cold) + the kind chip + the retrieval count + tag preview. Hidden when no memory has gone stale (the steady state for healthy workspaces). Mirrors the rev-47 stale-tasks panel at the memory axis with a distinct slate-purple accent so the two surfaces read as siblings without competing visually.
Per-row 'used Nd ago' usage chip on every memory entry — inline diagnostic affordanceEvery non-pinned, non-high-importance memory row in the dashboard memory panel now carries a 'used Nd ago' / 'used today' / 'never pulled' pill alongside the existing kind + importance + pinned chips. Three states distinguish never-pulled (muted-grey, italic) / recently-used (brand-color teal, ≤7 days, affirmative) / older (amber, attention). Operators reading the memory panel can spot dead knowledge inline without expanding the rev-153 stale-memory sidebar panel. `daysSinceRetrieved` is computed server-side in the dashboard render so the client chip renders purely from props (React 19 purity rule forbids Date.now() during render). Pure derived state from the rev-153 columns the pulse engine stamps on every retrieval.
GET /api/v1/memory/stale + extended GET /api/v1/memory projection + OpenAPI typed coverage — 75th unbroken cadence revNew bearer-auth `GET /api/v1/memory/stale?thresholdDays=30&limit=12&includeNeverRetrieved=true` mirrors the rev-153 dashboard primitive on the v1 surface in the same cycle the dashboard primitive ships. The cadence pattern from rev 37 onwards (every dashboard primitive has a v1 equivalent within one rev) holds unbroken into rev 153. The existing `GET /api/v1/memory` listing endpoint also gains `lastRetrievedAt` + `retrievalCount` projected on every row so MCP hosts rendering the memory list can render the same 'used Nd ago' affordance without a follow-up call. OpenAPI 3.1 spec types the new endpoint with full request/response schemas (thresholdDays integer 7-365, includeNeverRetrieved boolean, response shape with `staleMemoryEntries[]` carrying every per-row field including ISO date-time formats). The cadence pattern from rev 78 onward (every v1 enhancement gets typed in the OpenAPI 3.1 spec in the same cycle it ships) reaches its 75th unbroken rev with rev 153. MCP-host code generators reading the spec see typed contracts for the rev-153 stale-memory primitive immediately. Closes the diagnostic gap on the memory entity at the usage axis on every channel — dashboard panel + per-row chip + v1 listing projection + v1 stale endpoint + OpenAPI typed schema.