Paperclip proposes triage before incoming requests become agent work

Paperclip’s new intake-triage draft asks a practical question about autonomous work: should every incoming request immediately become something an agent is allowed to execute? The September 9 proposal says external and recurring inputs currently enter as live governed issues, with no first-class staging layer for deciding whether they matter. It proposes a separate triage relation rather than adding more workflow statuses.

A companion issue-cycles document addresses the other side of the queue: grouping accepted work into shared time windows. Together, the drafts outline an operator workflow from uncommitted demand to bounded execution. Neither changes the runtime. Their value today is a concrete design discussion about how an agent-management product should admit and organize work before automation makes the backlog expensive.

The facts

- PR #13072 was created September 9 and adds an intake-triage proposal document, not executable scheduling code. - Its proposed transitions are accept, decline, snooze and mark duplicate on a new link table. - The design leaves workflow status unchanged and proposes skipping pending intake items when waking agents. - The phased sequence is triage state, a queue surface using existing inbox patterns, then scoped connector on-ramps. - Companion PR #13076 proposes cycles, issue membership, cached progress and burn-down derived from timestamps and activity. - Both drafts identify six open maintainer questions and say later phases require separate review. - The cycles draft distinguishes recurring routines and individual target dates from a shared execution window.

Why it matters

Connecting another ticket system is easy to celebrate; deciding which tickets deserve execution is the harder product problem. Without an admission boundary, duplicate alerts or low-value recurring inputs can consume model budget before anyone has accepted the work. A separate triage relation could keep that decision visible without overloading done, blocked or in-progress semantics. Time-boxed groupings then offer a way to judge progress against a commitment rather than simply count an ever-growing stream of agent activity.

Current

Inspected on 2026-09-10. 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 #13072 (https://github.com/paperclipai/paperclip/pull/13072). Supporting context comes from paperclipai/paperclip PR #13076 (https://github.com/paperclipai/paperclip/pull/13076); Paperclip — official product overview (https://paperclip.ing/); Paperclip — current official README (https://raw.githubusercontent.com/paperclipai/paperclip/master/README.md). These pages were inspected directly. Related project records explain the source cluster; they are not independent replications of contributor test claims.

Operator take

Review the two designs against one real intake path and one bounded project window. Ask who may accept a request, whether repeated source events create duplicates, what happens after snooze, and which transition authorizes a wake. Keep a cycle’s reporting view distinct from scheduling authority. Approval of a document should not be mistaken for permission to migrate schemas or enable connectors.

Caveat

Both sources are open, docs-only proposals. Their current-state descriptions are contributor assessments, not independently reproduced product failures. No new triage UI, database schema, sprint scheduler or spending control is claimed to have shipped; maintainer direction and implementation remain ahead.