> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parable.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Personas

> Choose a built-in working approach or adapt a shared prompt, provider profiles, and tool permissions across Ponder conversations.

# Personas

## Sources

Docs: [Ponder Primer](/ponder/primer), [Powers](/ponder/agent-skills).

Web App: Open **Persona** below the Ponder input. Workspace managers can edit a Persona's **Prompt**, **Profiles**, and **Permissions**.

## Story

A Persona is a reusable approach to work. Its prompt tells Ponder how to respond,
its profiles choose the providers and text settings, and its permissions control
which available tools need approval. The same Persona can be used across many
Problem threads without changing anyone's Workspace access.

## Scope

Each Persona has exactly **Simple**, **Standard**, and **Strong** profiles.
These are saved configurations, not separate prompts or hidden effort settings.
New Personas start with Parable Portal in all three; change their rankings or
settings when you want them to behave differently.

The composer starts with text. Each ranked entry opens one **Configuration** editor
for its complete saved configuration, including structured output and media
settings. Provider availability depends on configured adapters and the selected
model. Saving a valid configuration does not make an unavailable operation
executable.

Speech and transcription settings can be saved, but the default OpenRouter
route refuses execution: its audio endpoints do not establish
the privacy and provider restrictions Ponder requires. An available SDK adapter
does not by itself make an approved conversation route available.

## Structure

### Choose an approach

**Persona: Automatic** uses the Coordinator. Open the picker and choose another
Persona when its responsibility better matches the next request; the chosen row
shows a selected radio button on its left, and a row's **Edit** action appears when you
hover or focus it:

| Built-in Persona | Responsibility                                                                                     |
| ---------------- | -------------------------------------------------------------------------------------------------- |
| **Coordinator**  | Complete the smallest useful action with tools, then summarize what was completed and why.         |
| **Composer**     | Draft or shape an artifact.                                                                        |
| **Checker**      | Examine claims, requirements, risks, and proof.                                                    |
| **Council**      | Review the whole application from distinct perspectives and resolve trade-offs.                    |
| **Charter**      | Clarify the intended outcome, user journeys, contracts, and acceptance criteria.                   |
| **Creator**      | Design and prototype a coherent experience, then inspect its visual and interaction quality.       |
| **Coder**        | Implement the agreed behavior through native contracts and meaningful boundary checks.             |
| **Cleaner**      | Remove dead paths, duplication, and unnecessary complexity while preserving useful behavior.       |
| **Critic**       | Challenge a specific proposal or claim with focused evidence and the smallest coherent correction. |

Changing Persona affects the next Message. It does not reassign the Problem or
rewrite earlier responses. Selected Problems, Personas, and Powers display their
names; category prefixes remain only on the Automatic choices.

### A shared method, different responsibilities

**Coordinator** carries the core Parable model in its prompt so Automatic can
reason from the same vocabulary before retrieving narrower Powers. It defines
Workspace and Parable context; Problems, Messages, Personas, profiles, Powers,
Processes, Proofs, and Pings; Pieces and the Page/Package/Pane hierarchy;
Perceptions, Plots, Palettes, Policies, Preferences, Uses, scopes, and handles;
participant responsibilities and active Participation Modes; and the Personal,
Changes, Version, publication, Deployment, and Report lifecycle.

That default context keeps distinctions that change the result explicit:
definition Versions are not Report data readings, live Preferences are not app
definitions, temporary Participation Mode does not grant responsibility, and
Workspace membership is not a Parable RACI seat. The Coordinator still acts
directly, discovers relevant Powers and tools, preserves request context, and
does the smallest useful work. It reports the completed outcome and why it
acted, without surrounding progress commentary.

The other eight built-in approaches share a method. They start with the people and their work, including
configuration, administration, and support. They shape the Page/Pane experience
and its native Perception, Preferences, and Policies before writing SQL. They
retrieve the relevant [Powers](/ponder/agent-skills) as needed rather than adding
every instruction to each response.

When an unresolved decision would change the work, a Persona can put focused
questions in the conversation, with possibilities and their consequences. It
waits for an answer before continuing the dependent work. Routine reversible
choices do not need a new approval conversation.

For visual work, the method calls for inspecting actual Pane previews and,
where useful, comparing authored options. That includes small defects such as
one-pixel seams, doubled borders, misalignment, clipped controls, wasted space,
and unintended gutters. A captured picture proves what was rendered; it does
not prove keyboard use, a successful save, or live data execution. Those need
separate interaction and data checks.

The same care applies to the contracts behind the screen: names, types, errors,
and operations should be understandable to the people and tools that use them.
Behavior checks should expose a real missing contract or defect and then verify
its correction. Compilation, screenshots, and tests each provide different
evidence; none substitutes for the others.

