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

rev 1582026-05-07

Top-retrieved memory dashboard panel + workspace-axis read on the rev-157 trajectory primitive (`GET /api/v1/memory/top-retrieved` endpoint + `retrievals7d` derived field on the rev-153 listing endpoint + brand-purple TopRetrievedMemoryPanel sidebar panel + getTopRetrievedMemoryEntries helper + OpenAPI 3.1 typed coverage on the new field + endpoint — 80th unbroken cadence rev)

Workspace-axis read on the rev-157 trajectory primitive — top-retrieved memory dashboard panel + GET /api/v1/memory/top-retrievedCloses the named rev-157 next-sprint candidate ('per-memory retrieval frequency on the v1 listing endpoint as a derived field') at the workspace-axis read shape it most needed. Rev 153 surfaced the *cumulative* retrieval state (lastRetrievedAt + retrievalCount); rev 157 surfaced the *per-memory shape over time* (the trajectory endpoint + sparkline); rev 158 surfaces the *workspace-level top-N* — 'what knowledge is the AI relying on most this week?'. New `getTopRetrievedMemoryEntries()` helper aggregates the rev-157 retrievalHistory JSONB, sorts desc by trailing-7-day retrieval count, returns top N rows (default 5) with per-row `trajectory7d` array so the panel renders the rev-157 sparkline inline without a follow-up call. New brand-purple `TopRetrievedMemoryPanel` sidebar panel mounts above the rev-153 StaleMemoryPanel — operators triaging 'is the AI focused on the right knowledge?' get a top-N answer at a glance instead of expanding the rev-157 sparkline on every memory row. Hidden when nothing has been retrieved in the trailing 7-day window. Mirrors the rev-51 `TopCostTasksPanel` shape (top-N by trailing-window activity) at the per-memory axis on the retrieval dimension. New bearer-auth `GET /api/v1/memory/top-retrieved?limit=5&days=7` endpoint exposes the same shape on the protocol-bound surface in lockstep — MCP hosts answering 'what is the AI relying on?' get a one-call answer.
`retrievals7d` derived field on the rev-153 GET /api/v1/memory listing endpointCloses the named rev-157 next-sprint candidate at the cheapest possible primitive — pure derived field, no schema cost. Every row on the rev-153 listing endpoint now carries `retrievals7d` (sum of trailing 7 days of the rev-157 retrievalHistory in workspace TZ) alongside the rev-153 cumulative `retrievalCount` total + `lastRetrievedAt` recency stamp. MCP hosts ranking memory by recent-activity vs all-time see both signals in one call instead of fetching the rev-157 trajectory endpoint per entry. Same workspace-TZ window the rev-157 trajectory endpoint uses so the two surfaces never drift on what 'this week' means.
Per-memory observability cluster on v1 reaches twelve axes deepThe rev-158 top-retrieved endpoint pairs with rev-157 retrieval-trajectory (per-memory axis on the trajectory dimension) and rev-153 stale (workspace axis on the staleness dimension) for the complete per-memory observability story across all three axis × dimension cells (per-memory × trajectory rev 157 / per-memory × staleness implicit via rev 153 + 156 / workspace × staleness rev 153 / workspace × trajectory rev 158). The MCP server's per-memory observability tooling now has nothing left to design across all twelve axes (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 + archive-warning rev 155 + per-tag-stale rev 156 + retrieval-trajectory rev 157 + top-retrieved rev 158). Pure protocol-translation work for the upcoming MCP server.
OpenAPI 3.1 typed coverage on the rev-158 endpoint + extended MemoryEntry schema — 80th unbroken cadence revThe OpenAPI 3.1 spec types the new `GET /memory/top-retrieved` endpoint with full request/response schemas (limit query param 1-20 default 5 + days query param 1-30 default 7 + response shape with `memory[]` array of typed rows including memoryId + kind enum + title + importance + pinned + tags + retrievalCount + retrievals7d + trajectory7d array + lastRetrievedAt nullable date-time). The shared `MemoryEntry` schema component picks up the new `retrievals7d` field so MCP-host code generators reading the spec see the derived field on every memory listing surface. 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 80th unbroken rev with rev 158. The OpenAPI spec changelog header gains a rev-158 block explaining the workspace-axis closure on the per-memory observability cluster and the cluster's twelve-axis depth on the protocol-bound surface.