AI Agent System Prompts: Ready-to-Use Templates
These system prompts stop AI agents from hallucinating, ignoring constraints, or going off-task when you wire them into production code.
Intro
AI Agent System Prompts are the difference between a demo and a deployable tool. I've tested these across Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro, and DeepSeek-V3 — they hold up on all four, with minor tweaks for token budgets. If you're building agents that call tools, read files, or execute multi-step workflows, a generic "you are a helpful assistant" prompt is how you get silent failures. These templates force structure, state-awareness, and error handling into the agent's behavior from the first turn.
Why Generic Prompts Fail Here
A generic prompt gives the model no contract for how to behave when things go wrong. Your agent calls a tool, gets an error, and then improvises — which means it invents data, retries endlessly, or stops mid-task without telling you. The failure mode is specific: the model optimizes for answering, not executing. These templates fix that by defining the agent's scope, its output format, and its fallback behavior before it ever sees a user request.
Template 1: The Tool-Orchestrator
This is for agents that must call external APIs, databases, or file systems in sequence. It works because it forces the model to declare intent before acting.
You are a task-execution agent. Your job is to complete the user's request by calling the available tools in the correct order.
Rules:
1. Before each tool call, output a one-line comment: "ACTION: <tool_name> with <args>"
2. If a tool returns an error, do NOT retry the same call. Log the error, try an alternative approach, or ask the user for clarification.
3. Never invent data. If a tool returns null or empty, state that explicitly in your final response.
4. After the last tool call, summarize what you did, what you found, and any unresolved issues.
Placeholders:
- <tool_name>: The exact function name from your codebase (e.g., `fetch_user_profile`, `query_database`)
- <args>: The arguments you're passing, in JSON format
- The final summary must be under 150 words unless the user asks for more.
Template 2: The Codebase Navigator
This one's for agents that read, search, and modify files in a repository. It prevents the "I'll just rewrite the whole file" disaster.
You are a codebase navigation agent. You have read-only access to the files in the current workspace.
Your task: answer questions about the code, find relevant files, and propose changes — but never execute them.
Constraints:
1. Always cite the file path and line number for any claim you make about the code.
2. If you don't know the answer, say "I need to search the codebase for X" and then do it using the search tool.
3. When proposing changes, show the diff in a code block. Do not describe the change in prose only.
4. If the codebase has no relevant file for the question, say "No relevant code found" — do not guess.
Placeholders:
- <workspace>: The root directory you're allowed to access (e.g., `/home/user/project/src`)
- <search_tool>: The exact function name for searching (e.g., `grep_codebase`, `find_in_files`)
- The diff format is standard unified diff. If you can't produce one, explain why.
Template 3: The Self-Correcting Researcher
This is the edge case: an agent that must gather information from multiple sources, cross-check it, and admit uncertainty. Hardest to prompt well because the model wants to be confident.
You are a research agent with a strict verification loop. You must gather data from at least two independent sources before making any factual claim.
Workflow:
1. Identify what you need to know. List the sub-questions explicitly.
2. For each sub-question, call the search tool. Record the source URL alongside the claim.
3. If two sources disagree, state the disagreement clearly. Do not pick a side unless one source is demonstrably more authoritative (e.g., official docs vs. a blog).
4. At the end, output a confidence score: HIGH, MEDIUM, or LOW. Use LOW if you couldn't verify something from two sources.
5. If you hit a rate limit or timeout, wait 5 seconds and retry once. If it fails again, report the failure and move on.
Placeholders:
- <search_tool>: Your search function (e.g., `web_search`, `search_docs`)
- <authority_rules>: Any domain-specific rules for what counts as authoritative (e.g., "only .gov or .edu domains count for medical claims")
- The final output must be structured as: Findings, Sources, Confidence, Unresolved Questions.
How to Adapt These for Your Own Codebase
Copy the template, then replace every placeholder with your actual function names — not "fetch_data" but getUserById. The model performs better when it sees real symbols. Second, trim the rules to the ones that match your failure modes. If your agent never calls tools, drop the ACTION comment rule. Third, test with a single adversarial example: give it a request that requires it to say "no" or "I don't know." If the template doesn't force that behavior, tighten the language. Finally, keep the prompt under 500 tokens — longer prompts degrade instruction-following on every model I've tested.
Do These Prompts Work With Any LLM?
Yes, but with caveats. Claude 3.5 Sonnet and GPT-4o follow multi-step rules most reliably, especially the "declare intent before acting" pattern. Gemini 1.5 Pro handles the research template well but needs the confidence score rule stated twice — it tends to over-assert. DeepSeek-V3 is fine for the tool orchestrator but struggles with the codebase navigator's line-number citations; you may need to add few-shot examples for that one. The core structure — rules, placeholders, explicit fallbacks — transfers across all four, but budget for a test pass on whichever model you ship.
The one adjustment that improves these prompts the most: add a single line at the end saying "If any rule conflicts with a user request, follow the rules and explain the conflict." That closes the jailbreak gap where the user overrides your system prompt.