The AI Agent Prompt Pack: 15 Prompts for Agents

I'm considering building an AI agent to handle [describe the task or workflow].

Analyze whether this task is a good fit for an agentic approach by evaluating it against these dimensions:

1. Task horizon: Is this a single-step task or does it require multiple sequential decisions where later steps depend on earlier outputs?
2. Tool dependency: Does completing this task require calling external tools, APIs, or data sources mid-execution?
3. Ambiguity tolerance: How much does the task require judgment calls that a deterministic script cannot handle?
4. Failure cost: If the agent makes a wrong decision mid-task, what breaks and how hard is it to recover?
5. Human-in-loop feasibility: Is a human available to check intermediate steps, or does this need to run fully autonomously?

Based on your analysis, give me a recommendation: full agent, partial agent (with human checkpoints), or deterministic automation. Explain your reasoning for each dimension.

Context:
- Task: [describe it]
- Users: [who runs this task today]
- Volume: [how often this task happens]
- Current solution: [how it works now, even if manually]

I'm designing an AI agent that will [describe the agent's purpose and the steps it takes].

Run a failure mode analysis on this design. For each failure mode, give me:
- What goes wrong
- At what point in the task it likely fails
- How likely it is (high / medium / low) given the task structure
- Whether it's recoverable or catastrophic
- A design change that would reduce or eliminate the risk

Cover at least these categories:
1. Tool call failures (the agent calls an API that returns an error or unexpected format)
2. Context drift (the agent loses track of the original goal mid-task)
3. Hallucinated actions (the agent takes a step that seemed logical but was never valid)
4. Loop and retry storms (the agent gets stuck in a retry pattern that wastes tokens or breaks downstream systems)
5. Permission and scope creep (the agent takes actions outside its intended scope)
6. User intent misread (the task was ambiguous and the agent solved the wrong problem)

Agent design so far:
[Paste your current design, even if rough]

I need to decide whether to build a custom AI agent, use an existing agent framework, or stitch together specialized tools for the following use case:

Use case: [describe it]
Team size and AI expertise: [describe your team]
Timeline: [when does this need to be in production]
Scalability requirements: [expected load, number of concurrent tasks]
Data sensitivity: [what data will the agent touch, any compliance constraints]

For each of these three paths, give me:
1. What it looks like in practice for my use case
2. The 2-3 biggest advantages
3. The 2-3 biggest risks or hidden costs
4. When this path breaks down or becomes the wrong choice

Then give me a recommendation with your reasoning. Don't hedge. Pick one and explain why the others lose for my specific situation.

Help me write a minimal agent specification for the following task. This is NOT a system prompt. It's a one-page design document I'll use to align my team before we start building.

