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

rev 442026-04-30

Per-task memory transparency, full share-page revision lineage, v1 artifact versions, task source-evidence in JSON export

Per-task memory transparency on every active-work card (close named rev-43 follow-up)Rev 43's running state explicitly named 'per-task source memory transparency' as the next-sprint candidate to close the load-bearing rev-41 transparency loop on the memory side of the task surface. Rev 41 made memory transparency visible on every artifact (post-cycle); rev 43 closed the signal-side loop on the task (pre-cycle / in-flight). Rev 44 closes the matching memory-side loop. New task.sourceMemoryIds JSONB column stamped each cycle by the pulse engine in workNextTask (latest retrieval wins). New 'N memory entries' chip mounts on every active-work card with at least one source memory entry; one tap expands a panel listing the memory entries the AI is pulling for this task (kind, importance, pinned state, content excerpt). Lazy-fetched via the new GET /api/tasks/{id}/source-memory route. Pairs with rev-43 TaskSources for the full per-task input picture: 'which signals AND which durable knowledge is shaping this task right now?' Operators debugging 'why is the AI heading this direction' get the complete answer before the artifact lands. Mirrored on v1 via GET /api/v1/tasks/{id}/source-memory in lockstep so MCP hosts inherit the same transparency vocabulary.
Full artifact version chain on /share/{token} (close named rev-43 follow-up)Rev 43's running state named 'share-link revisions panel' as the next-sprint candidate. Rev 39 shipped the per-output revision diff in-app; rev 42 shipped the share-page transparency. Rev 44 closes the lineage gap on the public share surface: every shared brief with a parentArtifactId now renders a 'Revision history' panel listing every prior version (id, title, status, date) walked through the rev-20 parentArtifactId chain. New getPublicArtifactVersionChain helper deliberately projects only the lineage fields — body content stays scoped to the artifact actually shared, since prior drafts may carry abandoned positioning the operator chose to remove. SOC 2 / ISO 42001 reviewers reading a shared brief can now see the full revision lineage at a glance. Brand-accent stripe pairs with the rev-42 source-evidence panel so both governance surfaces read with the same visual vocabulary.
GET /api/v1/artifacts/{id}/versions (close v1 parity gap on rev-20 primitive)The rev-20 artifact version-chain endpoint (`GET /api/artifacts/{id}/versions`) has been dashboard-only for 24 revs. Rev 44 mirrors it on the v1 surface so MCP hosts driving the desk read the full revision lineage of any output through the same protocol vocabulary. Bodies are projected (consistent with the dashboard endpoint, since v1 callers have viewer-equivalent access). Pairs with the rev-44 share-page version chain (external readers) + rev-39 inline diff view (operator readers) so revision lineage is reachable from every read surface. The v1 cadence pattern of 'ship the primitive, mirror the v1 endpoint within one rev' continues with the older rev-20 dashboard primitive that had been waiting for protocol parity.
Per-task source evidence in workspace JSON exportRev 43 shipped the artifact-side sourceEvidence appendix in the JSON export — `artifactId → { signals, memory }` — so procurement reviewers could cross-reference each output's inputs without writing a join. Rev 44 closes the task-side symmetry now that tasks carry both sourceSignalIds (rev 1) AND sourceMemoryIds (rev 44). New top-level taskSourceEvidence map: `taskId → { signals: [{ id, kind, priority, title }], memory: [{ id, kind, importance, title }] }` for every task with at least one source. Reviewers auditing in-flight work — not just shipped output — can read 'which inputs are shaping this task' with one lookup. Export bumps to exportVersion 3 (forward-compatible with the rev-40 importer which only reads typed array fields). Closes the procurement evidence symmetry: shipped artifacts AND in-flight tasks now both carry resolved evidence trails in the takeaway artefact.