Personas

A persona defines the identity of an agent — its system prompt, model settings, and tool access. Personas live in the Personas panel on the left side of the Agent editor. The behavior graph is persona-agnostic: the same graph compiles differently depending on which persona is active when you click Generate.

What a Persona Contains

Properties

Properties are named string fields where you write your prompts. Add them in the Personas panel by clicking the + button under a persona. The most common is system_prompt, but you can add as many as you need:

• system_prompt — The main system instruction passed to the model
• context — Background information injected into the conversation
• constraints — Rules or restrictions on the agent's behavior
• output_format — Instructions for how the agent should format responses

Property values support {param} slots. Use the Format Prompt node in your behavior graph to fill slots with runtime values, or use Get Persona Property to read the raw template string.

Accessing Properties from the Graph

The Get Persona Property node on the canvas reads a property by name. Type the property name in the node's text field (e.g. system_prompt) — it must match a property name defined on the active persona. At compile time, Loom looks up that name and embeds the property's value as a string literal in the generated code.

If you rename a property in the Personas panel, update the Get Persona Property nodes to match — the lookup is by exact name.

Managing Personas

In the Personas panel you can:

• Add a new persona (starts with defaults)
• Duplicate an existing persona as a starting point
• Delete a persona (must keep at least one)
• Select a persona — the active persona is highlighted and used for the next Generate

The active persona is saved with your project. When a Server Graph references your Agent project, it shows which persona was active at the time of the last import.

Compiling a Specific Persona

Select the persona you want in the Personas panel, then click Generate. The compiled agent.py has that persona's settings baked in as constants:

SYSTEM_PROMPT = "You are a research assistant..."
MODEL         = "claude-sonnet-4-20250514"  # or "gpt-4o", "gemini-2.0-flash", etc.
MAX_TOKENS    = 2048
TEMPERATURE   = 0.7
TOOLS         = [...]  # filtered by tool whitelist

To produce a different agent, select a different persona and regenerate. The behavior graph stays the same — only the constants change.

Personas vs. Runtime Switching

Personas are a compile-time concept. The generated agent.py contains exactly one persona's settings — there is no runtime persona switching in the generated code. To deploy multiple variants of the same agent as standalone scripts, generate once per persona.

Personas in Server Graphs

The real power of personas comes in Server Graph projects. When you import an Agent project into a Server Graph, each Agent Ref node has a persona selector dropdown. You can import the same agent multiple times — each ref node selecting a different persona.

When the Server Graph generates code, each Agent Ref compiles as a separate agent instance with its own persona settings baked in. A single Agent project with 5 personas becomes 5 independent agents in the server, each with its own system prompt, model, temperature, and tool whitelist. The Gateway routes requests to the appropriate agent based on your orchestration logic.

Tool Whitelist

The tool whitelist controls which tools a persona can access. Tools in your Dispatch Tool node that are not on the active persona's whitelist are excluded from the generated code entirely — they don't appear in the tools array sent to the model and have no handler in the output.

This lets you define all your tools once in the behavior graph and control access per persona. A "restricted" persona might only have read-only tools while an "admin" persona has the full set.