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

rev 1082026-05-02

Per-tag HTML archive page + 'More in this category' callout on post detail + archive summary stats + v1 tag endpoints

Per-tag HTML archive at /blog/tag/[slug]Closes the third axis on the public discovery surface alongside rev-105 per-author and rev-107 per-category archive pages. The rev-103 tag filter chips on /blog let readers narrow the index by tag inline, but had no dedicated drillable page. Tags collapse by slug (so 'MCP' and 'mcp' resolve to one page); the most-recent post's display name wins. Each per-tag page surfaces a hash-glyph hero with archive summary stats (posts + total words + estimated reading time + latest date) and a 'browse other tags' chip cluster at the bottom for cross-navigation. SSG'd via generateStaticParams. Sitemap updated in lockstep so crawlers see every per-tag archive page alongside the existing per-author + per-category pages — the public discovery surface is now uniformly drillable on every dimension.
v1 endpoints /api/v1/blog/tags + /api/v1/blog/by-tag/{slug}Mirrors the rev-105 per-author endpoints (/blog/authors + /blog/by-author/{slug}) at the tag axis. Closes the v1 blog cluster's seventh axis after listing (rev 102) + detail (rev 103) + categories (rev 104) + authors (rev 105) + related (rev 106) + neighbours (rev 107). MCP hosts rendering 'posts tagged MCP' or AI tooling roundup newsletters writing per-topic weekly digests now get the answer in one bearer-less GET instead of fetching the full /api/v1/blog and filtering client-side. The by-tag endpoint includes a `summary` block with totalWords + estimatedMinutes so callers don't have to re-aggregate per-post wordCount. No auth — same model as the rev-102/103/104/105/106/107 endpoints. Cache-control public, max-age=300, s-maxage=1800.
'More in this category' callout on /blog/[slug]Closes the named rev-107 next-sprint candidate at the post-detail axis. Until rev 108 the rev-107 per-category HTML archive closed the listing-level cross-category surface, but readers landing on a single post had no in-context cluster of category siblings — only the rev-106 related-posts grid (which ranks by tag-overlap content similarity, not category). Rev 108 adds the missing axis: every post page now surfaces a 2-card grid of up to 4 same-category siblings with date + read-time + title, plus a 'browse all N' chip linking to the rev-107 per-category archive. Distinct from rev-106 related (tag-similarity) — surfaces same-vocabulary work at the thematic-cluster axis. Pairs naturally with the rev-107 chronological prev/next nav (read newer/older in the timeline) for the full content-similarity (rev 106) + thematic-cluster (rev 108) + chronological (rev 107) trio of post-detail discovery affordances. Plus the post tags themselves are now clickable links to the rev-108 per-tag archive — until rev 108 they were inert spans.
Archive summary stats on per-category, per-author, per-tag pagesNew `summarizeArchive()` helper aggregates total post count + total words + estimated reading time across an archive's full post set. Surfaces inline in the hero of every archive page (per-category, per-author, per-tag) so readers see 'this is a 45-minute read across 8 posts' before scrolling the card grid. The estimated reading time is computed from the sum of word counts (not the sum of per-post readTime strings, which round per-post) so a small archive of short posts and a large archive of long posts show different totals. Mirrored on the v1 by-tag endpoint as a typed `summary` block. Cumulative micro-polish on the public discovery surface — every archive page now reads as a load-bearing surface rather than just a list.