Styles and personas

A style is a named set of settings for an agent’s turn: which harness runs it, which model it uses, how hard it thinks, which persona it speaks as and how the harness approves its actions. A persona is a named prompt that the agent receives with the step’s own prompt. A style picks a persona with its persona key.

Styles cascade like CSS. The workflow sets a base style for every step, a group adds its own for the steps inside it, a step names its own, and a key set on the step itself beats them all. Each setting is decided on its own, so a step that changes only its effort keeps the model it would have had.

[styles.careful_review]
extends = "reviewer"
effort = "max"
codex.sandbox_mode = "read-only"

The same name means the same thing on every step that uses it. Change the style called reviewer, and every step that uses it changes.

What a style holds

Key	What it sets
extends	One style this one starts from.
harness	The harness that runs the turn: claude, codex, opencode or pi.
model	The model the harness uses.
effort	How hard the model thinks: minimal, low, medium, high, xhigh, max or ultra. Each harness accepts only some of them.
connection	The connection the harness routes the turn through.
provider	The model provider. OpenCode only.
persona	A persona name from Settings > Personas. "" means no persona.
permissions	How the harness approves the agent’s actions: auto-accept, the default, or full. See permissions.

A style can also hold a sub-table for each harness: claude.model, claude.effort and claude.setting_sources; codex.model, codex.effort, codex.sandbox_mode and codex.approval_policy; opencode.model, opencode.connection and opencode.provider; pi.model and pi.effort. A plugin harness reads a sub-table of its own name. A sub-table applies only when that harness runs the step, and there it beats the plain key it sits beside. So a style can say effort = "high" for every harness and codex.effort = "medium" for Codex alone.

An agent step takes the same keys, except extends, directly. Style keys and harness-specific keys give every value.

How styles cascade

Orbital decides each setting of a step from the first of these that sets it:

1. the step’s own keys
2. the step’s style
3. the styles of the groups that hold the step, the innermost group first
4. the model picked when the run started, if one was
5. the workflow’s top-level style
6. the run’s preset: the preset the run was started with, or else the preset in use
7. the defaults in Settings > Harnesses

style = "balanced"

[steps.coder]
style = ["implementer", "codex"]

[steps.coder.check]
effort = "low"
prompt = "Run the project's checks and fix what they find."

Here coder.check takes its effort from its own key, low. Its persona comes from implementer and its harness and model from codex, both through the coder group. The workflow’s balanced style sets only effort, which the step already has, so it decides nothing here. An import step counts as a group for the steps it brings in, so its style reaches every imported step that does not choose for itself.

How a step’s settings resolve gives the exact order.

Lists of styles

style takes one name or a list. In a list, later names win, key by key:

[steps.review]
style = ["careful_review", "thorough"]

thorough sets effort = "high", so the step thinks at high even though careful_review says max. It still takes the persona and the Codex sandbox from careful_review, because thorough leaves them alone.

Extend a style

extends names one style to start from. The new style keeps every key of the one it extends and replaces the keys it sets itself. careful_review above is the shipped reviewer with more effort and a read-only sandbox on Codex. A style may extend a style from the app, from a style file or from the same workflow.

Style files

A style file is a TOML file with version = 3 and only [styles.*] tables. A workflow pulls style files in with use, a list of paths relative to the workflow file:

version = 3
entry = "steps.plan"
use = ["shared/team.toml"]

Several workflows can use the same file, so a team keeps its styles in one place.

Orbital builds the styles a workflow can name from four sources. A later source wins, key by key, when two define the same name:

1. the style files in use, in list order
2. the styles of workflows this file imports as steps
3. the workflow’s own [styles]
4. the presets in Settings > Presets

Style files and how styles merge give the details.

Presets: styles saved in Orbital

Settings > Presets holds presets: styles saved in Orbital, which every workflow can name without defining them. A step names a preset with style, just as it names a style its workflow defines. A preset wins over a file style of the same name on every key the app sets. So you can change the shipped reviewer in Settings and every workflow that names it follows.

To change a shipped preset for one workflow only, extend it under a new name in that workflow, as careful_review does, rather than redefining reviewer in the file. Your Settings would win over the file’s copy.