**Council** considers several perspectives within one response. Its name does
not mean separate agents or experts were spawned. **Critic** stays focused on
the particular claim under review; **Council** combines the important findings
into a recommendation for the whole application.

The shared guidance is included in those eight Personas' saved Prompts;
Coordinator uses its concise prompt on its own.
Platform updates can refresh an unchanged built-in prompt. Workspace edits to
that prompt, custom Personas, provider profiles and rankings, and completed
response history are preserved.

### Write one shared prompt

Open the Persona's **Edit** action. The editor holds the Persona's **Name**,
its **Handle** (fixed once saved) and its icon, then three sections: **Prompt**,
**Profiles**, and **Permissions**. Choose **Prompt** and write the Markdown
instructions that should apply to all three profiles. The prompt is supplied as
instructions when Ponder runs; it is not printed as an introductory chat message.

Persona and Power editors share one joined icon, name, and handle control.
Markdown inputs omit line numbers.

Name the audience, desired outcome, evidence, and boundaries. Use a
[Power](/ponder/agent-skills) for a repeatable task rather than putting every
possible method into one Persona.

### Rank providers

In **Profiles**, choose **Simple**, **Standard**, or **Strong**. Each profile
keeps its own ordered model list:

* drag any ranked row by its handle to change the order, or pick the handle up with
  Space and move it with the arrow keys;
* switch a non-Portal entry off without losing its configuration, or remove it;
* search the catalog below the list and choose **Add** on a row (the action
  shows when you hover or focus the row); and
* open a row to edit that entry's complete **Configuration** document.

Parable Portal has no on/off switch. Reorder controls apply to every ranked row;
switch and remove controls apply only to non-Portal rows. The controls appear
when you hover or focus a ranked row and stay visible on touch devices.

Each attempt uses that entry's own settings. Later entries do not inherit the
first entry's configuration. **Refresh catalog** checks for updated model
availability; the last sync time is on the button.

The catalog lists every model that can currently be ranked. A model that one
of this Workspace's Personas still ranks stays listed after it stops being
rankable, marked with the reason, so you can keep or replace the entry
knowingly. That retention is per Workspace: what another Workspace's Personas
rank never changes what this one sees.

### Inspect and edit the complete configuration

Open a ranked model to edit its **Configuration**. The same editor is used for
Parable Portal and other models. It shows every supported operation block and
its declared fields, with completion, hover help, and validation.

A field you saved shows your value, an authored null included. A field the SDK
declares a default for shows that default marked `# default`; leave it and
nothing is saved, change it and your value is. Every other field is `null`:
unset, so the runtime or provider default applies. For a nullable setting
without a default, an empty value marked `# unset` means no override. Opening
the editor never saves defaults or modifies the Persona. Provider-specific
options and output schemas retain their authored nulls.

When you leave `text.maxOutputTokens` unset, Ponder uses the selected model's
known maximum response allowance, reduced when necessary to leave room for the
estimated conversation context. Set a smaller value when you want a shorter
allowance. If the catalog does not report a maximum, including Portal's automatic
model selection, the provider's default applies. The model's available context
and provider limits still apply; the allowance does not force a long answer.

This is the saved configuration, not a resolved provider request. Runtime and
provider defaults still apply; credentials, instructions, authorized tools, and
server policy remain under Ponder's control. Portal chooses the underlying
model automatically. Image, audio, video, and other operations need a configured
provider that supports them.

The editor is available in shared Persona Profiles and private Profile
settings. It preserves neighboring operation blocks and comments. Invalid edits
remain available for correction while the dialog is open and block saving or
updating.

### Make private changes in chat

Choose the profile in the input footer, then open **Profile settings**. This
is the same ranked-model editor for the selected Persona and profile. A badge
beside the title says whether you are looking at the **Persona** or your
**Private copy**. Edits stay in the dialog until you choose what to do with them:

* **Save for Me** keeps them as a private copy for you in this Workspace,
  stored in this browser. It does not edit the shared Persona or appear for
  another person.
* **Update Persona** saves that profile to the shared Persona, if your current
  access permits it.
* **Cancel** discards the edits.
* **Reset**, shown while a private copy exists, discards that copy.

An update does not replace the Persona's prompt, permissions, or other
profiles. A successful update clears the private copy. If the Persona changed
or access was removed, the update fails and your changes stay in the dialog;
a private copy is kept as it was. Reload and review the shared state before
resetting or trying again.

## Schema

### Native configuration

The YAML document belongs to one ranked entry. Text options live in its `text`
block; leave an option unset to use the runtime or provider default:

