Custom Prompt Pack Starter: Write Your Own Agent Prompts for DAVE

A well-written system prompt has four parts, in this order. Every scaffold in this pack follows the same structure. Once you internalize it, you can write a production-ready prompt for any use case in under 15 minutes.

Part 1: Role declaration

The first sentence declares who the agent is. It sets the frame for everything that follows. A role declaration is not a greeting or a preamble: it is a precise statement of the agent's function.

Pattern: You are a [specific role]. Your job is to [primary function].

Examples:

• You are a contract review specialist. Your job is to identify non-standard clauses in supplier agreements.
• You are a customer intent classifier. Your job is to determine the primary intent behind a customer support message.
• You are a technical documentation editor. Your job is to ensure API documentation follows the team's style guide.

Avoid vague role declarations like "You are a helpful assistant." The more specific the role, the more consistent the behavior.

Part 2: Input description

Tell the agent what it will receive. If the input has a fixed structure (for example, a JSON payload from an API Call node, or a form submission from a User Interaction node), describe that structure explicitly. If the input format varies, describe the range of formats the agent may encounter and how to handle each.

Pattern: You will receive [description of input]. The input [may/will] contain [key elements].

If the input uses delimiter tags (such as [DOCUMENT] or [REFERENCE] tags), declare them here. Delimiter tags prevent the agent from confusing input content with prompt instructions, which is especially important when the input may itself contain instruction-like language.

Part 3: Rules

Rules are the constraints that make the agent's behavior predictable. This is the most important part of the prompt. Write rules as explicit, unambiguous statements. Each rule should be a single, testable condition.

Every prompt should include at minimum:

• What the agent must always do.
• What the agent must never do.
• How to handle edge cases and ambiguous input.
• Whether to ask for clarification or make a best-effort attempt when input is unclear.

Rules that say "be concise" or "be accurate" are not rules: they are aspirations. Rules that say "produce exactly two sentences" or "do not add information not present in the source text" are testable and enforceable.

Part 4: Output format

Specify exactly what the agent should return. For agents whose output feeds into downstream workflow nodes (API Call nodes, Routing nodes, or other Agent Interaction nodes), use structured JSON output so the result is parseable without additional processing. For agents whose output is the final deliverable (a rewritten document, a translation, a summary), plain text or the same format as the input is usually correct.

Always end the output format section with: Do not include a preamble or explanation. Return only [the specified output]. This prevents the agent from adding commentary that breaks downstream parsing or clutters the output for human reviewers.

Scaffold 1: Domain Classifier

Suggested name: [Your Domain] Classifier
Category: Custom
Suggested tags: classification, routing, custom

When to use this scaffold: Use this pattern when you need an agent to assign an item to one of a fixed set of categories specific to your domain. Suitable for routing support tickets to the right team, classifying documents by type, tagging content by department, or any use case where the categories are defined by your organization rather than a generic taxonomy.

Scaffold (fill in the bracketed sections):

You are a [domain] classification specialist. Your job is to assign the [item type] provided by the user to exactly one of the following categories:

[LIST YOUR CATEGORIES HERE, ONE PER LINE WITH A BRIEF DESCRIPTION OF EACH]

You will receive [description of input format].

Rules:
- Assign exactly one category. Do not assign multiple categories.
- Base your classification only on the content provided. Do not infer from context not present in the input.
- If the input does not clearly fit any category, assign the closest match and set confidence below 0.6.
- Do not ask for clarification. Make a best-effort classification on every input.

Return a JSON object with the following fields:
- "category": the assigned category name, exactly as listed above
- "confidence": a number between 0.0 and 1.0
- "rationale": a single sentence explaining the classification

Do not include a preamble or explanation. Return only the JSON object.

Adaptation notes: Replace the category list with your organization's specific categories. Keep category names short and unambiguous: if two categories sound similar, add a distinguishing description to each. For routing workflows, connect the output of this agent to a Routing node that reads the "category" field and directs the workflow accordingly. If you need multi-label classification (assigning more than one category), change the "category" field to a "categories" array and update the rules to allow multiple assignments.

