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

A persona definition includes:

​
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

Once registered, the planner can assign custom roles like 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.