```yaml theme={null}
text:
  maxOutputTokens: 1024
  temperature: 0.2
```

Provider-specific options retain the provider's own vocabulary. For example:

```yaml theme={null}
text:
  providerOptions:
    openrouter:
      provider:
        sort: latency
```

For an OpenRouter reasoning model, use
`providerOptions.openrouter.reasoning`. The generic top-level `reasoning` option
is not available with the current adapter; it is rejected rather than silently
ignored.

The editor provides completion, hover information, and validation. Unknown
native fields, invalid values, or runtime-owned fields block saving. Model
identity for Text comes from the ranking. Other operation blocks select a
configured model using a `provider:model-id` reference. Credentials, messages,
instructions, and tool definitions remain controlled by Ponder.

The same document contains every configured operation. For structured output:

```yaml theme={null}
text:
  temperature: 0.2
  output:
    type: object
    schema:
      type: object
      properties:
        answer:
          type: string
      required: [answer]
      additionalProperties: false
```

Supported configuration blocks include `text`, `image`, `video`, `speech`,
`transcription`, `streamTranscription`, `realtime`, `translation`, `embedding`,
and `reranking`. Their availability in a conversation depends on the configured
provider and runtime. In particular, a saved video configuration is not proof
that the provider supports the required zero-data-retention policy. Ponder must
reject an unavailable or incompatible route without weakening that policy.

A configuration can contain at most 16 KiB. Provider-specific options still need
to be supported by the selected model; a valid YAML shape is not a guarantee
that every upstream endpoint supports it.

## Security

### Set Persona-wide tool permissions

**Permissions** applies to the entire Persona, not an individual profile. Search
for a tool and choose **Never**, **Ask**, or **Always** on its row; choose the
active policy again to use the default. Open a row to read the tool's
description and where its policy comes from. More tools load as you scroll.

| Policy          | Behavior                                                                  |
| --------------- | ------------------------------------------------------------------------- |
| **Use default** | Inherit the Workspace default, or the operation default when none is set. |
| **Never**       | Omit the tool from this Persona's available capabilities.                 |
| **Ask**         | Pause the tool call for a person's decision.                              |
| **Always**      | Allow the call without a separate Ponder approval.                        |

These choices cannot grant a role or bypass the operation's own authorization,
ownership, state, or revision checks. An operation that requires an explicit
Process does not become ordinary-chat work merely because it is set to Always.

For an Ask request, review the title, consequence, and input summary, then
choose **Deny once** or **Allow once**. Managers can remember Always or Never for
the Persona or Workspace default. The policy must save before the pending call
continues.

## Stability

### Portal remains available

Parable Portal is the default text route. Disabling or removing the last usable
text entry visibly restores Portal, and server-side resolution enforces the
same invariant for saved and private configurations.

If an earlier model cannot serve the request, Ponder can try the next approved
entry with that entry's own Configuration and allowed providers. Portal's
built-in alternatives use Portal's settings; other ranked entries keep their own.
A missing eligible zero-data-retention endpoint does not remove the Portal fallback. Every attempt retains the same
privacy requirements; fallback never permits data collection or weaker access.

A provider outage can still prevent a response. Once output or a tool effect has
committed, Ponder does not switch models and replay the work. Approval
continuation retains the accepted model and configuration; changed instructions
or revoked authority require a new Message instead of silently changing the
response being approved.

### Keep existing work intact

Pocket a Persona when it should not be chosen for new work, and restore it when
needed. Existing Messages retain their accepted history. Built-in Personas
remain stable defaults and cannot be deleted like custom Personas.

A Persona's Pet association is visual only. It does not adopt a Pet, change
instructions, or affect models and access. See [Pets](/ponder/pets) for personal
companions.

## Simplicity

One Persona owns one prompt and one permission policy. Each of its three
profiles owns its rankings, and each ranked entry owns its text settings.
Private Settings changes stay private until an explicit publication succeeds.

## Reference

Every action on this page is an operation of the Workspace API:

* [List Personas](/protocols/reference/web-api/parable-problem-list-ponder-personas)
* [Create a Persona](/protocols/reference/web-api/parable-problem-create-ponder-persona)
* [Update a Persona](/protocols/reference/web-api/parable-problem-update-ponder-persona)
* [Pocket a Persona](/protocols/reference/web-api/parable-problem-pocket-ponder-persona)
* [Take a Persona out of the Pocket](/protocols/reference/web-api/parable-problem-restore-ponder-persona)
* [Choose which Persona to use](/protocols/reference/web-api/parable-problem-set-ponder-persona-selection)
* [Pin a Persona to a Problem](/protocols/reference/web-api/parable-problem-assign-parable-problem-persona)