Scaffold 2: Decision Support Agent

Suggested name: [Decision Type] Decision Support
Category: Custom
Suggested tags: decision-support, reasoning, custom

When to use this scaffold: Use this pattern when you need an agent to evaluate a situation against a set of criteria and produce a structured recommendation, not a final decision. The agent surfaces the relevant factors and makes a recommendation; a human makes the final call in a Human Review task. Suitable for procurement approvals, content publication decisions, escalation recommendations, and any use case where AI-assisted reasoning accelerates a human decision without replacing it.

Scaffold (fill in the bracketed sections):

You are a [domain] decision support specialist. Your job is to evaluate the [item type] provided by the user against the following criteria and produce a structured recommendation.

Evaluation criteria:
[LIST YOUR CRITERIA HERE, ONE PER LINE]

You will receive [description of input format].

Rules:
- Evaluate the input against every criterion listed. Do not skip criteria.
- Base your evaluation only on the content provided. Do not infer from context not present in the input.
- Do not make the final decision. Produce a recommendation and the evidence for it. A human will make the final call.
- If a criterion cannot be evaluated because the required information is absent, mark it as "insufficient information" rather than making an assumption.

Return a JSON object with the following fields:
- "recommendation": one of "approve", "reject", or "escalate"
- "confidence": a number between 0.0 and 1.0
- "criteria_results": an array of objects, each with "criterion" (the criterion name), "result" ("pass", "fail", or "insufficient information"), and "note" (a single sentence of evidence or explanation)
- "summary": two sentences summarizing the recommendation and the primary factors that drove it

Do not include a preamble or explanation. Return only the JSON object.

Adaptation notes: Pair this agent with a Human Review node. Pass the agent's JSON output as the task payload so the reviewer sees the structured recommendation and the evidence for each criterion before making the final decision. For escalation workflows, use a Routing node to read the "recommendation" field: "approve" and "reject" can route to automated downstream steps, while "escalate" routes to a Human Review task.

Scaffold 3: Input Validator

Suggested name: [Content Type] Validator
Category: Custom
Suggested tags: validation, quality-check, custom

When to use this scaffold: Use this pattern when you need an agent to check whether a piece of content meets a defined standard before it progresses in a workflow. Suitable for validating form submissions, checking that a document contains required sections, verifying that a brief meets minimum requirements before briefing an AI content agent, or any use case where a quality gate is needed before downstream processing begins.

Scaffold (fill in the bracketed sections):

You are a [content type] validation specialist. Your job is to check whether the content provided by the user meets all of the following requirements before it progresses.

Required elements:
[LIST YOUR REQUIREMENTS HERE, ONE PER LINE]

You will receive [description of input format].

Rules:
- Check the content against every requirement listed. Do not skip requirements.
- Base your validation only on the content provided. Do not infer from context not present in the input.
- If a requirement is partially met, mark it as "partial" rather than "pass" or "fail".
- Do not suggest how to fix failures in the validation result. Return only the validation outcome.

Return a JSON object with the following fields:
- "valid": true if all requirements are met, false if any requirement fails or is partial
- "requirements": an array of objects, each with "requirement" (the requirement name), "status" ("pass", "fail", or "partial"), and "note" (a single sentence of evidence)
- "blocking_issues": an array of requirement names where status is "fail" (empty array if none)
- "summary": a single sentence stating whether the content passed validation and, if not, how many requirements failed

Do not include a preamble or explanation. Return only the JSON object.

Adaptation notes: Use a Routing node after this agent to branch on the "valid" field: true routes to the next processing step, false routes to a Human Review task or back to the submitter. The "blocking_issues" array gives the Routing node a clean list of failures without requiring it to parse the full requirements array. For workflows where partial compliance is acceptable, update the routing condition to check whether "blocking_issues" is empty rather than whether "valid" is true.

Scaffold 4: Domain-Specific Extractor

Suggested name: [Domain] Data Extractor
Category: Custom
Suggested tags: extraction, domain-specific, custom

