Paperclip proposes permanent agent personas across tasks and onboarding

Paperclip's September 10 persona proposals treat recognizable agent identity as shared application data rather than decoration local to one page. The foundation change would assign a stable palette from a fixed ClipLab character library, persist that appearance on the agent and expose cached image URLs for external integrations. A companion proposal carries the same identity through lists, tasks, comments, the org chart, selectors and onboarding. Both remained open when inspected.

The design makes a deliberate performance split. Dense lists use static images; an agent header may show one animated character with pointer tracking. Reduced-motion, touch, hidden-content and renderer-failure fallbacks remain part of the contract. The product consequence is continuity: reconnecting a provider or revisiting a draft should not make an agent look like a different worker. That visual continuity is explicitly separate from the permission and status machinery that determines what the worker can actually do.

The facts

- PR #13170 adds validated appearance data, deterministic migration backfill and random defaults at agent creation. - The foundation preserves appearance through hire approvals, configuration revisions and company portability. - SVG rendering in Node and PNG rendering with sharp are paired with a bounded worker pool, request coalescing and disk or S3 caching. - PR #13171 places static persona images across lists, tasks, comments, activity and dashboard views. - The UI proposal allows one live character per view and specifies reduced-motion and touch fallbacks. - The contributor reports 38 Linux visual/performance checks, including 500-avatar coverage; the screenshots use synthetic Storybook fixtures.

Why it matters

A control plane with several agents needs a reliable way to distinguish participants across a handoff. A stable visual marker can help a reader follow who wrote a comment or owns a task without rereading every label. It can also mislead if a friendly character is mistaken for evidence of competence or readiness. Paperclip's stated boundary is therefore important: company isolation, permissions and authoritative status labels retain their existing meaning.

Current

Inspected on 2026-09-11. The Paperclip release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was open (not merged) when captured. Release metadata bounds availability; proposals, merged mainline changes and packaged releases are not interchangeable.

Evidence

Primary evidence: paperclipai/paperclip PR #13171 (https://github.com/paperclipai/paperclip/pull/13171). Supporting context: paperclipai/paperclip PR #13170 (https://github.com/paperclipai/paperclip/pull/13170); Paperclip — official product overview (https://paperclip.ing/). These pages were inspected directly. Linked documentation establishes the product contract; it does not independently reproduce contributor or author experiments.

Operator take

Review the migration and portability behavior before the animation. A useful acceptance test keeps one agent's appearance consistent through edit, reconnect, approval and export/import, then checks a dense task view without live rendering in every row. The UI PR depends on the foundation landing first. Treat the contributor's screenshot and performance receipts as review evidence, not proof that the feature has shipped or been exercised against a real customer company.

Caveat

Both proposals were open at capture. The reported Linux tests and screenshots are contributor evidence using fixtures; this run did not reproduce the rendering suite or complete real provider sign-in. Visual identity does not confer authority.