A system prompt is the complete instruction set that the model evaluates when an AgentFlow agent starts. System prompts are limited to a maximum length of 100,000 characters, including spaces. These guidelines are intended for developers and prompt engineers who build and maintain AI agents for Reltio AgentFlow. They cover recommended structure, agent-type patterns, safety guardrails, and common mistakes to avoid.

For more information about how to create and publish an agent once a system prompt is ready, see Create, test, and submit an agent for review.

Golden rules

We recommend following these five rules for every system prompt, regardless of agent type:

Recommended prompt structure

We recommend the following structure as the default starting point for production-ready system prompts:

Section 1 — Identity

The identity section establishes a clear persona and boundaries for the agent. It defines who the agent is, what it can do, and — critically — what it cannot do. Explicit limitations prevent the agent from attempting actions outside its design.

We recommend this pattern:

• You are the [Agent Name] in Reltio AgentFlow. Your purpose is to [primary mission in one clear sentence].
• You [capability 1], [capability 2], and [capability 3].
• You do not [explicit limitation 1] or [explicit limitation 2].

Section 2 — Objectives

The objectives section defines what the agent accomplishes, expressed as specific and measurable outcomes. Each objective should state a concrete action and its deliverable.

Section 3 — First-turn behavior

The first-turn section defines how the agent handles the user's opening message. The logic must branch on whether the request is clear:

• If the user provides a clear request, address it immediately and proceed to the relevant workflow step.
• If no clear request is provided, make a silent call to the relevant stats tool if needed, display a welcome message with capabilities, and present actionable options.

Section 4 — Tone, style, and formatting

The tone and style section defines how the agent communicates. We recommend the following for all agents:

• Always respond in well-structured Markdown — use headings, bullet lists, and tables.
• Be concise — for example, "Sure — here's the profile" rather than "Great question! I'd be happy to help".
• No flattery — avoid "Great question!", "Excellent choice!", and similar phrases.
• Cite tools in backticks when mentioning them.
• Ask clarifying questions when the request is ambiguous.
• Use tables for comparisons and multi-item displays.
• Use visual indicators — ✅ success, ⚠️ warning, ❌ error.

Section 5 — Tools

The tools section documents every tool available to the agent with clear selection criteria. Tools must be organized into tables by category — data retrieval, data modification, and utility. Each table must specify the tool name, its purpose, its parameters, and the condition under which it must be used. For data modification tools, the table must also state whether confirmation is required before execution.

In addition to the tables, include explicit tool selection rules that tell the agent exactly which tool to use under which condition. Vague instructions such as "use the appropriate tool" are an anti-pattern — for more information, see Anti-patterns.

Section 6 — Workflow

The workflow section defines the agent's execution steps as a numbered sequence. Each step should include four elements:

• Trigger — when this step executes.
• Action — what to do.
• Output — the expected result.
• Next — the transition rule to the following step.

Section 7 — Guardrails

The guardrails section defines the agent's safety boundaries. We recommend including three elements: a confirmation matrix, operational limits, and a list of prohibited actions.

Confirmation matrix

Recommended operational limits

• Batch size — Maximum 100 items per operation.
• Result display — Default 10 items; offer pagination.
• "Process all" requests — Always estimate count first; warn the user if the count exceeds 1,000 before proceeding.

Recommended prohibited actions

• Never modify data without explicit user confirmation.
• Never expose PII unless the security context permits.
• Never call tools not listed in the Available Tools section.

Section 8 — Output format and the Tools Used section

The output format section defines how every agent response must be structured. Every response must end with a Tools Used section that lists each tool called in backticks alongside the key parameter values used. This section provides transparency and supports auditability of agent actions.

Recommended response structure:

• [Answer or result]
• [Summary of actions taken]
• Next Steps: [suggested action 1], [suggested action 2]
• Tools Used: tool_name — {parameter: "value", ...}

Section 9 — Error handling

The error handling section classifies failures into four types and defines a response pattern for each. The agent must always suggest a next action after any error.

Section 10 — Internal logic (optional)

The internal logic section is optional. It contains hidden decision algorithms for agents that require deterministic computation as part of their workflow.

Agent-type starting points

The recommended ten-section structure applies to all agent types. The following starting points adapt that structure to common behavioral patterns.

Read-only agent

A read-only agent retrieves, summarizes, and explains data. It never modifies data. The identity section should state that the agent's sole purpose is to retrieve, summarize, and explain data — never to modify it. The tools section should list only retrieval tools. Any request to write, merge, unmerge, delete, or create data should be refused with: "Sorry, this agent is read-only. I can only help you explore and understand data."

Batch processing agent

A batch processing agent operates on large sets of records. The guardrails section should include an estimation step before processing any "process all" request: get the count first; if it exceeds 1,000, warn the user and require explicit confirmation; display the execution plan before acting.

Interactive decision agent

An interactive decision agent guides users through a structured decision process. We recommend a four-step workflow:

• Step 1 — Context gathering: The agent asks clarifying questions to resolve the candidate set and validate inputs.
• Step 2 — Analysis and recommendation: The agent presents findings and a data-driven recommendation.
• Step 3 — Confirmation and execution: The agent presents options and waits for the user's selection before acting.
• Step 4 — Post-action: The agent logs the decision, displays results, and suggests next steps.

Anti-patterns

The following patterns produce unreliable agent behavior and should not appear in production prompts:

Quality checklist

Before submitting a system prompt for publish review, confirm the following.

Structure

• System prompt is within the 100,000 character limit, including spaces.
• Role and identity are clearly defined in 2–4 sentences.
• Objectives are specific and measurable.
• First-turn behavior handles both clear and unclear requests.
• All available tools are documented with usage criteria.
• Workflow has numbered steps with decision points.
• Guardrails define confirmation requirements.
• Output format guidance is present.
• Error handling covers user input, permission, and service errors.

Content quality

• No ambiguous terms such as "appropriate" or "relevant" appear without definition.
• No flattery phrases appear.
• Active voice is used throughout.
• Examples are provided for complex behaviors.

Safety

• Destructive actions require confirmation.
• Operational limits are defined for batch operations.
• Prohibited actions are explicitly listed.
• PII handling rules are specified.

For more information about how to publish an agent after the prompt passes this checklist, see Create, test, and submit an agent for review.