Docs/Concepts/Personality (PETG)

Personality (PETG)

Every Neofir agent is configured as a Personality, not a script. The personality has five required fields and several optional ones. The system prompt is assembled from this JSON at every turn — there is no per-vertical code path.

The five fields

Field	What it does	Example
`role`	The identity the model takes. One short sentence.	"asistent vânzări Neofir"
`environment`	The context the conversations happen in. Who is on the other end and what they typically ask.	"You speak with founders evaluating Neofir. Common questions: capabilities, channels, pricing."
`tone`	Register, rhythm, vocabulary. Long enough to be unambiguous, short enough that the model can hold it.	"Direct, conversational. 2–3 sentences max. Do not repeat documentation verbatim — synthesize."
`goal`	What the agent is trying to achieve in the conversation. Use to bias toward action vs. information.	"Help the visitor decide if Neofir fits. Propose a discovery call when interest is shown."
`guardrails`	What the agent must not do. Array of bullets. The strongest lever you have.	["Never invent pricing.", "Escalate compliance questions to a human."]

Optional fields

welcome_message — first message shown when a user opens the widget.
fallback_message — shown when the LLM fails twice or the request is out of scope.
shortcuts — up to four quick-reply chips. Rendered as buttons in the widget.
example_phrases — user/assistant pairs that calibrate tone. The strongest tool you have for voice consistency.
signature_phrases — phrases the model may use to sound like a brand voice.
escalation_triggers — keywords that should force escalate_to_human.
disclaimers — legal lines appended to specific reply categories.

Why example phrases matter

Prose descriptions of tone ("be friendly but professional") are weakly steered by LLMs. Few-shot examples are the cheapest way to lock in a voice. Three to five examples is the sweet spot — more wastes tokens; fewer leaves the model improvising.

{
  "example_phrases": [
    {"user": "How does it work", "assistant": "Connect a channel, upload your docs, pick a tone. ~15 min."},
    {"user": "How much?", "assistant": "4 plans: 19/45/89/269 EUR. Studio is the default. 14-day trial, no card."},
    {"user": "Is WhatsApp my personal number?", "assistant": "No. You get a dedicated business number through Twilio."}
  ]
}

The model treats this like coaching: "this is the energy and length expected."

How the prompt is built

At every turn the platform assembles the system prompt from the personality JSON. The structure is fixed; the values come from your configuration:

# Personality
You are {role}.

# Environment
{environment}
Channel: {channel}.  Language: {language}.
Available services:
- {service rows from catalog}

# Tone
{tone}
Examples:
User: {ex.user}
You:  {ex.assistant}

# Goal
{goal}

# Response rules
1. Synthesize. Never quote source chunks verbatim.
2. Keep replies short. 2-3 sentences default.
3. Do not repeat phrasing from your previous turn.
4. Propose the next step when the user signals intent.
5. If you do not know, say so once and offer to connect a human.

## Tools you may use
- book_slot: ...
- check_availability: ...
- ...

# Tool error handling
{standard 4-step recovery template}

# Guardrails
- {each guardrail bullet}

# Always-known knowledge
{system-mode RAG chunks, if any}

# Context (from knowledge base)
{retrieved chunks for the current turn}

# Recent history
{last 6 turns formatted role: content}

Today's date: {ISO}
# User message
{current turn}

Editing the personality

Open /dashboard/agent. Each field is a textarea with character counts and inline guidance. Changes save against the org as a single PATCH on the personality JSONB column. The next message uses the updated prompt — no rebuild, no redeploy.

What not to put in personality

Pricing. Put it in Knowledge instead. Personality is for behaviour, not facts.
Catalog rows. Use the services table. Personality should not duplicate the catalog.
Verbose prose. Each field is read every turn. Keep total under ~800 tokens; the model holds the rules better when they are tight.