Personas

A persona gives a workflow step a specialized identity — a role, a goal, and a backstory that gets injected into the LLM's system prompt when that step runs. The result is more domain-appropriate output: a legal_advisor step reasons like counsel; a researcher step behaves like an analyst. This is MeghaOS's take on role-based agents.

Anatomy of a persona

Defined in as an a persona:

AgentPersona(
 name="legal_advisor",
 role="Corporate Legal Counsel",
 goal="Protect the company from legal risk",
 backstory="You are a senior corporate attorney …", # injected into the system prompt
)

How personas are used

1. During decomposition, the planner sees the available personas (describe_for_planner) and tags each step with one.
2. When the workflow engine runs that step, it injects the persona's role + goal + backstory into the system prompt.
3. The step's output reflects that expertise.

The orchestrator maps common step kinds to built-in roles — researcher, writer, coder, analyst, coordinator — and you can register richer domain personas like legal_advisor in the registry.

Registering your own

from persona_registry import persona_registry, AgentPersona

persona_registry.register(AgentPersona(
 name="growth_marketer",
 role="Head of Growth",
 goal="Maximize qualified signups",
 backstory="You are a data-driven growth marketer who…",
))

Once registered, the planner can assign growth_marketer to relevant steps automatically.

Plugins as personas

A plugin can also declare a persona_name (see the Plugin interface) so that whenever its tools run inside a workflow, the matching persona's backstory is applied — tying a capability to a voice.

Delegation

A step can hand work to another role mid-flight using action="DELEGATE_TASK" with { "target_persona": "...", "action": "...", "args": {} } — letting, e.g., a coordinator pass a sub-task to a researcher. This is what turns a flat plan into something closer to a team of collaborating agents.