Personas

Agent One supports composable personas — specialized agent identities that can be routed to based on channel, user, or message pattern. Each persona has its own system prompt, tool access, and memory namespace.

What is a Persona

A persona defines how the agent behaves in a specific context. Think of it as a role the agent can assume. The default persona is defined in agent.persona in config.yaml. Additional personas are defined under the personas key.

agent:
  name: "Agent One"
  persona: "You are a helpful personal assistant. Be direct and concise."

personas:
  - id: "sales-rep"
    name: "Sales Assistant"
    soul: |
      You are a sales assistant for Cronoss.
      Focus on lead qualification, follow-ups, and CRM updates.
      Always be professional and data-driven.
    tools: ["clickup", "browser_navigate"]
    budget_cap_usd: 0.30

  - id: "code-reviewer"
    name: "Code Reviewer"
    soul: |
      You review pull requests and provide constructive feedback.
      Focus on correctness, readability, and Go best practices.
    tools: ["github"]

The soul field is the persona’s system prompt — its identity and behavior instructions. Keep it under 300 tokens.

Bindings

Bindings route incoming messages to the right persona based on channel, user, or pattern:

bindings:
  - persona: "sales-rep"
    channel: "whatsapp"
    user: "+1234567890"

  - persona: "code-reviewer"
    channel: "telegram"
    pattern: "review PR.*"

  - persona: "default"
    channel: "*"
    user: "*"

Bindings are evaluated in order. The first match wins. A catch-all binding with wildcards (*) ensures the default persona handles unmatched messages.

Binding Fields

Field	Description	Example
`persona`	ID of the persona to activate	`"sales-rep"`
`channel`	Channel to match (`*` for any)	`"whatsapp"`
`user`	User identifier to match (`*` for any)	`"+1234567890"`
`pattern`	Regex pattern on message content	`"review PR.*"`

Agent-as-Tool

Personas can invoke other personas using built-in tools:

agent_send — send a message to another persona and get a response
agent_transfer — hand off the entire conversation to another persona

User: "Can you review the latest PR on cronoss-be?"
Default persona → recognizes code review request
→ Calls agent_send to "code-reviewer" persona
→ Code reviewer processes the request with GitHub tools
→ Response flows back through default persona to the user

Safety Limits

Max depth: 3 — personas can call other personas, but only 3 levels deep
Per-persona budget — each persona has its own budget cap
RBAC gates — persona access is controlled by the user’s role
routes_to whitelist — personas can only invoke listed peers

Memory Scoping

Each persona operates in its own memory namespace. Facts, conversation history, and sessions are scoped per persona. This prevents a sales persona’s context from leaking into code review sessions.

The default persona has access to the global memory namespace. Custom personas are isolated unless explicitly configured to share.

Managing Personas

Personas can be managed through:

config.yaml — define personas and bindings directly
Chat — “Add a new persona for customer support”
Web Portal — CRUD interface for personas with live preview

System-default personas are read-only. User-defined personas can be created, edited, and deleted freely.