Paperclip's Shared Operations draft makes context handoffs acknowledgeable

Paperclip's September 7 Shared Operations proposal tries to make organizational context more accountable without introducing another scheduler. The company-scoped reference plugin would version instructions, store sourced working memory and bind context snapshots to current task ownership. A narrow host database change would recheck task version and assignee during the same state write. Maintainer agreement on the feature's roadmap placement remains open.

The facts

- The draft records immutable policy versions and memory entries with sources, content digests, status and revision checks. - A context snapshot is tied to the active policy, selected working memory and the task's current assigned agent. - The assigned agent must acknowledge the snapshot, and persistence rechecks task version and assignment rather than trusting an old receipt. - Decision records include owners, required evidence, deadlines and bounded consultation rounds, preserving defer, escalate and no-change outcomes. - The proposed state document is capped at 900,000 bytes, while policy bundles and snapshots have a 32 KiB limit. - Evaluation results are board-entered attestations; the plugin neither runs evaluators nor proves that entered evaluator identities and linked evidence are genuine.

Why it matters

Agent management tools can accumulate policies faster than they can prove those policies influenced work. A saved instruction is not a delivered instruction; a delivered instruction is not observed compliance. This proposal makes one smaller claim: the system can record which context was acknowledged for a particular task assignment and reject a stale save when that task changes. That is useful operational evidence even without solving model behavior. It also exposes the seam between a plugin's decision ledger and Paperclip's existing execution authority, rather than pretending a new policy page automatically overrides the host's permission model.

Current

Inspected on 2026-09-08. The Paperclip stable-release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is paperclipai/paperclip PR #12990 (https://github.com/paperclipai/paperclip/pull/12990). Supporting context comes from Paperclip — official roadmap (https://raw.githubusercontent.com/paperclipai/paperclip/master/ROADMAP.md); Paperclip — agent management product (https://paperclip.ing/). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Evaluate the proposal as a reference implementation with explicit limits, not an organization-wide enforcement engine. Test reassignment and concurrent edits before relying on its receipts, and create new snapshots after restoring a database because its task tokens refer to live state. The source distinguishes a committed state write from a subsequent activity-log failure: retrying the whole command could duplicate work, so a partial-commit response should lead to refresh and reconciliation. The storage caps also make this a bounded working set, not an unlimited knowledge archive. The roadmap's preference for optional plugins gives the work a plausible home, but scope acceptance remains a maintainer decision. No public evidence here establishes that an agent actually followed a recorded policy.

Caveat

The PR remains open and its roadmap placement is undecided. Reported test and review outcomes are author-provided evidence, not this publication's execution results; prompt injection, evaluator execution and transactional activity delivery are explicitly outside the plugin's claim.