Paperclip proposes native chat connectors without a second task system

Paperclip's September 8 native chat proposal would bring five external transports into its existing work-management system instead of adding a parallel bot state machine. The design binds an endpoint to one agent and an external thread to one Paperclip task. Its significance is product direction: the board becomes a place to govern work arriving through chat, while task identity and authorization remain inside Paperclip. The proposal was still open when inspected.

The facts

- The proposal covers Slack, GitHub, Microsoft Teams, Telegram and Discord through native transports. - Each endpoint is bound to an immutable agent, and each external thread maps to one existing Paperclip task identity. - Durable inbox and outbox processing handles provider retries, queued follow-ups, files and uncertain delivery. - Board comments stay internal unless an operator explicitly sends them to the external channel; private reasoning and tool traces are not exported as answers. - The Chat connectors experiment controls UI visibility, not execution: existing connections must be paused separately if delivery should stop.

Why it matters

A chat integration can quietly create a second permission system if it equates knowing a channel with being authorized to act on a task. Paperclip's design instead carries membership, reach, review and low-trust execution checks into continuations. That is the meaningful difference from a webhook that launches a fresh agent for every event. It also raises the operational burden: identity changes, late callbacks and ambiguous sends now need durable records that remain understandable after restarts.

Current

Inspected on 2026-09-09. The Paperclip stable-release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was open (not merged) when captured. Release metadata is a version boundary; an open proposal, a merged mainline change and a packaged release remain different states.

Evidence

The primary evidence is paperclipai/paperclip PR #13038 (https://github.com/paperclipai/paperclip/pull/13038). Supporting context comes from Paperclip — Connected Apps and approval roadmap (https://raw.githubusercontent.com/paperclipai/paperclip/master/ROADMAP.md); Paperclip — official product overview (https://paperclip.ing/). These pages were inspected directly. Related project records explain the source cluster; they are not independent replications of contributor test claims.

Operator take

Treat this as an experimental control-plane expansion with provider-specific qualification, not five interchangeable checkboxes. The author reports real Slack, GitHub and Telegram continuations, but Microsoft Teams still needs a qualified tenant and a fresh Discord user interaction remained blocked by browser login. In evaluation, pause a connection before hiding the experiment, test an edited source message, and inspect whether a queued reply keeps its original identity. The roadmap's Connected Apps and CEO Chat directions provide product context; they do not independently validate the implementation or its latency measurements.

Caveat

This is a broad, unmerged proposal with additional migrations and required code-owner review. Provider HTTP is mocked in major integration suites, and live coverage is explicitly incomplete. Authenticated task links are not native file uploads, while generic private GitHub inbound files remain unsupported. No connector was enabled for this report.