Profiles¶

Profiles let you configure different reviewer behavior for different agents. A profile targeting coder subagents can use a different model and tool visibility than the profile targeting the main general agent.

Built-in reviewer profiles¶

The adversary setting selects a built-in behavioral template that defines what the reviewer watches for. This is different from the settings profile that contains it - a settings profile controls which model and tools an agent gets, while adversary controls the reviewer's mandate.

`adversary`	Description
`general`	Instruction compliance. The reviewer reads the agent's system prompt and blocks when the agent deviates from it — ignoring its stated rules, skipping required steps, or acting outside its mandate. Does not block opinions, preference questions, or summaries of established work. Default when no `adversary` is set.
`code`	Production-grade code. Blocks changes that skip understanding (no visible investigation before editing), expand scope beyond the task, patch symptoms instead of root causes, ignore production constraints, or claim completion without verification. The reviewer sees Read, Grep, and Glob output to judge whether the agent earned its edits through actual research.
`research`	Evidence-backed advice. Blocks confident recommendations and factual claims not grounded in visible research — web searches, doc lookups, or source inspection. Passes conceptual reasoning, brainstorming, and answers that clearly label their uncertainty.
`prompt`	Lean prompt engineering. When the agent writes prompts for other AI models, blocks verbosity, vague generalities ("be thorough", "ensure quality"), unnecessary examples, incident archaeology, and redundant restatements. Every sentence must impose an actionable constraint or supply context the downstream model cannot infer.
`spec`	Implementable plans. Blocks specs, architecture proposals, and implementation plans that dodge key decisions, hide uncertainty behind confident prose, or ignore obviously affected surfaces. Passes plans that are grounded in the actual codebase and explicit about what remains uncertain.

To use a built-in reviewer, set adversary inside your settings profile. The profile's name is just a label and selects nothing - adversary: code runs the built-in code reviewer no matter what the profile is called. A profile that omits adversary runs general.

Because the label and the reviewer are independent, two differently-tuned profiles can share one reviewer - the same adversary: code with different models, prompts, or tool visibility.

adversary is only meaningful inside a named profile. Setting it in defaults has no effect, because defaults never selects a reviewer. You can layer your own rules on top of any built-in reviewer using system_prompt_mode: append. See Custom Prompts.

How profiles work¶

defaults and profiles accept the same configuration keys. Settings resolve in order: server defaults → defaults → first matching profile. Each layer deep-merges on top of the previous.

defaults:
  model: gpt-5.4

profiles:
  # Off the shelf — adversary: code gives the agent the code review
  # mandate with no extra configuration needed
  code-review:
    agents: [coder, web-dev]
    adversary: code
    model: claude-sonnet-4-6

  # Off the shelf + append — the built-in "spec" reviewer as a base,
  # then a project-specific guardrail appended on top of it
  planner:
    agents: [planner]
    adversary: spec
    system_prompt: |
      Our API contracts are defined in api/schemas/. Block any plan that
      adds or changes an endpoint without referencing the corresponding
      schema file. If no schema exists yet, the plan must include creating
      one as an explicit step.
    system_prompt_mode: append

  # Fully custom — system_prompt replaces the built-in mandate entirely
  # (system_prompt_mode defaults to "replace")
  data-ops:
    agents: [etl-runner]
    adversary: general
    model: gemini-3.1-pro-preview
    system_prompt: |
      This agent processes CSV and Parquet files through our ETL pipeline.
      Block any operation that writes directly to the production database.
      Block any file write outside of the data/staging/ directory.
      Block schema changes to existing tables without a migration file.

The three profiles show the main patterns: using a built-in reviewer as-is, layering project-specific rules on top of a built-in, and writing a fully custom reviewer mandate from scratch.

The `agents` key¶

Each profile requires an agents list to activate. Without it, the profile does nothing.

The agents list contains agent names that this profile should match:

general – the main agent (the default name when no named agent is set)
Any subagent name (e.g., coder, web-dev, research) – Claude Code only
Any named agent launched with claude --agent <name> or, in Codex, zwischen codex <name>

First match wins – if an agent matches multiple profiles, only the first one applies.

Agents with no matching profile are not reviewed¶

There is no catch-all

An agent that matches no profile gets no reviewer at all and runs unmonitored.

Routing happens exclusively through profile agents lists. defaults is pure operational config - model, credentials, tool settings - and never routes an agent to a reviewer. An agents key placed inside defaults is ignored entirely.

So if you want an agent reviewed, it must appear in some profile's agents list. To review your main session, give a profile an agents list containing general:

profiles:
  main:
    agents: [general]
    adversary: general

To confirm what is actually in effect for a session, run /z status - it reports the reviewer and model, so an unmonitored session is visible rather than silent.

What profiles can override¶

A profile can set any key that defaults accepts, plus two that are profile-only:

Key	Effect
`adversary`	Which built-in reviewer this profile runs (profile-only)
`agents`	Which agents this profile matches (profile-only, required)
`model`	Different reviewer model
`api_key`	Different provider credentials (`${ENV_VAR}` reference)
`system_prompt`	Completely custom reviewer prompt
`system_prompt_mode`	`"replace"` (default) or `"append"`
`tools`	Different tool visibility and enforcement
`cycle`	Different context cycling thresholds
`include_claude_md`	Whether to forward CLAUDE.md to this reviewer
`disable_subagents`	Whether this agent is steered away from spawning subagents
`web_search`	Whether this reviewer can use web search
`model_tuning`	Whether to apply provider-specific prompt adjustments

Deep merge behavior¶

For nested dicts like tools and cycle, the merge is key-by-key. A profile that sets tools.output_visible doesn't erase defaults.tools.pre_review.

Exception: system_prompt does not merge. A profile's system_prompt replaces the system prompt entirely – it does not inherit from defaults.system_prompt. The system_prompt_mode key controls whether it replaces or appends to the server profile's prompt, not the defaults prompt.

Example: full profile¶

profiles:
  file-processing:
    agents: [file-processor]
    adversary: code
    model: gemini-3.5-flash
    system_prompt: |
      This agent bulk-renames and reformats files. It should never modify
      file content beyond whitespace and naming conventions. Block any edit
      that changes logic, return values, function signatures, or import
      paths. Block any new file creation — this agent only modifies
      existing files.
    system_prompt_mode: append
    tools:
      review_exempt: [Read, Glob, Grep]
      pre_review: [Bash]
      write_review: [Edit, Write]
    cycle:
      threshold_pct: 0.15

This configures a tightly scoped reviewer for a bulk file-processing subagent: the code built-in reviewer as a base, fast model, appended guardrails specific to the task, most read-only tools exempt from review, but shell commands and file writes still reviewed.