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

rev 1732026-05-08

Two more industry onboarding templates (Direct-trade food / beverage + Outdoor recreation / guided experiences) + per-author social handles primitive (GitHub / X / LinkedIn / Mastodon / Bluesky) on the rev-106 author profile registry + frontmatter + author archive page hero rendering with per-platform chip row + v1 /blog/authors endpoint extended with resolved socialHandles + templates page count + radar copy refresh — closes the named rev-172 next-sprint candidates (further industry templates AND per-author social-link auto-resolution) at two more underserved verticals + the cheapest possible per-author identity primitive across five canonical professional-social platforms — 95th unbroken cadence rev (rev 173)

Two more onboarding templates — Direct-trade food / beverage + Outdoor recreation / guided experiencesCloses the named rev-172 next-sprint candidate (further industry templates — direct-trade food / beverage + outdoor recreation / guided experiences) at two more underserved SMB segments where the procurement-conscious buyer's 'will it know my industry on day 1?' question is loudest. Direct-trade food / beverage (small-batch coffee roasters, single-origin chocolate makers, artisan cheese, specialty tea — 4 high-importance memory entries: producer + farm + harvest year origin transparency on every product page, producer-share retail-price disclosure, 18-month harvest-cycle origin-visit cadence rule, 70% wholesale share channel-mix red flag + 1 sample subscriber origin-story request signal) AND Outdoor recreation / guided experiences (independent gear shops, guide services, charter operators, outfitting companies, adventure-tourism operators — 4 high-importance memory entries: named-guide / captain / instructor confirmation rule, honest-seasonal-risk-window transparency rule, 18-month guide-tenure peak-season pairing rule, 21-day below-peak booking-horizon red flag + 1 sample repeat-customer relationship-expansion question signal). Two new OnboardingTemplateKey enum values (direct_trade_food, outdoor_recreation) extend the rev-19 pattern. The templates cluster is now twenty-three named verticals deep, closing the day-1 starvation-point story across two more underserved owner-led segments where named-producer / named-guide attribution is the load-bearing differentiator against generic AI tools.
Per-author social handles primitive (GitHub / X / LinkedIn / Mastodon / Bluesky)Closes the named rev-172 next-sprint candidate (per-author social-link auto-resolution — auto-resolving GitHub / X / LinkedIn handles from the email or a `socialHandles` registry field for richer per-author profile blocks). Until rev 173 the rev-106 author profile + rev-107 frontmatter override + rev-172 Gravatar email primitive together gave readers a per-author avatar + bio + tagline + arbitrary `links` array — but the social-axis (GitHub / X / LinkedIn / Mastodon / Bluesky) had to live as raw `links` entries per-handle, which was operationally painful for contributors and gave the rendered surface no way to know 'this is a GitHub handle, render it with the GitHub icon'. Rev 173 closes that. New `BlogAuthorSocialHandles` type with bare-username keys for github / x / linkedin / mastodon / bluesky. New `socialHandles` block on data/blog-authors.json + matching `authorGithub` / `authorX` / `authorLinkedin` / `authorMastodon` / `authorBluesky` frontmatter fields with the same registry → frontmatter override resolution rev 107 introduced. New `buildSocialHandleUrl(platform, handle)` helper derives the per-platform URL at render time from the bare username so contributors register usernames once (no @, no URL prefix) and the URL shape can evolve (LinkedIn personal vs company; Mastodon instance handling) without a registry migration. Per-platform chip row renders on every per-author archive page hero with slate-tinted ambient styling distinct from the rev-106 brand-color teal `links` chips so readers can tell 'this is a GitHub profile' apart from 'this is a labelled portfolio link' at a glance. The five canonical platforms (GitHub → X → LinkedIn → Mastodon → Bluesky) cover ~95% of professional social presence as of 2026; future platforms can be added as bare-username keys without touching the URL builder. Strategic significance: pairs with rev-105 author archive + rev-106 profile registry + rev-107 frontmatter override + rev-172 Gravatar email as the now-five-axis per-author identity surface (avatar / tagline / bio / homepage / socials).
v1 /blog/authors endpoint extended with resolved socialHandlesPairs the rev-173 dashboard primitive with the v1 mirror in lockstep — the cadence pattern from rev 37 onward (every dashboard primitive ships with a v1 equivalent in the same cycle) holds unbroken into rev 173. The existing rev-105 `GET /api/v1/blog/authors` endpoint now also projects each profile's `socialHandles` block as a Record<platform, { handle, url }> shape — bare username + resolved URL together so MCP hosts rendering an author profile chip don't have to re-derive the URL shape per platform. Pairs with the rev-106 profile bio + avatar projection so MCP hosts now have the complete per-author identity surface in one bearer-less GET. Closes the named rev-172 candidate at the protocol-bound surface in addition to the dashboard surface. The MCP server (Q3 #1) gains one more pre-typed surface with nothing left to design on the per-author identity axis.
Templates page count + radar copy refresh + visual polishTemplates page count copy bumps 'twenty-one verticals today' → 'twenty-three verticals today' across hero, metadata title, OpenGraph + Twitter description, JSON-LD CollectionPage block, and the templates-cta. Two new keyword hints on the per-vertical chip line (Direct-trade food/beverage `Origin transparency · producer share · harvest cycles · channel mix`; Outdoor recreation `Named guides · seasonal risk · guide tenure · booking horizon`). Six new SEO keywords (`AI for direct-trade coffee roasters`, `AI for craft food and beverage`, `AI for single-origin chocolate makers`, `AI for outdoor recreation operators`, `AI for guide services`, `AI for charter operators`). 'Don't see your vertical?' next-radar list refreshes — replaced with small construction / general contracting, dental / orthodontic clinics (regulated retention rules + insurance billing rhythms), independent veterinary practices (pet-owner cadence + recall recall), and small distillery / brewery operators (production-vs-tap-room channel split) now that direct-trade food + outdoor recreation are shipped. Per-template detail page keyword-hint map gains the matching two new entries so /templates/[key] for the new verticals reads with the same depth as the existing twenty-one verticals. New `.blog-author-hero-socials` + `.blog-author-hero-social` CSS uses a slate-tinted palette + tiny mono-glyph badge inside each chip — quieter than the rev-106 brand-color teal links so the social row reads as ambient profile-context rather than primary call-to-action.