Personas
Role-based agents that give workflow steps specialized expertise.
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:
| Field | Purpose |
|---|---|
name | Identifier the planner assigns to a step |
role | Short title |
goal | What the persona optimizes for |
backstory | Injected into the LLM system prompt to shape behavior |
How personas are used
- During decomposition, the planner sees
the available personas (
describe_for_planner) and tags each step with one. - When the workflow engine runs that step, it injects the persona's role + goal + backstory into the system prompt.
- 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.