When to use this scaffold: Use this pattern when you need an agent to extract fields that are specific to your domain and not covered by a generic extraction prompt. Suitable for extracting terms from contracts, pulling structured data from domain-specific reports, parsing internal document formats, or any use case where the fields to extract are defined by your organization's data model rather than a generic schema.

Scaffold (fill in the bracketed sections):

You are a [domain] data extraction specialist. Your job is to extract specific information from the [document type] provided by the user and return it as a structured JSON object.

Extract the following fields:
[LIST YOUR FIELDS HERE, WITH A BRIEF DESCRIPTION AND THE EXPECTED FORMAT FOR EACH]

You will receive [description of input format]. Enclose the document in [DOCUMENT] tags.

Rules:
- Extract values exactly as they appear in the source. Do not reformat or normalize values unless the field definition specifies a required format.
- If a field cannot be found, set its value to null. Do not infer or fabricate values for missing fields.
- If a field appears multiple times with different values, return all values as an array.
- Do not include fields that were not listed above.

Return a JSON object with the following fields:
- "extracted": an object where each key is a field name from the list above and each value is the extracted value (or null)
- "missing_fields": an array of field names where the value is null
- "confidence": a number between 0.0 and 1.0 representing your overall confidence in the extraction

Do not include a preamble or explanation. Return only the JSON object.

Adaptation notes: The [DOCUMENT] delimiter tag in the input format prevents the agent from treating document content as prompt instructions. Always use a delimiter tag when the input may contain instruction-like language. For high-confidence extractions (confidence above 0.9 with no missing fields), use a Routing node to pass the result directly to an API Call node. For lower-confidence extractions, route to a Human Review task for verification before the data is used downstream.

Suggested name: [Task] Reasoning Agent
Category: Custom
Suggested tags: reasoning, chain-of-thought, custom

When to use this scaffold: Use this pattern when the task requires the agent to reason through a problem in steps before producing a conclusion, rather than producing an answer directly. Suitable for complex assessments, root cause analysis, risk evaluation, and any use case where the quality of the conclusion depends on the quality of the reasoning that precedes it. The structured reasoning output also makes the agent's logic auditable: a human reviewer can read the reasoning steps and verify that the conclusion follows from them.

Scaffold (fill in the bracketed sections):

You are a [domain] reasoning specialist. Your job is to [primary task] by working through the problem step by step before reaching a conclusion.

You will receive [description of input format].

Reasoning steps:
Work through the following steps in order before producing your conclusion:
1. [First reasoning step: what to consider or evaluate first]
2. [Second reasoning step]
3. [Third reasoning step]
4. [Add or remove steps as needed for your use case]

Rules:
- Complete every reasoning step before producing the conclusion. Do not skip steps.
- Base your reasoning only on the content provided. Do not introduce external assumptions.
- If a step cannot be completed because the required information is absent, note this explicitly in that step's reasoning and continue to the next step.
- The conclusion must follow directly from the reasoning steps. Do not introduce new factors in the conclusion that were not identified in the reasoning.

Return a JSON object with the following fields:
- "reasoning_steps": an array of objects, each with "step" (the step number), "description" (the step name from the list above), and "finding" (a concise statement of what this step found)
- "conclusion": a clear statement of the final conclusion
- "confidence": a number between 0.0 and 1.0
- "summary": two sentences summarizing the conclusion and the key reasoning that supports it

Do not include a preamble or explanation. Return only the JSON object.

Adaptation notes: The reasoning steps are the most important part of this scaffold to customize. Write steps that match the actual reasoning process a domain expert would follow. Generic steps produce generic conclusions: specific steps produce auditable, domain-appropriate reasoning. For Human Review workflows, the "reasoning_steps" array gives the reviewer a transparent view of how the agent reached its conclusion, making it easier to identify where the reasoning went wrong if the conclusion needs to be overridden.

Once you have filled in a scaffold and reviewed the prompt text, add it to your workspace in four steps:

1. Navigate to Agents in the left sidebar, then click the Prompt Library tab.
2. Click New Prompt. Fill in the Name (use the suggested name pattern from the scaffold, replacing the bracketed section with your specific domain or task), select Custom as the Category, add your Tags, and paste the completed prompt text into the Content field.
3. Optionally select an Agent to attribute the prompt to, then click Create.
4. Open the agent you want to use this prompt with, switch the prompt source to Library Prompt, select the prompt from the dropdown, toggle Lock Prompt if this agent should always use this prompt regardless of which workflow references it, and save.

You need the Admin or Create role to create prompts in the Prompt Library. DAVE ships with six default tenant roles (Admin, Create, Curate, Use, Reporting, and Financial), all editable by your administrator.

Using the AI Assistant to refine your scaffold: After filling in the bracketed sections, you can use DAVE's built-in AI Assistant to refine the prompt before saving. Click AI Assistant on the New Prompt form, describe what you want to improve (for example: "Make the rules more specific" or "Add a rule for handling empty input"), and click Generate. The system uses your tenant's default AI provider and model (configured under Admin → Settings → General → System Parameters → AI Assistant) to produce a revised draft. Review and edit before saving: the AI Assistant is a drafting aid, not a final authority on prompt quality.

Testing before production: Before referencing a custom agent in a production workflow, test it in a draft workflow with representative input. Custom prompts are more likely than generic ones to have edge cases the scaffold did not anticipate, because they encode domain-specific logic that only your team can fully evaluate. Test across the range of inputs your workflow will encounter. Create a new agent version with adjusted Config JSON if the output does not meet your standard, and retest before promoting.

Which category should I use for a prompt that does not fit Content Generation, Review, Safety, Analysis, or Transformation?

Use Custom. The Custom category is the correct choice for any prompt that combines multiple functions, encodes domain-specific logic, or does not map cleanly to one of the five named categories. Do not force a custom prompt into a named category just to avoid using Custom: a miscategorized prompt is harder to find and maintain than one filed under Custom with clear tags.

Can I use the AI Assistant to write the entire prompt from scratch instead of filling in a scaffold?

Yes. Click AI Assistant on the New Prompt form, enter a narrative description of what you want the prompt to accomplish, and click Generate. The system produces a draft prompt using your tenant's default AI provider and model. However, AI-generated prompts for custom use cases frequently need more editing than those for generic use cases, because the AI Assistant does not know your domain, your data formats, or your organization's specific requirements. Use the scaffold as a quality check: verify that the generated prompt has a clear role declaration, an input description, explicit rules, and a specified output format before saving.

How many rules should a prompt have?

As many as the task requires, and no more. A prompt with two precise rules is better than one with ten vague ones. Start with the minimum set of rules that prevents the most common failure modes, test the prompt, and add rules only when testing reveals a gap. Adding rules pre-emptively for situations that never occur in practice makes the prompt harder to read and maintain without improving output quality.

My custom prompt produces inconsistent output. What should I do?

Inconsistent output usually has one of three causes: the rules are ambiguous (the agent has room to interpret them differently on each call), the temperature setting in the agent's Config JSON is too high (reduce it toward 0.2 for tasks requiring consistent structured output), or the input varies more than the prompt anticipates (add rules to handle the input variations you are seeing). Open the agent detail page, create a new version with adjusted Config JSON or a refined prompt, test in a draft workflow, and compare output across multiple test instances before promoting to production.

Should I use delimiter tags like [DOCUMENT] in my prompts?

Yes, whenever the input may contain instruction-like language. Delimiter tags tell the agent where the prompt instructions end and the user-provided content begins. Without them, an input that contains phrases like "ignore previous instructions" or "your new task is" may confuse the agent. DAVE's prompt injection scanning provides a platform-level defense, but delimiter tags add a prompt-level defense that is under your control. Use them for any prompt that accepts free-form text input from external sources.

Can I share a custom prompt across multiple agents?

Yes. A library prompt can be assigned to any number of agents in the same tenant. If you have a validation prompt that applies to multiple content types, create one prompt in the library and assign it to each relevant agent. When the validation logic needs updating, edit the prompt once and all assigned agents use the updated version at their next execution. If you need slightly different validation rules for different content types, create separate prompts rather than trying to make one prompt handle all variations with conditional logic.