Paperclip v2026.817.0: agents propose, you decide

Some actions need a person’s permission. Until now, an agent could stop and make you reconstruct the request from its thread, or act and hope you agreed.

Paperclip v2026.817.0 gives that request a proper place: the agent proposes a specific action, and you approve or decline 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 ask for permission

A Decision asks one question: may this agent take this action? The agent shows the exact change. Nothing happens until an authorized person approves an option. Paperclip then applies only the changes shown and records the result.

If a target changes first, Paperclip disables stale options. Destructive actions confirm their scope. Declines stay on the record, and unanswered requests expire.

A Paperclip Merch Store decision asking permission to place an $8,750 hoodie order, with options to approve it or request a smaller order. — The Chief of Staff asks permission to place a merch order. You can approve it or request a smaller run.

Use Decisions only for actions an agent may not take alone. The Decisions guide shows how to answer one.

Agents can coordinate across tasks

Standard-trust agents can now leave notes on sibling tasks. They can do this only when both the agent and the human responsible for its run can access the task.

Paperclip attributes each cross-task write to the agent, responsible person, and run. If a write is blocked, Activity names the rule. Company, trust, pause, and budget limits still apply.

The old Audit page has merged into Activity. Use the Agent actions view to see who did what, on whose behalf, and in which run. Scripts that used /audit should move to /activity.

The Activity page showing the Chief of Staff commenting on the task Confirm hoodie sizes and quantities, with the responsible person and originating run. — The Chief of Staff leaves a note on a sibling task. The same row links the action to its task and 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 tasks, review your trust scopes and task 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 action is waiting for permission. If it isn’t, each row shows an action an agent has already worked out and written down for you.