Persona Overview

Learn how AI personas in CodeCourier let you configure specialized, reusable agent identities with distinct tools, models, instructions, skills, commands, scripts, and context bindings for every stage of your development workflow.

8 min read
personasai-agentsconfiguration

Personas are one of the most powerful concepts in CodeCourier. A persona is a named, reusable AI agent configuration that defines exactly how an agent behaves when it participates in a workflow run or sandbox session. Each persona specifies the CLI tool to use, the model, the thinking effort level, custom instructions, which skills are available, which commands and scripts are injected, and optionally a bound context document. By creating purpose-built personas, you move from ad-hoc prompting to a systematic, repeatable approach to AI-assisted development.

Why Personas Matter

Without personas, every workflow run starts from a blank slate. You would need to manually specify the model, write system prompts, and configure tools each time. Personas solve this by encapsulating all of those decisions into a reusable identity that can be referenced by name across your project.

Consider a real-world scenario: your team has a coding standard that requires thorough type safety, prefers functional patterns, and always runs ESLint before committing. Instead of repeating these instructions in every prompt, you create a “Senior TypeScript Designer” persona with those rules baked into its instructions. Every workflow that uses this persona inherits the same behavior automatically.

Project-Scoped

Personas are scoped to a project. Each project maintains its own set of personas, which means different projects can have entirely different agent configurations without interfering with each other.

Persona Types

Every persona has a type that determines its role within a workflow pipeline. CodeCourier defines ten persona types, each designed for a specific stage of the development process:

Designer

The primary coding agent. Designers receive a task prompt and implement it directly in the sandbox environment. They write code, create files, install dependencies, and produce the actual deliverable. Most workflows start with a designer step.

Checker

A verdict-based review agent that evaluates the designer’s output. Checkers examine the code changes, run tests if configured, and produce a pass/fail verdict with feedback. When a checker fails the work, the designer can loop back and iterate based on the feedback, creating a design-check loop that improves quality automatically.

Optimizer

A specialized agent focused on refactoring and performance improvement. Optimizers take existing code and enhance it without changing functionality. They look for opportunities to reduce duplication, improve readability, optimize bundle size, and apply best practices.

Prompter

A prompt engineering agent that transforms vague, informal instructions into clear, structured prompts with explicit acceptance criteria. Running a prompter before a designer step can dramatically improve the quality of the resulting implementation by ensuring the designer receives unambiguous instructions.

Investigator

A research agent that thoroughly analyzes the codebase to understand a problem or feature request before any implementation begins. Investigators explore file structures, read existing code, trace dependencies, and produce a summary of findings that subsequent agents can use as context.

Planner

An architecture agent that analyzes codebases and creates structured assessments. The planner reviews the codebase, identifies issues and work items, and produces actionable outputs that can be executed step by step. This type powers CodeCourier’s dedicated issue sessions.

Deep-Dive

An intensive analysis agent designed for complex, multi-faceted problems that require deep codebase understanding. The deep-dive type is similar to the investigator but more thorough in scope - it is typically deployed for architectural analysis, root-cause investigations spanning many subsystems, or cross-cutting concerns where a surface-level scan would miss critical dependencies. Deep-dive sessions generally run longer and at higher thinking effort than standard investigator sessions.

Reviewer

A specialized code review agent focused on security, maintainability, and design patterns. The reviewer differs from the checker in a fundamental way: it does not produce pass/fail verdicts. Instead, it produces detailed, nuanced review feedback - observations, suggestions, concerns, and commendations - that a human or subsequent agent can act on. Use the reviewer type when you want rich qualitative feedback rather than a binary gate.

Custom

A free-form type for personas that don’t fit any of the standard categories. The custom type imposes no structural expectations on the agent’s behavior - it behaves exactly as its instructions, skills, and context dictate. Use this type for highly specialized agents such as documentation writers, migration assistants, changelog generators, or any other role that requires maximum flexibility without conforming to a predefined archetype.

Choosing the Right Type

When in doubt, choose the type that most closely matches your agent’s primary output. If it writes code, use designer. If it analyzes deeply, use deep-diveor investigator. If it produces qualitative review feedback without a verdict, use reviewer. If nothing fits, use custom.

How Personas Relate to Workflows

Workflows in CodeCourier are sequences of steps, and each step can be powered by a persona. The Persona Pipeline workflow type is specifically designed for this: you select a sequence of personas, and each one executes in order within the same sandbox environment. The output of one persona becomes the context for the next.

For example, a persona pipeline might look like:

  1. Investigator persona analyzes the codebase and documents the relevant architecture
  2. Prompter persona rewrites the user’s request into a detailed technical specification
  3. Designer persona implements the feature based on the refined prompt
  4. Checker persona reviews the implementation and either approves or requests changes
  5. Optimizer persona cleans up and refactors the final code

Each step in this pipeline uses a different persona, potentially with a different model, different skill sets, different injected commands and scripts, and different instructions tailored to its role.

How Personas Relate to Sandboxes

When a workflow run executes, each persona step is assigned to a sandbox. The sandbox provides an isolated E2B cloud environment with a full Linux filesystem, internet access, and installed CLI tools. The persona’s configuration determines which CLI tool runs in the sandbox (Claude Code, OpenCode, Codex, or others) and how that tool behaves (model, instructions, skills, commands, scripts, and context).

Run steps in the database track which persona executed each step, enabling per-persona analytics like success rates, average iterations, cost breakdowns, quality scores over time, and activity timelines.

Capabilities

Personas can be configured with:

  • CLI tool selection - Choose between Claude Code, OpenCode, Codex, or other supported tools
  • Model selection - Pick the specific LLM model (e.g., claude-opus-4-6, claude-sonnet-4-6)
  • Thinking effort - Control how much reasoning the model applies (low, medium, high, max)
  • Custom instructions - Free-form text that shapes the agent’s behavior
  • Skill assignment - Choose which skills (domain knowledge packages) are available
  • Command injection - Select shell commands and aliases to inject into the sandbox
  • Script injection - Select executable scripts to inject into the sandbox
  • Context binding - Bind a Context document whose active version is prepended to the sandbox configuration
  • Learning injection - Toggle whether compiled learnings from past runs are injected
  • Enable/disable toggle - Temporarily disable a persona without deleting it

Personas do not control sandbox infrastructure settings like memory, CPU, or timeout - those are configured at the workflow or run level.

Persona Versioning

Personas support a built-in versioning system. Every time you save significant edits to a persona’s configuration or instructions, a new version is created rather than overwriting the previous one. Each version record carries a version number, a parentPersonaId pointing to the previous version, and an isLatest flag indicating whether it is the currently active version.

This means you can safely iterate on a persona’s instructions and always roll back to an earlier version if a change produces worse results. The version history is visible from the persona detail page, with a diff view for comparing versions side by side.

Active Version

Only the version with isLatest: true is used in new workflow runs. Older versions are preserved for audit purposes and rollback, but they do not participate in new sessions unless promoted to latest.

Next Steps