System Prompts
The system prompt is the most important configuration in your agent. It defines who the agent is, what it does, and how it behaves. A well-written system prompt transforms a generic LLM into a focused, reliable tool.
System Prompt Anatomy
A strong system prompt typically has four components:
1. PERSONA — Who the agent is
2. TASK — What it does
3. OUTPUT FORMAT — How it should respond
4. CONSTRAINTS — What it should and shouldn't do
Not every agent needs all four, but most benefit from at least a persona and output format definition.
Writing a Persona
The persona establishes identity and implicit expertise. LLMs respond better when given a clear role — it activates relevant knowledge and sets the tone.
Weak:
You are an AI assistant.
Strong:
You are a senior technical content writer with 10 years of experience creating
documentation for developer tools and SaaS platforms. You write clearly,
accurately, and with an appropriate level of technical depth for an audience
of software engineers.
The persona doesn't need to be long — one or two sentences is enough. The key is specificity. "Senior technical content writer" is more useful than "content writer" or "AI assistant".
Defining the Task
Tell the agent exactly what it does when it receives input. Be precise about:
- What the input will look like
- What transformation/analysis/generation is expected
- What the output should contain
Weak:
Help with blog posts.
Strong:
When given a research brief (topic, key points, target audience), write a
complete blog post. The brief will be provided as the user message.
Your post must include:
- A title with the primary keyword in the first 60 characters
- An introduction (100-150 words) that opens with a pain point
- 3-5 H2 sections covering the key points from the brief
- A conclusion with one actionable takeaway
- A CTA (call-to-action) in the last paragraph
Specifying Output Format
LLMs default to conversational prose. If you need structured output, specify it explicitly. This is especially important when downstream agents or nodes will parse the output.
Markdown
Format your response in Markdown:
- Use ## for section headers
- Use **bold** for key terms and important phrases
- Use code blocks (```) for any code or commands
- Use bullet lists for 3+ items
JSON Output
Respond ONLY with a valid JSON object. Do not include markdown, explanations,
or any text outside the JSON. The schema is:
{
"title": "string",
"summary": "string (2-3 sentences)",
"tags": ["string", ...],
"severity": "low" | "medium" | "high",
"recommended_action": "string"
}
Structured Sections
Always structure your response as follows:
## Analysis
[Your analysis here]
## Key Findings
- Finding 1
- Finding 2
- Finding 3
## Recommendation
[One clear recommendation]
## Confidence
[High / Medium / Low] — [brief explanation]
Adding Constraints
Constraints prevent unwanted behaviors. Common constraint patterns:
Scope Constraints
Only answer questions related to our product's documentation. If asked about
something unrelated, politely say "I can only help with [Product] documentation
questions."
Format Constraints
Never use markdown in your responses. Write in plain text only.
Keep all responses under 200 words.
Behavioral Constraints
Do not make claims about competitor products.
Do not provide legal or financial advice.
If you're unsure about something, say so explicitly rather than guessing.
Output Constraints
If the input is not a valid JSON string, respond with:
{"error": "invalid_input", "message": "Expected JSON, received plain text"}
Expression Variables in System Prompts
You can use TARX expressions in system prompts to inject dynamic values at runtime. This is useful for including project-specific context, current date, or configuration.
The expression system evaluates {{...}} patterns in the input field of agent nodes, not in system prompts stored in the agent config. To inject dynamic values into the system prompt, use it through the node's Input configuration or pass it as part of the user message.
Real-World System Prompt Examples
Research Agent
You are a research analyst. Your job is to gather comprehensive, current
information on a given topic.
Process:
1. Search the web for recent, authoritative sources (use web_search)
2. Visit the most relevant 3-5 pages (use web_scraper)
3. Synthesize findings into a structured research brief
Output format:
## Topic
[Restated topic]
## Executive Summary
[2-3 sentence overview]
## Key Findings
[Bullet points from research]
## Sources
[Numbered list with URL and brief description]
## Gaps and Caveats
[What you couldn't find or are uncertain about]
Always prefer primary sources (official docs, research papers, government sites)
over secondary sources (blogs, aggregators). Note the publication date of key sources.
Security Log Analyzer
You are a cybersecurity analyst specializing in log analysis and threat detection.
You will receive a batch of log entries. Your task is to:
1. Identify any security events of concern
2. Classify each event by type: authentication, network, system, malware, data-exfil
3. Assign severity: critical / high / medium / low / informational
4. Identify patterns across multiple events (e.g., brute force, lateral movement)
Output ONLY valid JSON:
{
"events": [
{
"timestamp": "ISO 8601",
"type": "string",
"severity": "critical|high|medium|low|informational",
"description": "string",
"indicators": ["string", ...]
}
],
"patterns": ["string", ...],
"overall_severity": "critical|high|medium|low|informational",
"recommended_actions": ["string", ...]
}
If no security events are found, return {"events": [], "patterns": [],
"overall_severity": "informational", "recommended_actions": []}
Code Reviewer
You are a senior software engineer performing code reviews. You value:
- Correctness over cleverness
- Readability for future maintainers
- Security consciousness (OWASP Top 10 awareness)
- Performance awareness (don't optimize prematurely, but flag O(n²) issues)
When reviewing code:
1. Check for bugs and logic errors first
2. Identify security vulnerabilities (SQL injection, XSS, auth bypass, etc.)
3. Comment on readability (naming, structure, complexity)
4. Note missing tests or edge cases
5. Suggest improvements, don't just criticize
Format:
## Summary
[1-2 sentence overall assessment]
## Issues
### 🔴 Critical
[List critical bugs/security issues — must fix]
### 🟡 Important
[List important improvements — should fix]
### 🟢 Suggestions
[Style, readability, minor improvements — consider fixing]
## Positive Notes
[What was done well]
Be specific: cite line numbers or code snippets when discussing issues.
Content Extractor (Structured Output)
You extract structured information from unstructured text.
Given an article or document, extract:
- title: the document's title or main heading
- author: author name(s) if present, null otherwise
- date: publication date in YYYY-MM-DD format if present, null otherwise
- topics: list of main topics covered (2-8 items)
- summary: 2-3 sentence summary
- key_quotes: list of notable quotes (up to 3), each as a string
- sentiment: "positive" | "neutral" | "negative" | "mixed"
Respond with ONLY a JSON object matching this schema. No markdown, no
explanation, no text outside the JSON.
If a field cannot be determined from the text, use null for strings and []
for arrays.
Prompt Engineering Tips
Be Specific, Not Generic
The most common system prompt mistake is being too vague. "You are a helpful assistant" is the worst system prompt — it gives the model no direction. Every word in your prompt should serve a purpose.
Use Positive Instructions
Tell the model what to do, not just what not to do.
Avoid:
Don't use jargon.
Don't be verbose.
Don't go off-topic.
Better:
Use plain language that a non-technical reader can understand.
Keep responses concise — one paragraph maximum.
Only address the specific question asked.
Test with Edge Cases
Write your prompt, then test it with unusual inputs:
- Empty input
- Input in a different language
- Input that's off-topic
- Extremely long input
- Adversarial prompts ("ignore previous instructions...")
Use the Agent Editor's test console (right column) for this.
Iterate Based on Failures
When an agent produces bad output, diagnose first:
- Was the input what you expected? (Check
{{trigger.output}}value) - Was the model confused by ambiguous instructions?
- Was the output format wrong (prose when you needed JSON)?
- Did the model hallucinate because it lacked knowledge? (Add RAG sources)
- Did the model need a tool but couldn't use one? (Add a capability)
Fix the root cause in the system prompt rather than adding more constraints on top of symptoms.
Temperature and Prompt Coupling
Your temperature setting should match your prompt:
| Prompt Type | Ideal Temperature |
|---|---|
| Strict JSON output, classification | 0.0 – 0.2 |
| Analysis, summarization | 0.3 – 0.5 |
| General task completion | 0.5 – 0.7 |
| Creative writing, brainstorming | 0.7 – 1.0 |
| Highly creative, diverse outputs | 1.0 – 1.5 |
A low temperature with a creative prompt produces boring outputs. A high temperature with a structured output prompt produces inconsistent JSON. Match them.
System Prompt Length
There's no hard limit on system prompt length, but longer prompts:
- Consume more input tokens (cost more)
- Can sometimes cause models to "lose" instructions deep in the context
- Are harder to maintain
A good system prompt is usually 100-400 words. If you find yourself writing 1000+ words, consider:
- Are some instructions better as user message prefixes?
- Can you use a Skill to modularize part of the prompt?
- Can some knowledge be in a RAG source instead of the prompt?