IX · Routing & CompositionEmerging★

Agent Persona Profile

also known as Agent Profile Object, Persona Configuration, Nexus-Style Profile

Treat agent identity as a structured profile object — persona, primary motivator, allowed actions, knowledge bindings — rather than a free-form role sentence in the system prompt.

Context

A platform hosts many agent variants — customer-support persona, research-assistant persona, coding-partner persona — that share a runtime but differ in role, tone, motivator, allowed tools, and knowledge bindings. Each variant is currently defined by a free-form system prompt the team edits in markdown.

Problem

Free-form persona prompts collapse into a few failure shapes. Versioning is by git diff over prose, which is brittle. Two variants that should share a base persona accidentally diverge as engineers edit each in isolation. Knowledge bindings (which RAG corpus, which tools, which memory partition) live half in code, half in prose, with no single review surface. Swapping personas at runtime requires re-injecting the whole prompt rather than swapping a typed reference.

Forces

  • Personas need to be versionable as structured artifacts, not prose diffs.
  • Shared persona components (motivator, tone) want to be inherited rather than copy-pasted.
  • Knowledge bindings (tools, RAG, memory) should be part of the persona, not adjacent code.
  • Runtime swap of persona must be cheap and unambiguous.

Example

A SaaS product offers three agent personas: a support-rep persona (warm, escalates to humans easily, billing-tools), a sales-rep persona (curious, asks fit questions, CRM-tools), and an internal-staff persona (terse, has admin-tools). All three inherit from a base profile defining tone defaults; each overrides motivator and action set. Switching a tenant from support-only to support+sales is a profile-id change.

Diagram

Solution

Therefore:

Define a Profile schema with fields: persona (role description), primary motivator (what drives this agent), action set (allowed tools), knowledge bindings (RAG sources, memory partitions, vector stores), behaviour parameters (tone, verbosity, model choice). Store profiles as configuration files. The runtime composes the active system prompt from the profile; runtime swap is by profile id. Inheritance: a base profile defines defaults; specialised profiles override fields. Distinct from [[role-prompting]] (one prose sentence) and from [[personality-variant-overlay]] (multiple voices over a single base).

What this pattern forbids. Agent identity must not be defined only by free-form prose in the system prompt; it is captured as a structured profile object the runtime loads as configuration.

And the patterns that stand alongside it, or against it —

  • alternative-toCAMEL Role-Playing·— Have two agents role-play a user-assistant interaction to autonomously complete a task neither could solve alone.
  • complementsPersonality Variant Overlay·— Let one agent speak in several named voices that overlay the base identity rather than replacing it, so the agent can shift register without losing identity continuity or splitting into separate personas.
  • complementsAgent Skills★— Package author-time procedures (markdown + optional resources) the agent loads on demand for specific task types.
  • complementsInner Committee★— Run one model under several distinct personas (executor, critic, planner) within a single agent loop.
  • complementsAgent Factory★— Manufacture agent instances from a versioned template that renders model, tools, and prompt atomically, with registry-backed identities, so a fleet stays consistent and one template change propagates instead of drifting per instance.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in recipes

References

Provenance