Plugins & Personas

Personas

A persona is not just a system prompt. It's a system prompt plus a dedicated mind and memory system that grows organically as you use it.

When a persona is active, every fact the agent learns, every decision it makes, and every pattern it recognizes gets stored under that persona's identity. In future sessions with the same persona, those facts are recalled — the persona remembers what it learned. This is the difference between a prompt template and a living cognitive profile.

Usage

# Activate a persona
/persona architect

# Deactivate
/persona off

# The agent shows the active route and persona in metadata:
# provider:model · provider · grade B · ⌘ architect

What Personas Control

• System prompt — base instructions and cognitive style
• Memory namespace — facts stored under the persona's identity
• Badge — visual identifier in the TUI and meta tags
• Preferred tools — which tools the persona tends to reach for

Tones

Tones adjust the agent's communication style without changing its capabilities or memory. They're lighter than personas — no dedicated memory, just a style overlay.

/tone concise    # Terse, minimal explanations
/tone teaching   # Explains reasoning, suggests learning paths
/tone off        # Default communication style

Plugin Registry

The plugin registry manages active persona, tone, and memory layers. It's responsible for:

• Loading and validating persona definitions
• Merging persona system prompts with the base Lex Imperialis (core system prompt)
• Routing memory operations to the correct namespace
• Showing persona/tone state changes as toast notifications

Trust dynamic plugin code

Persona and tone data remain non-executable. Plugins that evaluate Pkl, run scripts or OCI tools, call HTTP endpoints, or connect MCP servers require a separate trusted-code entry before evaluation or connection. Installation, activation markers, extension selection, and trusted directories do not grant this authority.

Shipped content packs

Shipped personas, tones, prompts, skills, workflows, and catalog data use the independently versioned omegon-shipped content pack. Omegon validates its identity, version, digest, provenance, compatibility, and content-only capability requests before inventory. The current standalone persona, tone, and workflow categories can be empty.

The process pins one content generation at boot. Replacing the pack changes new processes without rebuilding Omegon and cannot alter active sessions. Pack residency never activates a persona or tone and never grants prompt, tool, effect, executable, or path authority. If the pack is unavailable, Omegon retains its six constitutional host axioms, omits optional extension and tool guidance, and disables model-driven session compaction locally.

{
  "permissions": {
    "trustedContributionCode": [
      "plugin:my-plugin",
      "mcp:project",
      "mcp:acp-client"
    ]
  }
}

Plugin IDs use the plugin directory name. mcp:project admits the frozen server set from .omegon/mcp.toml;mcp:acp-client separately admits MCP servers supplied by an ACP client. The host binds each admission to the current plugin snapshot or MCP configuration digest. The stable profile grant survives updates, so changed bytes still require operator review. No currently supported dynamic plugin or MCP path supplies verified confinement.

Plugin and MCP lifecycle

Plugin and MCP discovery joins the same metadata-only candidate inventory as native extensions. Discovery captures stable identity and source digest without evaluating Pkl, starting scripts or containers, connecting HTTP or MCP, resolving secrets, or publishing registrations. Trust admission must succeed before the existing transport adapter probes.

• MCP uses one per-server deadline for connection, required tool discovery, and optional resource, template, and prompt discovery.
• Slice 2 does not automatically restart MCP services; MCP and remote-service cleanup is reported as best effort.
• Armory context, script, and OCI processes are bounded, and owned process groups are killed and reaped on timeout or cancellation.
• HTTP plugin failures degrade locally rather than claiming strict cleanup.
• A failed candidate cannot replace the prior accepted graph. One generation owner performs rollback and shutdown for native, MCP, and manifest adapters. /status reports the active composition, contribution health, cleanup assurance, coded diagnostics, and compatibility parity.

Quarantine prevents ordinary activation or silent respawn; it does not mean the code ran in a sandbox.

MCP HostActions

MCP result metadata may propose declarative HostActions, but the server does not execute host effects by declaration alone. Omegon requires the dispatching MCP tool's live parent lease, verifies that requested effects fit within it, and consumes each child identity once. Manual approval is only one gate and cannot widen project policy, runtime policy, or origin trust. A lease-less or over-broad action fails closed.

Dynamic tool inventory

Tool visibility is assembled at runtime from core tools, enabled capability groups, extensions, project configuration, persona policy, and the current provider surface. The running inventory—not a fixed documentation list—is authoritative.

• Use manage_tools to list, enable, or disable situational capability groups.
• Use /profile and /settings to inspect operator-selected runtime defaults.
• Project and persona policy can narrow tool availability; enabling a group does not bypass permissions.