Skip to Content
Polyant is open source under AGPL-3.0 — star us on GitHub.
Admin PanelPrompts

Tab: Prompts

The Prompts tab is where the assistant’s system prompt is composed. Polyant splits the system prompt into eight ordered sections, each with a clear job. This modularity exists for two reasons:

  1. Override-friendly. Replacing one section (say, the personality) does not force you to copy-paste the rest.
  2. Reusable across instances. Many production setups share Safety and Tooling sections verbatim and customize only Identity, Soul, and Skills.

At runtime the engine concatenates the eight sections in order to build the full system prompt sent to the LLM, replacing template variables like {{datetime}} and {{skillsList}} along the way.

Layout

The Prompts tab uses a two-column layout:

  • Sticky left sidebar. Lists the eight section keys (01-identity, 02-soul, 03-tooling, 04-safety, 05-skills, 06-memory, 07-user-identity, 08-datetime) in order. Clicking a key scrolls the right pane to that section. The sidebar stays pinned as you scroll.
  • Scrollable right pane. Stacks all eight section editors top-to-bottom in a single scroll surface, so you can read the whole prompt in context or jump between sections via the sidebar.

The eight section identifiers above are the literal keys stored in the instance_prompts table — they are not friendly labels and the UI renders them verbatim.

The eight sections

01 - Identity

Purpose. Tells the assistant who it is, who it works for, and what its scope is. This is the answer the assistant gives when a user asks “who are you?”.

Belongs here. Brand, organization, areas of competence, formal partnerships, persona name.

Example excerpt:

# Identity

You are the customer-support assistant for Acme Corp.
Acme builds collaborative spreadsheets for engineering teams.
Your scope is product questions, billing, and onboarding.
Out-of-scope topics should be escalated to a human.

02 - Soul

Purpose. Personality, tone, communication style, values, conversation-management rules.

Belongs here. Tone register (formal, friendly), verbosity (concise, expansive), structured-output preferences (use tables when listing options), values (accuracy, transparency), turn-management norms (when to ask clarifying questions, how to close a conversation).

Example excerpt:

# Personality

## Tone and style
- Friendly and professional. Drop slang. Avoid hype words.
- Be concise. Lead with the answer; add detail underneath.

## Behavior
- If a request is ambiguous, ask one clarifying question before acting.
- When you do not know something, say so. Never invent facts.

## Closing
- After resolving a request, ask if there is anything else.
- If the user signals they are done, sign off briefly.

03 - Tooling

Purpose. Strategy for using tools — when to delegate, when to parallelize, how to handle errors.

Belongs here. Rules like “check the Skills section before reaching for a generic tool”, “run independent tool calls in parallel”, “never call non-idempotent tools without confirmation”.

Example excerpt:

## Tool Usage Guidelines

- Before using any tool to answer, check the Skills section first.
- If you need to call multiple tools and the calls are independent
  (no data dependencies), run them in parallel in the same turn.
- Do not run dependent tool calls in parallel. Wait for the result
  before issuing the next call.
- Use spawnTask for complex, multi-step research that should not
  pollute the main conversation.

04 - Safety

Purpose. Hard rules the assistant must not break.

Belongs here. No invention of facts, confirmation before destructive actions, redaction rules, escalation paths.

Example excerpt:

# Safety Rules

- Do not invent information. If you do not know, say so.
- Do not perform destructive actions (delete, send, charge) without
  explicit user confirmation.
- Do not expose technical errors, empty tool results, or system
  problems to the user. If a tool fails, ask the user for the
  missing information naturally.

05 - Skills

Purpose. How the assistant discovers and uses skills.

Belongs here. The pattern for selecting a skill from <available_skills>, how to load it (readSkill), how autoLoaded skills behave, constraints (one skill at a time).

This section uses the template variable {{skillsList}}, replaced at runtime with the list of skills enabled for the instance. Do not remove this variable — without it, the assistant cannot see its skills.

Example excerpt (default):

# Skills (mandatory)

Before responding: analyze the <description> entries in
<available_skills>.
- If exactly one skill clearly matches the request: load it by
  calling readSkill with the value of <name>, then follow the
  returned instructions.
- If several skills could match: pick the most specific one,
  then load and follow.
- If none clearly match: do not load any skill.

Skills with autoLoaded="true" are already loaded. Follow their
<content> directly without calling readSkill.

{{skillsList}}

06 - Memory

Purpose. When the assistant should reach into long-term memory and when it should write to it.

Belongs here. Triggers for searchMemory (references to past preferences, decisions, events), triggers for saveMemory (only on explicit user request), reminder that automatic extraction handles the rest.

Example excerpt:

# Memory

## Retrieval
Use searchMemory when the message references past information:
preferences, decisions, events, appointments. Do not search for
greetings or generic questions without historical context.

## Saving
Use saveMemory only when the user explicitly asks ("remember that
...", "save this"). Background extraction handles the rest.

07 - User Identity

Purpose. Information about the specific end user the assistant is talking to. This is dynamic — typically populated at runtime by an update-user-profile tool or by an upstream integration.

Belongs here (default, empty): “No information available about the user.”

Example excerpt (filled at runtime):

# User

Name: Alice Johnson
Role: Engineering manager at Acme
Email: [email protected]
Last seen: 2026-04-29
Preferences: prefers tables over prose, replies in English.

08 - Datetime

Purpose. Anchors the assistant to “now” and the operating timezone.

Belongs here. The {{datetime}} template variable and the timezone declaration. The engine substitutes {{datetime}} with the current ISO timestamp on every request.

Example excerpt:

# Date and Time

Current date and time: {{datetime}}
Timezone: UTC

How the sections are stitched together

When a user message arrives, the supervisor builds the system prompt by:

  1. Loading the eight sections from instance_prompts in order (01-identity first, 08-datetime last).
  2. Replacing {{datetime}} with the current ISO timestamp in the configured timezone.
  3. Replacing {{skillsList}} with <available_skills> XML for every skill enabled on the instance.
  4. Concatenating the result.
  5. Sending it as the system message of the LLM call.

You can preview the rendered prompt by inspecting any conversation in the Conversations screen — the system prompt appears as the first message of the dump.

Cache and TTL

The Prompts tab writes to PostgreSQL. The engine caches prompts in memory for 60 seconds; saves are visible to the next request after the cache expires (or instantly on engine restart). For aggressive iteration, restart the engine to bypass the cache.

Last updated on
Agents (General)Tools