Skip to main content

Personas

Sources

Docs: Ponder Primer, Powers. 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: 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 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 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:
Provider-specific options retain the provider’s own vocabulary. For example:
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:
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. 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 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: