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

rev 1612026-05-07

Per-memory cost spike alarm + daily Slack push + outbound memory.cost_spike event + ⚡ pill on TopCostMemoryPanel + GET /api/v1/memory/cost-spikes closes the cost-spike alarm cluster's seventh axis at the per-memory level — 83rd unbroken cadence rev

Per-memory cost spike detector (detectMemoryCostSpikes helper) closes the cost-spike alarm cluster's seventh axisCloses the cost-spike alarm cluster's seventh axis on the load-bearing primitive layer — workspace (rev 32), per-task (rev 55), per-source (rev 58), per-assignee (rev 62), per-tag (rev 67), now per-memory (rev 161). Pure read of the rev-160 memoryEntries.dailyCostHistory primitive — no schema cost. A memory entry is spiking when its today >= 2× trailing-7-day daily average AND today >= $0.50 absolute AND >= 3 historical days of non-zero spend (so a brand-new load-bearing memory entry's first day can't trigger). Pinned + importance>=9 entries excluded server-side because they're load-bearing-by-design — alarming on them is tautological. Closes the descriptive (rev 159 attribution) → trajectory (rev 160 sparkline) → alarm (rev 161) trio at the per-memory axis on the cost dimension at parity with the per-task axis (rev 51 + 54 + 55) and the per-source axis (rev 57 + 60 + 58).
Daily Slack push + outbound memory.cost_spike event closes the chat + integration channel parity gapNew buildMemoryCostSpikeSlackPayload() Slack block + dispatchMemoryCostSpikeWebhook() outbound dispatcher + new memory.cost_spike OutboundEvent value. New pingMemoryCostSpikes() sweep added to runDailyDigest() mirrors pingTagCostSpikes() shape exactly: rate-limited via the new memory_cost_spike activity-log kind to once per workspace per 24h with the same dead-Slack-webhook auto-clear path as rev-58 source spikes. Slack post: ':zap: Per-memory cost spike' header + listing each spike with ratio + today vs avg + retrieval count + kind + title snippet. Outbound payload includes the per-memory shape (memoryId + title + kind + importance + todayUsd + baselineUsd + spikeRatio + retrievalCount). Lets external integrations (FinOps tool tracking AI cost on a per-knowledge-asset dashboard, CRM tagging knowledge entries by ROI, board-status integration aggregating 'open cost issues this week') route the alarm by named knowledge entry — the strongest possible operator-facing answer to 'this specific knowledge asset is anomalously expensive today' because it names the entry, not just the workspace or the source.
Inline ⚡ alarm pill + spike banner + spiking-row accent on TopCostMemoryPanelEvery spiking row on the rev-159 TopCostMemoryPanel now gets a brand-red ⚡ pill alongside the rev-159 cost amount + rev-160 trajectory sparkline. Spiking rows wear a left-border accent + tinted amount color matching the rev-58 source spike + rev-67 tag spike treatments. Banner above the list summarises the spiking count inline so operators see the alarm without reading every row. Closes the visual-hierarchy gap on the rev-159 panel — operators now scan the panel and triage by alarm state (today's spike) alongside cumulative state (rev 159) and trajectory shape (rev 160) without leaving the dashboard sidebar. The rev-159 panel now reads at three orthogonal levels — same three-level pattern shipped on per-task in revs 51/54/55 + on per-source in revs 57/60/58 — uniformly applied at the per-memory axis on the cost dimension.
GET /api/v1/memory/cost-spikes v1 endpoint + OpenAPI 3.1 typed coverage + activity-log glyph + tint — 83rd unbroken cadence revCloses the cost-spike alarm cluster's seventh axis on the protocol-bound surface in lockstep with the dashboard primitive (cadence pattern from rev 37 onward holds unbroken into rev 161). New bearer-auth GET /api/v1/memory/cost-spikes?limit=10 endpoint mirrors the rev-58 /sources/cost-spikes shape at the per-memory axis. Each row carries memoryId, title, kind, importance, pinned, tags, todayUsd, baselineUsd, spikeRatio, retrievalCount. Pairs with /api/v1/memory/top-cost (rev 159) + /api/v1/memory/{id}/cost-trajectory (rev 160) as the three-axis cost-observability surface on the per-memory entity. The OpenAPI 3.1 spec types the new endpoint with full request/response schemas + the OpenAPI changelog header gains a rev-161 block. Activity log gains memory_cost_spike kind with ⚡ glyph matching the rev-32/55/58/62/67 cost-spike kinds so operators reading the audit trail scan all seven axes with one consistent visual vocabulary. The MCP server's per-memory cost tooling now has nothing left to design across attribution + trajectory + alarm.