Files
PaperClipAI/docs/specs/agent-config-ui.md
T
DottaandPaperclip ebaeba40ee feat: simplify agent onboarding and configuration (#13011)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Operators create agents and configure their runtimes in the board
UI.
> - The old creation flow presents several choices and a large form
before an agent can start.
> - The existing onboarding controls already provide clear provider
connection steps.
> - This pull request uses those controls in a new-agent wizard and
organizes the full configuration pages.
> - Operators can connect, test, save, and assign a first task while
keeping the existing configuration tools.

## Linked Issues or Issue Description

Related: #10974. That earlier open PR also reorganizes agent
configuration. This PR follows the reviewed Storybook designs for agent
creation and the current configuration tabs.

**What existing behavior does this improve?**

Agent creation, provider connection, runtime tests, and full agent
configuration.

**Current behavior**

The creation dialog leads to a large manual configuration form. Provider
login controls differ from onboarding. Environment variables and secret
access appear in separate places.

**Proposed behavior**

Choose a name and adapter. Connect Claude or Codex through the existing
onboarding controls. Configure and test the runtime, save the agent, and
open a task dialog with that agent assigned. Use the same design on the
existing configuration tabs.

**Reason and benefit**

The first setup asks for fewer decisions. The full editor keeps
instructions, skills, runtime controls, secret access, permissions,
keys, and revisions available in clear sections.

**Breaking changes**

The board creation and configuration layouts change. The
test-environment API adds an optional, allowlisted `testCredentials`
field for one-shot probes. Database contracts stay the same. Native ACPX
tests now reject unsupported local platforms before a CLI login can mask
the runtime restriction.

## What Changed

- Added a new-agent wizard with numbered steps, adapter branding,
provider connections, editable model choices, runtime tests, and
confirmation.
- Added Codex app-server, Claude ACPX, and OpenCode runner choices.
- Stored API credentials through existing secret APIs and persisted
references in agent configuration. New setup keys are isolated from
credentials used by existing agents.
- Preserved external-agent invitations beside the wizard, including
optional messages, one-time prompts, and clipboard fallback.
- Added OpenRouter provider and secret bindings for Pi and OpenCode.
- Added adapter-specific prerequisite fields for Cursor, Gemini, Kimi,
and Hermes. Cursor Cloud keys are saved as new organization secrets.
- Fixed Cursor Cloud repository field mapping, omitted empty remote
environment values, and added useful model and repository error
messages.
- Preserved complete MCP assignments when multiple valid profiles
contain more than 250 tools in total. Generated profiles retain exact
tool selectors.
- Added service branding and deployment-aware adapter choices. Cloud
setup offers Claude, Codex, and OpenCode; local native runners require
the experimental setting.
- Made the agent list responsive at intermediate widths.
- Applied the reviewed design to the real agent configuration pages.
Kept the instruction editor, skills, and existing mutations.
- Combined secret access and environment variables under one Save and
Discard action.
- Added interactive Storybook screens for setup, configuration,
confirmation, authentication, and test results.
- Fixed Pi provider-error parsing and thinking-effort persistence.
Native ACPX validates Linux x64 on the actual local, SSH, or sandbox
target.
- Redacted the complete transient probe-credential field from HTTP error
logs, including rejected provider names.

## Verification

- Current head `df0292fe6` has a fresh Greptile 5/5 review with no
unresolved findings. All 31 executed CI checks passed, including the
aggregate verification gate and all browser E2E shards. Storybook visual
regression is skipped by its workflow; the local Storybook build passed.

- Browser tests completed real assigned tasks with direct Codex, Claude,
OpenCode, Pi, and native Codex.
- Verified external-agent invitation generation and automatic prompt
copying in the live browser.
- Pi and OpenCode used an existing OpenRouter secret. Browser checks
covered save and reload, instruction edits, skill selection,
environment-variable Save and Discard, and assigned task creation.
- Invalid Claude API credentials remained on the connection step with an
error. A live Pi/OpenRouter invalid-key probe returned a provider
failure and left the user-secret inventory unchanged (zero entries
before and after).
- Full workspace typecheck and build passed after rebasing onto current
master. After review fixes, server and UI typechecks, token gates, and
the full build passed again. Storybook built successfully.
- All 5,542 local UI tests passed. The Cursor Cloud and Pi adapter
regressions passed all 24 tests. Review regressions passed 69 server
tests and all 18 agent-list tests.
- The local full test command ran 6,971 general server tests
successfully. Editing review fixes during that long run caused nine
tests to use stale modules; fresh isolated runs passed. An unrelated
embedded-Postgres fixture hit the host shared-memory limit; its 15
affected tests passed when the fixture groups ran separately.
- Local workspace groups passed after rerunning 18 CLI tests
sequentially to avoid host database limits and parallel-load timeouts.
The local full command stopped at the general server phase, so
serialized server verification comes from the five passing CI shards.
- Browser testing at 390px confirmed that the agent action menu opens
and the page has no horizontal overflow. CI browser E2E shards passed.
- Review the `Onboarding / New agent` and `Agents / Configuration
refresh` Storybook groups. In the real app, create an agent, run its
connection test, save it, assign a task, and reload its configuration.

## Risks

- This changes the main agent setup and configuration UI. Regression
tests cover routing, persistence, secret bindings, and form actions.
- Native Claude ACPX requires Linux x64. Direct Claude works on macOS.
Remote checks execute a bounded platform probe and reject unsupported or
unverified targets.
- A native OpenCode task reached the provider context limit because of
its tool payload. Its provider connection test passed. Direct OpenCode
completed a task. This existing native execution limit is not fixed
here.
- Claude and Codex connection keys use the existing user-secret store.
Other runtime setup keys use distinct organization secrets. Existing
credentials are never rotated. Probes do not store entered keys. Failed
agent creation removes newly staged credentials.
- Cursor Cloud has not completed a live task. Its authenticated account
still needs GitHub repository access. The live run passed MCP
provisioning, remote environment validation, and explicit Auto model
selection before the repository prerequisite blocked execution.
- Generated runtime MCP profiles can exceed the public profile-edit
request limit. They still contain exact catalog selectors and preserve
permission boundaries.
- No database migration, dependency, lockfile, or workflow changes are
included.

## Model Used

OpenAI Codex, based on GPT-6, with reasoning, repository tools, shell
execution, and browser automation. The runtime did not expose the exact
model ID or context window size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-09-08 14:22:32 -05:00

14 KiB
Raw Blame History

Agent Configuration & Activity UI

Current implementation (2026-09-07)

The shipped new-agent flow starts from Agents → New Agent. A small dialog collects a name and an enabled adapter, then opens a setup page with numbered navigation. Claude and Codex have a subscription/API-key connection step. Configuration provides a searchable, free-text model selector and an environment selector; additional settings remain on the full agent page. Finish setup submits the existing governed hire request. Confirmation links to configuration and opens a new task with the created agent assigned; agents awaiting approval cannot be assigned work yet.

Paperclip Runner offers native Codex (app server), Claude via ACPX, and OpenCode. The selected provider is passed through the existing runner configuration builder. Codex's default is the adapter catalog default. OpenCode and Pi require a provider/model ID; OpenRouter uses openrouter/<provider>/<model> and OPENROUTER_API_KEY. Entered keys are tested through the probe-only testCredentials field without storage. Finishing setup saves each key as an isolated user secret so a failed test cannot overwrite another agent’s credential, and an existing organization secret can also be bound. Agent configuration and revisions contain references, never the entered key.

Run test uses the chosen environment and current configuration. For Claude/Codex readiness checks that do not make a model request, setup also invokes the adapter's existing CLI hello probe with the same environment and credentials. Runtime failures, provider failures, warnings, and in-progress tests use the same compact result card in setup and full configuration. Warnings remain distinguishable from blocking failures.

The new-agent dialog also retains an external-agent invitation link, with an optional message, one-time onboarding prompt, and clipboard fallback. External agents still require organization-admin approval.

The full configuration page retains the contextual navigation and existing instruction-file editor, skills, tools, permissions, API keys, and revision behavior. Secrets & variables groups environment bindings with API secret-access grants. Its page-level Save/Discard actions include editor-local environment drafts. Activity, runs, costs, and budgets link to the company audit views scoped to the agent.

The sections below are the original design reference; the implementation summary above supersedes their creation-dialog layout.

Context

Agents are the employees of a Paperclip company. Each agent has an adapter type (claude_local, codex_local, process, http) that determines how it runs, a position in the org chart (who it reports to), a heartbeat policy (how/when it wakes up), and a budget. The UI at /agents needs to support creating and configuring agents, viewing their org hierarchy, and inspecting what they've been doing -- their run history, live logs, and accumulated costs.

This spec covers three surfaces:

  1. Agent Creation Dialog -- the "New Agent" flow
  2. Agent Detail Page -- configuration, activity, and logs
  3. Agents List Page -- improvements to the existing list

1. Agent Creation Dialog

Follows the existing NewIssueDialog / NewProjectDialog pattern: a Dialog component with expand/minimize toggle, company badge breadcrumb, and Cmd+Enter submit.

Fields

Identity (always visible):

Field Control Required Default Notes
Name Text input (large, auto-focused) Yes -- e.g. "Alice", "Build Bot"
Title Text input (subtitle style) No -- e.g. "VP of Engineering"
Role Chip popover (select) No general Values from AGENT_ROLES: ceo, cto, cmo, cfo, engineer, designer, pm, qa, devops, researcher, general
Reports To Chip popover (agent select) No -- Dropdown of existing agents in the company. If this is the first agent, auto-set role to ceo and gray out Reports To. Otherwise required unless role is ceo.
Capabilities Text input No -- Free-text description of what this agent can do

Adapter (collapsible section, default open):

Field Control Default Notes
Adapter Type Chip popover (select) claude_local claude_local, codex_local, process, http
Test environment Button -- Runs adapter-specific diagnostics and returns pass/warn/fail checks for current unsaved config
CWD Text input -- Working directory for local adapters
Prompt Template Textarea -- Supports {{ agent.id }}, {{ agent.name }} etc.
Model Text input -- Optional model override

Adapter-specific fields (shown/hidden based on adapter type):

claude_local:

Field Control Default
Max Turns Per Run Number input 80
Skip Permissions Toggle true

codex_local:

Field Control Default
Search Toggle false
Bypass Sandbox Toggle true

process:

Field Control Default
Command Text input --
Args Text input (comma-separated) --

http:

Field Control Default
URL Text input --
Method Select POST
Headers Key-value pairs --

Runtime (collapsible section, default collapsed):

Field Control Default
Context Mode Chip popover thin
Monthly Budget (cents) Number input 0
Timeout (sec) Number input 900
Grace Period (sec) Number input 15
Extra Args Text input --
Env Vars Key-value pair editor --

Heartbeat Policy (collapsible section, default collapsed):

Field Control Default
Enabled Toggle true
Interval (sec) Number input 300
Wake on Assignment Toggle true
Wake on On-Demand Toggle true
Wake on Automation Toggle true
Cooldown (sec) Number input 10

Behavior

  • On submit, calls agentsApi.create(companyId, data) where data packs identity fields at the top level and adapter-specific fields into adapterConfig and heartbeat/runtime into runtimeConfig.
  • After creation, navigate to the new agent's detail page.
  • If the company has zero agents, pre-fill role as ceo and disable Reports To.
  • The adapter config section updates its visible fields when adapter type changes, preserving any shared field values (cwd, promptTemplate, etc.).

2. Agent Detail Page

Restructure the existing tabbed layout. Keep the header (name, role, title, status badge, action buttons) and add richer tabs.

Header

[StatusBadge]  Agent Name                    [Invoke] [Pause/Resume] [...]
               Role / Title

The [...] overflow menu contains: Terminate, Reset Session, Create API Key.

Tabs

Overview Tab

Two-column layout: left column is a summary card, right column is the org position.

Summary card:

  • Adapter type + model (if set)
  • Heartbeat interval (e.g. "every 5 min") or "Disabled"
  • Last heartbeat time (relative, e.g. "3 min ago")
  • Session status: "Active (session abc123...)" or "No session"
  • Current month spend / budget with progress bar

Org position card:

  • Reports to: clickable agent name (links to their detail page)
  • Direct reports: list of agents who report to this agent (clickable)

Configuration Tab

Editable form with the same sections as the creation dialog (Adapter, Runtime, Heartbeat Policy) but pre-populated with current values. Uses inline editing -- click a value to edit, press Enter or blur to save via agentsApi.update().

Sections:

  • Identity: name, title, role, reports to, capabilities
  • Adapter Config: all adapter-specific fields for the current adapter type
  • Heartbeat Policy: enable/disable, interval, wake-on triggers, cooldown
  • Runtime: context mode, budget, timeout, grace, env vars, extra args

Each section is a collapsible card. Save happens per-field (PATCH on blur/enter), not a single form submit. Validation errors show inline.

Runs Tab

This is the primary activity/history view. Shows a paginated list of heartbeat runs, most recent first.

Run list item:

[StatusIcon] #run-id-short   source: timer     2 min ago     1.2k tokens   $0.03
             "Reviewed 3 PRs and filed 2 issues"

Fields per row:

  • Status icon (green check = succeeded, red X = failed, yellow spinner = running, gray clock = queued, orange timeout = timed_out, slash = cancelled)
  • Run ID (short, first 8 chars)
  • Invocation source chip (timer, assignment, on_demand, automation)
  • Relative timestamp
  • Token usage summary (total input + output)
  • Cost
  • Result summary (first line of result or error)

Clicking a run opens a run detail inline (accordion expand) or a slide-over panel showing:

  • Full status timeline (queued -> running -> outcome) with timestamps
  • Session before/after
  • Token breakdown: input, output, cached input
  • Cost breakdown
  • Error message and error code (if failed)
  • Exit code and signal (if applicable)

Log viewer within the run detail:

  • Streams heartbeat_run_events for the run, ordered by seq
  • Each event rendered as a log line with timestamp, level (color-coded), and message
  • Events of type stdout/stderr shown in monospace
  • System events shown with distinct styling
  • For running runs, auto-scrolls and appends live via WebSocket events (heartbeat.run.event, heartbeat.run.log)
  • "View full log" link fetches from heartbeatsApi.log(runId) and shows in a scrollable monospace container
  • Truncation: show last 200 events by default, "Load more" button to fetch earlier events

Issues Tab

Keep as-is: list of issues assigned to this agent with status, clickable to navigate to issue detail.

Costs Tab

Expand the existing costs tab:

  • Cumulative totals from agent_runtime_state: total input tokens, total output tokens, total cached tokens, total cost
  • Monthly budget progress bar (current month spend vs budget)
  • Per-run cost table: date, run ID, tokens in/out/cached, cost -- sortable by date or cost
  • Chart (stretch): simple bar chart of daily spend over last 30 days

Properties Panel (Right Sidebar)

The existing AgentProperties panel continues to show the quick-glance info. Add:

  • Session ID (truncated, with copy button)
  • Last error (if any, in red)
  • Link to "View Configuration" (scrolls to / switches to Configuration tab)

3. Agents List Page

Current state

Shows a flat list of agents with status badge, name, role, title, and budget bar.

Improvements

Add "New Agent" button in the header (Plus icon + "New Agent"), opens the creation dialog.

Add view toggle: List view (current) and Org Chart view.

Org Chart view:

  • Tree layout showing reporting hierarchy
  • Each node shows: agent name, role, status badge
  • CEO at the top, direct reports below, etc.
  • Uses the agentsApi.org(companyId) endpoint which already returns OrgNode[]
  • Clicking a node navigates to agent detail

List view improvements:

  • Add adapter type as a small chip/tag on each row
  • Add "last active" relative timestamp
  • Add running indicator (animated dot) if agent currently has a running heartbeat

Filtering:

  • Tab filters: All, Active, Paused, Error (similar to Issues page pattern)

4. Component Inventory

New components needed:

Component Purpose
NewAgentDialog Agent creation form dialog
AgentConfigForm Shared form sections for create + edit (adapter, heartbeat, runtime)
AdapterConfigFields Conditional fields based on adapter type
HeartbeatPolicyFields Heartbeat configuration fields
EnvVarEditor Key-value pair editor for environment variables
RunListItem Single run row in the runs list
RunDetail Expanded run detail with log viewer
LogViewer Streaming log viewer with auto-scroll
OrgChart Tree visualization of agent hierarchy
AgentSelect Reusable agent picker (for Reports To, etc.)

Reused existing components:

  • StatusBadge, EntityRow, EmptyState, PropertyRow
  • shadcn: Dialog, Tabs, Button, Popover, Command, Separator, Toggle

5. API Surface

All endpoints already exist. No new server work needed for V1.

Action Endpoint Used by
List agents GET /companies/:id/agents List page
Get org tree GET /companies/:id/org Org chart view
Create agent POST /companies/:id/agents Creation dialog
Update agent PATCH /agents/:id Configuration tab
Pause/Resume/Terminate POST /agents/:id/{action} Header actions
Reset session POST /agents/:id/runtime-state/reset-session Overflow menu
Create API key POST /agents/:id/keys Overflow menu
Get runtime state GET /agents/:id/runtime-state Overview tab, properties panel
Invoke/Wakeup POST /agents/:id/heartbeat/invoke Header invoke button
List runs GET /companies/:id/heartbeat-runs?agentId=X Runs tab
Cancel run POST /heartbeat-runs/:id/cancel Run detail
Run events GET /heartbeat-runs/:id/events Log viewer
Run log GET /heartbeat-runs/:id/log Full log view

6. Implementation Order

  1. New Agent Dialog -- unblocks agent creation from the UI
  2. Agents List improvements -- add New Agent button, tab filters, adapter chip, running indicator
  3. Agent Detail: Configuration tab -- editable adapter/heartbeat/runtime config
  4. Agent Detail: Runs tab -- run history list with status, tokens, cost
  5. Agent Detail: Run Detail + Log Viewer -- expandable run detail with streaming logs
  6. Agent Detail: Overview tab -- summary card, org position
  7. Agent Detail: Costs tab -- expanded cost breakdown
  8. Org Chart view -- tree visualization on list page
  9. Properties panel updates -- session ID, last error

Steps 1-5 are the core. Steps 6-9 are polish.

Native ACPX connection tests reject unsupported local platforms before a host CLI login can incorrectly mark the runner connected. The existing verified Claude ACPX runtime requires Linux x64; remote environments are evaluated independently of the control-plane host platform.