The run’s preset

Every run also has a preset of its own, below everything the workflow sets. Settings > Presets marks one preset as in use. A run started without a preset follows the preset in use, and when you switch the preset in use, those runs move to it at their next turn. Pick a preset on the Start page, or pass style to start_run, to pin a run to that style instead: a later switch does not move it.

The run’s preset fills in what the workflow leaves open. On a fresh install the shipped claude preset is in use, so every step that names no harness runs on Claude Code. Switch the preset in use to codex, and those steps move to Codex at their next turn. A step whose own styles name a harness stays where it is.

When the harness of the preset in use runs out of quota, a banner on Settings > Presets offers to switch the preset in use. Orbital never switches it by itself.

Change, reset and restore styles

Orbital adds the shipped presets on every start and never overwrites one you edited. Reset to default returns an edited shipped preset to Orbital’s version. Deleting a shipped preset hides it until you choose Restore. Settings describes the page.

Personas

A persona says who the agent is. It is a named prompt, such as “You review work you did not write”, that the agent receives along with the step’s own prompt. Personas live in Settings > Personas. A style or a step names one with persona, and persona = "" gives a step no persona even when a style below it names one.

What ships

Orbital ships these presets. Apart from claude and codex, none names a harness or a model, so each runs on whichever harness the run’s preset gives it.

Style	Settings
balanced	effort = "medium"
deep_thinking	effort = "high"
planner	persona = "planner", effort = "high"
implementer	persona = "implementer", effort = "medium"
reviewer	persona = "strict_reviewer", effort = "high"
researcher	persona = "researcher", effort = "medium"
claude	harness = "claude". In use on a fresh install.
codex	harness = "codex"

It also ships these personas:

Persona	Who the agent is
planner	Plans the change before code is touched.
implementer	Makes the planned change and checks it.
strict_reviewer	Reviews others’ work and reports defects.
researcher	Finds things out and cites its sources.
supervisor	Looks after your runs. The Supervisor speaks as it, on the preset in use.

Shipped presets gives each persona’s prompt.

Permissions

permissions decides whether the harness asks before the agent acts. It does not take tools away: a step can use every tool its harness offers. The default is auto-accept. When a harness asks you something, the run shows as Question until you answer. See standings.

To set permissions for a whole workflow, put them in a style and name it in the workflow’s top-level style.

A prompt is not a limit

A prompt that says “do not change files” is a request, and the agent can ignore it. On Codex, codex.sandbox_mode = "read-only" in a style keeps the step from writing.

Claude Code

Setting	What happens
auto-accept	Claude Code’s auto mode approves what it judges safe. Whatever auto mode does not settle, the run asks you as a Question.
full	Claude Code bypasses its permission checks. Nothing is asked.

Codex

Setting	What happens
auto-accept	Codex defaults to workspace-write and on-request: it can change files in the workspace and run sandboxed commands, and decides when to ask for approval to act outside the sandbox. Each approval request appears as a Question for you to approve or decline. Set codex.sandbox_mode and codex.approval_policy to override these defaults.
full	Codex runs with full access and never asks, whatever codex.sandbox_mode and codex.approval_policy say.

Harness-specific keys lists the sandbox modes and approval policies.

OpenCode

Setting	What happens
auto-accept	Every permission OpenCode raises is asked as a Question. Your OpenCode permission settings decide what it raises.
full	Every permission is approved. Nothing is asked.

Shipped workflows

Of the shipped workflows, pursue-goal and port-project use full. The others use auto-accept.

Quick reference

To decide	Where to set it
Settings for every step	style at the top level
Settings for every step in a group	style on the group
Settings for one step	style on the step, or the key itself on the step
Who the agent is	persona
Harness, model and effort	harness, model, effort
A setting for one harness only	claude.*, codex.*, opencode.* or pi.*
Whether the harness asks before it acts	permissions
Styles shared between workflows	use with a style file
Settings for every run that picks no preset	The preset in use, in Settings > Presets

Related

• Give steps a style: a worked example.
• Use different models in one workflow: styles on several harnesses.
• Workflow file: every style key and the exact resolution order.
• Settings: the Presets and Personas pages.