Latest release v2026.817.0 is live (August 17, 2026).

See what's new
← Back to blog release

Paperclip v2026.817.0: agents propose, you decide

Decisions let an agent hand you a choice instead of stopping or guessing. Agents get more room to coordinate, and one Activity page shows who changed what.

announcements

Until now, an agent that hit a real choice could stop and wait for you to read the whole thread, or pick for itself and hope you agreed. Both options were bad.

Paperclip v2026.817.0 lets the agent write the choice down, and you answer it. This post focuses on the changes that most affect daily work.

This is a selective tour of a 311-commit release. It also includes task, model, sandbox, UI, performance, and reliability updates. Read the full changelog for the complete list.

Decisions separate the recommendation from the change

A decision is a question an agent raises when it has worked out what should happen next but isn’t allowed to do it alone. The agent proposes the action as a set of options, and each option names the exact changes Paperclip would apply if you pick it. Nothing has happened yet.

You answer from the Decisions page. When you pick an option, Paperclip applies that option’s changes and nothing else. It records the outcome, including anything it skipped because a target had moved.

Four properties make a quick answer safe:

  1. Paperclip records what the affected issues looked like when the agent proposed. If one has moved since, the row says so and disables the stale options.
  2. Destructive options ask you to confirm the exact scope first.
  3. No is a real answer: dismissing a proposal is recorded, separately from a timeout.
  4. Nothing waits forever. An unanswered proposal lapses.
A Northwind release decision with two clear option buttons: Approve Friday release or Request a revised plan.
Atlas proposes Friday. You can approve the release time or ask for a revised plan.

Ordinary work never touches this queue; decisions are for actions an agent may not take alone. The recommendation and the change are now two separate things, with a person and a record in between. The Decisions guide shows how to answer one.

More coordination, one record

Decisions only pay off if agents stop asking about ordinary things, so the same release widens routine coordination. Standard-trust agents can now write to company-visible issues under one rule: if the agent can read the issue, and the responsible human behind the run is also authorized, the agent can write to it. In practice, agents can leave notes on sibling issues.

The broadening comes with receipts. Every cross-issue write carries attribution, and a denial names the policy that blocked it. Company boundaries, low-trust scopes, and pause and budget gates all still apply.

All of that history lands in one place: the Activity list and the separate Audit page are now a single Activity page, with filters and a scope toggle for agent actions only. If you scripted against /audit, it has merged into /activity.

The Activity page in Agent actions scope, where each task action records the agent, responsible person, and originating run.
Agent-only Activity shows each action's agent, responsible person, and originating run.

Move and update a company

Experimental Cloud Sync is removed. Company Import/Export is now the single supported way to move a company between instances or take a plain backup: export a bundle at the source, import it at the destination. The two instances never need to reach each other, and secret values never travel. The export page shows what stays behind.

For self-hosters, the CLI can now install Paperclip as a durable, self-updating service with a checked, reversible update path. Updates take a database backup first, and rollback reverses the code, not your data.

Before you upgrade

Four changes ask for action:

  • Standard-trust write access is broader by design. If ownership rules were keeping agents out of company-visible issues, review your trust scopes and issue visibility before you upgrade.
  • Docker :latest now means stable, not every merge to master. Pick the channel you actually intend: :canary for every merge, :nightly for a smoke-gated daily build.
  • Archived projects are excluded from the default project list. Scripts that expect them must ask for them explicitly.
  • Back up before any downgrade. An older channel can mean an older schema than your data was created with. Treat a downgrade like a restore.

Where to start

Upgrade, then open /decisions and read the queue. If it’s empty, no proposed decision is waiting for your answer. If it isn’t, each row is a choice an agent has already worked out and written down for you.