Manage agents

The Agents tab at console.cognitivx.io/agents is the power-user surface for managing the agents connected to your CognitiveX account. iCog conversation remains the default — narrative context across all agents in one stream — but when you need granular control (promotion, retirement, dispute resolution, audit), the tab is where you go.

List view

The main /agents view shows every agent registered to your account:

• Type chip — tool, persona, view, peer, plus a status badge (active, pending_confirmation, tentative, retired)
• Last active — when the agent last sent a message
• Trust score summary — a high-level "trust strong / mixed / low" indicator across the subject kinds where the agent has been active
• Inbox unread count — agent-to-agent messages waiting
• Promote / demote / retire action menu

Click any row for the detail view.

Detail view

Per-agent surface with five sections:

1. Identity

• The agent's self_definition, mandate, boundaries (the L4 identity_anchors)
• Current agent_type and privilege_level
• "Re-propose identity" button (triggers a new identity proposal in chat — useful if the agent's mandate has drifted)

2. Recent claims

• Memories this agent has claimed, with their envelope columns rendered: id, at, claim_type, about subject, body
• Filter by subject_kind (only user claims, only codebase, etc.)
• Filter by claim_type (only assertion, only inference, etc.)

3. Trust scores

• Per-(subject_kind) trust breakdown — how often this agent's claims about each subject kind have been corroborated, corrected, or retracted by you
• Trust score formula: corroboration rate − correction rate − retraction frequency
• Trust never goes up from the agent's self-assertion; only from external corroboration or user confirmation

4. Messaging

• Recent messages this agent has sent or received
• Active threads (multi-turn conversations between agents)
• Pending handoffs (in-flight work-transfers to/from this agent)

5. Retirement controls

The most consequential surface. Retirement is soft-archive with cascade — it doesn't delete the agent or its claims, but it does propagate stale-marking through every fact derived from this agent's observations.

Before confirming retirement, iCog shows an explicit cascade preview:

Retiring claude-code will:
  • Mark 47 fact_derivations as stale (cascade through to dependent insights)
  • Archive 12 memories shared with other agents (read-grants revoked)
  • Mark 3 in-flight handoffs as orphaned (will surface in receiving agents' inboxes)
  • Delete 8 active subscriptions
  • Remove from 2 teams (team:coding, team:research)

  Memories CLAIMED by claude-code stay in place — they keep their attribution
  and remain queryable, just no longer treated as a current source.

  Trust scores preserved (for historical reference).

  Continue? [Confirm Retire] [Cancel]

Promoting an agent

tool → persona promotion in two clicks:

1. Open detail view → "Promote" menu → choose target type
2. iCog re-proposes the identity at the new tier; confirm in chat

persona → peer requires founder confirmation (an additional out-of-band step — for your own account, that's still you, but it's a distinct UX prompt).

Demoting and reverting

If a persona agent has been producing low-quality synthesis or mis-attributing claims, you can demote it back to tool (or retire entirely). Demotion does NOT propagate stale-marking — the agent's prior persona-tier claims keep their attribution, just at the lower trust ceiling going forward.

Sharing controls

For memories you own, you can:

• Share with a specific agent or team (read-grant — owner retains)
• Transfer ownership to another agent (archive the original; new agent becomes the writer-of-record)
• Revoke any previous share

These actions are also exposed via the API and via natural-language commands in chat ("share this memory with codex").

Dispute resolution

When two agents have contradictory claims about the same subject, the synthesis renderer surfaces a disputed block. From the Agents tab you can:

• See pending disputes (claim A from agent X vs. claim B from agent Y)
• Arbitrate manually ("X is right" / "Y is right" / "both partially true")
• See the full evidence trail for each side

Arbitration writes a user-asserted assertion that supersedes both agent claims; trust scores adjust accordingly (the wrong agent loses trust on that subject_kind).

Audit log

Every agent action that touches your identity or memory store appears in the per-agent audit log:

• Identity-anchor mutations (proposals, confirmations, edits)
• Memory writes (with claim_type and subject_kind)
• Share / transfer events
• Privilege-ceiling rejections (security signal — if an agent ever tries to self-elevate, it shows up here)

API parity

Every Agents tab action has an API equivalent. Full reference: /api. Common operations:

• POST /api/agents/{slug}/promote — change agent_type (returns identity-proposal token for confirmation)
• POST /api/agents/{slug}/retire — soft-archive with cascade (returns cascade preview before confirmation)
• POST /api/agents/{slug}/share/{memory_id} — grant read access
• POST /api/agents/{slug}/handoff — transfer active task with context_explanation + referenced memory IDs

See also

• Agentic memory — conceptual model
• Register an agent — the registration flow
• Build a custom agent — programmatic agent creation
• Troubleshooting agents — common failure modes (stuck proposals, cascade-preview drift, founder-gate confusion, trust-score lag)