Tool Persona Manager
One interactive surface for personas: browse, edit, create, delete.
Returns a view rather than a wall of JSON. The roster is on the left, the selected persona's traits are sliders on the right, and save, delete and create are in the view. Call this instead of chaining list_cognitive_personas, persona_lookup, persona_update and persona_delete by hand.
Usage
{ "tool": "persona_manager", "params": { "filter": "custom" } }
| filter | shows |
|---|---|
custom (default) |
personas you created — the editable ones |
builtin |
the personas that ship with the package, read-only |
all |
both |
Reads travel with the result, so switching between personas in the view costs no round trip. Only writes go back to the server, through persona_update and persona_delete — the same tools with the same guards, not a second implementation.
Creating a persona: three routes, three forms
A persona's motivational values come from one of several routes, and the route decides which fields are even meaningful. Asking for a description and a survey and a personality profile in one form would demand three answers when supplying any one of them is the whole job. So the form switches:
| route | what you fill in | reaches |
|---|---|---|
| From a description | a paragraph of prose | all 13 values, via inferred Big Five |
| From a survey | 26 trait sliders, each with its criterion on hover | 9 of 13 |
| From Big Five | 5 personality sliders | all 13 |
Update offers the same three against an existing persona, prefilled with what it already has — so "revise this from a new description", "re-answer the survey" and "give it a Big Five profile" are all one click from the persona.
Description mode completes in the conversation, not the view
Inferring traits from prose needs a model reading the text, and the widget sandbox has none. So that mode composes the request and hands it to the assistant, which completes it through persona_create_from_description and the completeness contract.
The form says so. A mode that silently did nothing, or spun on a write that could never happen, would be worse than one that names where the work happens.
Survey and Big Five complete in the view immediately.
What it will not do
Built-in personas render read-only. They ship with the package and are shared by every install, so the server refuses to edit or delete them and the view does not offer to.
Unsaved edits are not discarded silently. Switching personas with pending changes asks first.
A partial write is reported. Personas live in two stores, and if one accepts a write and the other does not, the status line says so rather than reporting success. A persona updated in one store and not the other is the hardest failure in this subsystem to notice.
Description drift comes back with the save
Changing traits can leave the prose describing someone else — a vector that now says "impatient" under a description that still says "patient". The save reports which description claims the new numbers contradict.
The description is never rewritten. Someone wrote it, and it carries intent numbers cannot.
Related
- persona_update — the write path behind the sliders
- persona_delete — the delete path
- persona_create_from_description — what description mode hands off to