The spec should include:
1. Agent name and one-sentence purpose
2. Trigger: what starts the agent running
3. Inputs: what information the agent receives at start
4. Tools available: what APIs, databases, or functions the agent can call (list them)
5. Decision points: where the agent makes a judgment call (list each one and what it's deciding)
6. Outputs: what the agent produces or changes in the world when it's done
7. Termination conditions: what causes the agent to stop (success, failure, and edge cases)
8. Human handoff points: where a human should review before the agent proceeds
9. Out of scope: explicitly, what this agent will NOT do

Task: [describe it]
Available tools/APIs: [list what you have]
Constraints: [budget, latency, compliance, user-facing vs. background]

Review the following tool definitions I'm passing to my AI agent and identify every way they could cause the agent to misuse them or fail.

For each tool, evaluate:
1. Is the name clear enough that the agent will call it at the right time (not too broad, not too narrow)?
2. Is the description precise enough to prevent misuse?
3. Are the parameters well-typed and described?
4. Are error states documented so the agent knows what to do when the tool fails?
5. Is the output format specified clearly enough that the agent can parse it reliably?

Then rewrite each tool definition to fix the issues you found. Keep the same underlying functionality. Only improve the clarity and safety of the definition.

My tool definitions:
[Paste your tool schemas or descriptions]

Audit the following agent system prompt for these specific failure risks:

1. Ambiguous scope: Does the prompt leave it unclear what the agent should do when it encounters an edge case?
2. Missing refusal conditions: Are there situations where the agent should stop and ask a human rather than proceed, and does the prompt specify them?
3. Persona drift: Does the prompt establish the agent's identity clearly enough that it won't start acting like a general assistant?
4. Over-instruction: Are there instructions that conflict with each other or that the agent might follow too literally in edge cases?
5. Under-instruction: What obvious situations does the prompt fail to cover?
6. Tone and escalation: Does the prompt tell the agent how to communicate when it's uncertain or when something goes wrong?

After your audit, rewrite the system prompt to address every issue you found. Flag any changes you made with a [CHANGED] marker so I can review them.

Current system prompt:
[Paste it]

Agent purpose: [one sentence]
User context: [who talks to or triggers this agent]

I need to break the following complex task into a sequence of smaller sub-tasks that a multi-step agent (or multiple specialized agents) can handle reliably.

For each sub-task in your decomposition:
1. Give it a name and one-sentence description
2. Define its input (what it receives from the previous step or from the user)
3. Define its output (what it produces for the next step)
4. Identify whether it needs tool access, and which tools
5. Flag whether a human should review the output before the next step proceeds
6. Estimate the failure risk: low, medium, or high, with one sentence on why

Then draw the overall flow as a numbered sequence with branching points clearly marked (e.g., "If step 3 fails, go to step 3b instead of step 4").

Task to decompose: [describe it in full]
Tools available: [list them]
Acceptable latency per run: [seconds or minutes]
Is this user-facing or background: [specify]

I'm designing an agent that runs [describe the task]. I need to figure out where to put human-in-the-loop checkpoints without making the agent so interrupt-heavy that it's worse than just doing the task manually.

Help me design the oversight model by:
1. Mapping every decision the agent makes during the task
2. Classifying each decision as: reversible/irreversible, high-stakes/low-stakes, and certain/uncertain
3. Recommending a checkpoint policy for each class of decision:
   - Auto-proceed (no human needed)
   - Notify but proceed (log it, human reviews asynchronously)
   - Pause and confirm (agent waits for explicit human approval)
   - Escalate and stop (agent halts and flags for human takeover)
4. Estimating what percentage of runs would require synchronous human input under this policy

Optimize for: [choose one: maximum autonomy / maximum safety / fastest time-to-completion]
Acceptable interruption rate: [e.g., "no more than 1 in 10 runs should require synchronous input"]

Agent task: [describe it]

Write a persona definition for an AI agent that will [describe what it does and who it serves].

The persona definition should include:
1. Name (or role label if no custom name)
2. One-paragraph description of how it talks and what it prioritizes in interactions
3. Five example phrases it would use (and five it would never use)
4. How it handles uncertainty (does it say "I don't know," ask a clarifying question, or offer a best-effort answer with a caveat?)
5. How it handles a user who is frustrated or confused
6. What it does when it cannot complete the task (how does it hand off or explain the failure?)
7. What it explicitly will not do, stated in first person as the agent

Make the persona specific enough that two different engineers building different parts of this agent would produce consistent behavior. Generic descriptions like "helpful and friendly" are not acceptable. Every trait should be concrete and testable.

Product context: [describe your product]
User: [describe who interacts with this agent]
Tone goal: [e.g., "expert but approachable," "direct and efficient," "warm and reassuring"]

I need a concrete evaluation rubric for my AI agent so I can measure whether it's working in production, not just in demos.

The agent does: [describe the task]
It succeeds when: [describe the ideal output or outcome]
It fails when: [describe failure states you've seen or anticipate]

Create an evaluation rubric with:
1. A set of test case categories that covers normal inputs, edge cases, and adversarial inputs (give 3 examples per category)
2. For each test category, a scoring rubric (1-5 or pass/fail, your choice, but explain the criteria)
3. Three metrics I should track in production (not just accuracy, think about task completion rate, fallback rate, latency, etc.)
4. A minimum bar for each metric below which I should stop and fix before continuing rollout
5. A log format I should use to capture agent behavior so I can debug failures after the fact

Make the rubric specific to my use case, not a generic "AI evaluation" template.

Act as a red-teamer trying to make the following AI agent fail, misbehave, or produce harmful outputs.

Your job is to generate 15 test inputs specifically designed to break this agent. Organize them into:
1. Boundary violations (inputs that push the agent to act outside its defined scope)
2. Prompt injection attempts (inputs that try to override the agent's instructions)
3. Ambiguous inputs (inputs with multiple valid interpretations that could lead to wrong actions)
4. Adversarial edge cases (rare but valid inputs the agent was probably not designed for)
5. Compounding failures (multi-turn sequences where each step seems fine but the combination causes a problem)

For each test input, describe:
- The input itself
- What a broken agent would do
- What a well-designed agent should do instead
- How severe the failure is (low / medium / high)

Agent description: [describe your agent]
System prompt summary: [paste or summarize it]
Tools available: [list them]

I'm about to ship an AI agent to production. Review the following agent design and give me a go / no-go recommendation with specific blockers.

Evaluate across these dimensions:
1. Safety: Can the agent take actions that are irreversible or destructive? Are those actions gated behind confirmation?
2. Scope: Can an unusual input push the agent outside the job it was designed for?
3. Observability: If this fails at 2am, can I reconstruct what the agent did and why from logs alone?
4. Failure handling: What happens when a tool errors, times out, or returns a shape the agent didn't expect mid-task?
5. Cost and loops: What's the worst-case token spend for a single run, and what stops a retry storm?
6. Human handoff: When the agent gets stuck, does a human find out, and do they have enough context to take over?
7. Rollback: If this goes badly on day one, how do I turn it off, and what half-finished state does that leave behind?

For each dimension, give me a rating (blocker / concern / acceptable) and point to the specific thing in my design that led to that rating. Then give one verdict: go or no-go. If no-go, list only the blockers, ordered by what to fix first. Don't soften it.

Agent design: [paste your spec, system prompt, and tool definitions]
Deployment context: [user-facing or background, expected volume, what systems it touches]

I need to explain an AI agent to a stakeholder who is skeptical of it. Write a one-page brief they can actually interrogate.

The agent: [describe what it does]
The stakeholder: [describe their role and what they're accountable for]
Their specific concern, if I know it: [describe, or say "general discomfort with autonomy"]

The brief should cover:
1. What the agent does, in one sentence, with no AI vocabulary
2. What it is explicitly not allowed to do
3. What happens when it's wrong: who finds out, how fast, and what it costs
4. What a human still controls, and at which points
5. How we'd know it's failing before a customer tells us
6. What we'd do to turn it off, and how long that takes

Rules: no hedging, no "the AI decides" hand-waving, no claims we can't back with a specific mechanism in the design. If a concern is legitimate and unresolved, say so and name it. A brief that admits one real risk earns more trust than one that admits none.

Write the user-facing copy that sets correct expectations for an AI agent in our product.

The agent: [describe what it does]
Where the user encounters it: [describe the surface: chat, background automation, inline suggestion, etc.]
What it does well: [describe]
What it does badly or refuses to do: [be specific and honest]

Produce:
1. One sentence the user reads before they first use it, framing what it's for
2. A short "what this can and can't do" list in plain language, no marketing tone
3. The message the agent shows when it's uncertain
4. The message it shows when it can't complete the task, including what the user should do next
5. The message it shows when it did something the user may want to undo

Constraints: write for someone who has never thought about how agents work and never will. No jargon. No apologizing. Never imply more capability than the agent has, because every overpromise here becomes a support ticket later.

Our AI agent made a mistake that affected users. Help me communicate it.

What happened: [describe what the agent did]
Who was affected and how: [describe scope and impact]
Why it happened: [describe the root cause, in technical terms]
What we've changed: [describe the fix and any new guardrail]
What we haven't solved yet: [be honest]

Write three versions:
1. For affected users: what happened in their terms, what it means for them, what they should do, and what we've done about it. No jargon, no blaming the model.
2. For internal stakeholders: the same facts with the mechanism explained, plus what class of failure this belongs to and whether it can recur.
3. For the team: the one design assumption this proved wrong.

Rules: never describe the agent as if it acted on its own and surprised us. We designed it, we shipped it, we own the output. Don't promise it will never happen again unless the fix genuinely makes that class of failure impossible. Say what's true.