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

rev 862026-05-01

OpenAPI bulk-action coverage, v1 digest preview, activity log glyph expansion

OpenAPI typed schema for the 8 remaining bulk action endpoints — closes the named rev-85 next-sprint candidateRev 85's running state explicitly named 'OpenAPI spec coverage on the few remaining v1 endpoints (the bulk action endpoints)' as the rev-86 candidate. Rev 86 closes the typed-schema bulk-action symmetry on the v1 surface: `/tasks/bulk` (rev-26/35), `/signals/bulk` (rev-33/35), `/memory/bulk-update` (rev-34/35), `/artifacts/bulk` (rev-6/35), `/tasks/cost-spike-ack/bulk` (rev-57), `/sources/cost-spike-ack/bulk` (rev-60), `/cost/by-assignee/cost-spike-ack/bulk` (rev-63), `/cost/by-tag/cost-spike-ack/bulk` (rev-68). All eight previously had self-describing index entries but no typed JSON schema in the OpenAPI 3.1 spec — MCP hosts had to read string descriptions and infer the request shape. Rev 86 makes them all typecheckable. **Strategic significance**: closes the typed-schema bulk-action symmetry across the protocol-bound surface. The cost-axis MCP cluster's daily-ack bulk surface (per-task / per-source / per-assignee / per-tag) is now four axes typed; the four core entity bulk surfaces (tasks / signals / memory / artifacts) are all four typed. The MCP server's bulk-action tooling has nothing left to design on the typed-contract surface.
POST /api/v1/workspace/digest-preview — closes the dashboard-only digest-test gap from rev 36New bearer-auth v1 endpoint mirrors the rev-36 dashboard `/api/digest/preview` endpoint. Body `{ userId? }` defaults to workspace owner if omitted (matches rev-77 v1 personal-inbox + rev-30 v1 reaction conventions). Recipient must be an owner/admin of the workspace; viewers can't preview because the digest exposes per-recipient personalisation that low-trust roles shouldn't be able to push to senior recipients' inboxes. Bypasses the per-workspace 22h cron interval gate (matching the dashboard preview path) so MCP hosts iterating on configuration can fire repeatedly without waiting for the next 13:15 UTC tick. The recipient's rev-78/79/80/81 dashboardPrefs (digest opt-out / weekend mute / quiet hours window) are honoured exactly as the production cron would. **Strategic significance**: the digest is the only operator-loaded channel that had no v1 surface to verify since rev 36. Rev 86 closes the gap — the digest email's full rendering path (workspace summary + assigned tasks + mentions + stale + personal cost + personal chronic + personal inbox sections, gated by each recipient's dashboardPrefs) is now exerciseable from the protocol-bound side, so the upcoming MCP server can ship 'test the digest config' tooling without dashboard-only bridge code. Also typed in the OpenAPI 3.1 spec in the same cycle the endpoint ships.
Activity log glyph + per-kind tinting expansion — six accumulated kinds finally get visual affordanceThe rev-35 activity log glyph map has been growing rev-by-rev (cost spike kinds rev-32/55/58/62/67, chronic kinds rev-61/64/70, source auto-pause rev-62) but six accumulated kinds were falling through to the '•' default since they shipped: `stale_tasks` (rev-48 + rev-50 sweep), `share` (rev-10 share-page render), `webhook` (rev-19 outbound delivery), `email` (rev-7 email forwarding + rev-25 digest send), `comment` (rev-26 task discussion), `operator_note` (rev-14 AI direction primitive). Rev 86 adds glyphs (⌛ / ⤴ / ⇝ / ✉ / 💬 / ✎) and per-kind tints (amber / brand-purple / brand-color / teal / brand-purple / amber) so operators reading the activity log now see every kind the codebase actually emits with a per-kind colour signal. **Strategic significance**: closes the rev-35 per-kind scannability symmetry on the activity log. Operators reading a busy log no longer have to read the leading word of every detail line to identify the kind — the glyph + tint is the load-bearing fast-scan affordance, especially valuable on the rev-78 time-bucketed log + rev-21 chip filter + rev-38 keyword search composed view that rev-79 introduced as the four-dimensional read shape.
Visual polish — pulse animation on dashboard reset success stateCumulative micro-polish (every rev 22+ has carried at least one). The rev-85 dashboard reset chip's 1.2s brand-green flash now also rings out via a `box-shadow` pulse animation that fades from `rgba(15,118,110,0.42)` to transparent over 1.2s with a subtle 1.02× scale step at 0%. Pairs with the existing color/border-color flash so the chip reads through three distinct visual states on a single tap (neutral / hover-lifted / success-pulsed). Distinct visual confirmation that doesn't require a toast — the pulse is large enough to draw the eye on first reset but small enough not to compete with the rev-12 heartbeat indicator or rev-76 what's-new badge in the same status bar. **Strategic significance**: keeps the rev-by-rev visual-hierarchy discipline alive — every chip + pill + button on the status bar now wears its own state vocabulary (heartbeat = ambient state, what's-new = temporal delta, personal inbox = actionable counter, density = layout, reset = reset-just-fired). Each reads at a different cadence so they never compete.