Prompting Guide for your AI worker

The guide is organized around the four prompting surfaces inside a Darwin worker. Most rules apply across surfaces, but each section is written so you can jump straight to the one you need.

Inside an AI worker there are four sections where we can prompt instructions.

A space where we define global information or instructions for every worker in the workspace. For example: business location, working hours, contact information, and frequently asked questions. All workers in the workspace can use this context to respond.

A space reserved for one specific worker, where we define information, instructions, and personality that only belong to that worker. For example, in a workspace with a sales worker and a post-sales worker, each one needs different prices (products vs. maintenance) and different personalities (persuasive vs. consultative).

Both the IKB and GKB contain the same set of sub-sections.

A space for custom or premade blocks of information in text format that the worker has available as permanent context. The content is fixed as part of the prompt and is available in every stage of every pipeline. It is not a retrieval tool that is only called when needed.

A space where we can load spreadsheets for the worker to use as context. This works as a retrieval tool.

A space where we can load files for the worker to use as context or to send into the conversation.

A space where we can set websites to scrape so the worker can use the result as context. This works as a retrieval tool.

A retrieval tool lets the worker query external data sources for specific information (spreadsheets, PDFs, web scrapes) on an as-needed basis. By retrieving only what is relevant, it optimizes performance and prevents the model’s context window from becoming congested.

A space inside an AI stage on any pipeline where we define the worker’s Objective for that particular stage.

Example: Ask the human for its name, surname and age.

A space inside an AI stage on any pipeline where we define the conditions that, when met, make the worker move to a different stage.

Example: If the human mentioned its name, surname and age.

These principles apply to every prompting surface. Treat them as the default; the rules in later sections refine them for specific contexts.

The model is capable but has no context on our norms, our customers, or how we want things done. The more precisely you describe the destination and the success criteria, the better the result. If a colleague with no context on the task would be confused reading your prompt, the AI will be too.

Describe the outcome you want, not every micro-step to reach it. Reserve absolute language (Always, Never, Must) for true invariants — safety rules, required outputs, or prohibited actions. Use decision rules for everything else.

Explaining the reason behind an instruction makes the model generalize correctly when the conversation drifts from the cases you anticipated. “Never use ellipses” is weaker than “Never use ellipses, because the answer is read aloud by a text-to-speech engine.”

The same concept should always be called by the same name. Pick one term and stick to it across the Objective, the conditions, the IKB, and the GKB. Inconsistency is a top cause of the model interpreting two instructions as different requirements.

The model creates what it sees. Telling it “do not write long sentences” still primes it on long sentences. Tell it what to do first (“Write short, concise sentences”), and only then add the negation if it is still needed.

Modern models follow instructions literally. If a rule should apply broadly, say so (“apply this to every step”, “in every response”, “across every channel”). Implicit generalization is no longer reliable.

If the Objective says “always greet by name” and the GKB says “never greet by name when the conversation is reopened in less than an hour”, the model has to guess which one wins. Either reconcile them in one place, or write an explicit priority rule (“Stage instructions override knowledge-base defaults”).

Objective prompts are read by the model as plain text, but the markdown structure inside them gives the model strong signals about hierarchy and intent. Across every Objective prompt, follow these conventions.

When an Objective has multiple phases or branches, separate them with headings (#, ##, ###). Headings give the model an unambiguous map of the structure and let you nest sub-instructions cleanly.

When you want the assistant to say something verbatim, put it inside a blockquote. This visually separates literal speech from meta-instructions.

“Hello {name}, how can I help you today?”

Use - bullets for sets of items where order does not matter (FAQs, options the human can pick from, things to confirm in any order).

Use 1., 2., 3. when the order of execution matters. Numbering communicates a sequence the model should respect. When a step needs to be broken into sub-steps that also run in order, use a decimal notation under it (1.1, 1.2, 1.3, …) so the hierarchy is explicit.

Example:

Bold and italic styling rarely changes model behavior and adds visual noise. Use headings, lists, and blockquotes for emphasis instead. Reserve bold or italic only when calling out a single critical token in a long paragraph and there is no cleaner alternative.

The Objective tells the worker what to accomplish during a stage. It is the single most influential piece of text in a stage — everything else is context.

Avoid politeness filler like “Please could you…”. Open with the Objective.

“Your Objective is to…”

The system prompt already defines who the Assistant is by combining its name, role, company, and personality. Repeating that framing inside the Objective is redundant and pushes the actual task further down. Open with the task itself, not with an identity statement.

Models pay the most attention to the start and end of a prompt. Place the main command first. If there is a single non-negotiable constraint, repeat it at the end as a closing reminder.

Use “Human” inside the prompt. Not “lead”, not “customer”, not “client”. This keeps vocabulary consistent across the Objective, the conditions, and the knowledge bases.

Use “Assistant” or “AI” to refer to the worker. Not “you” or any other pronoun. Second-person pronouns shift the model’s framing in ways that are hard to predict.

Tell the model what to do in an imperative way.

“Mention X.” “Ask Y.”

Rigid constraints can make the worker loop on the same task. A rigid constraint is one that opens with “Always”, “Only”, or similar absolute words.

Examples to avoid:

“Always ask the human for its name.” “Only mention that we sell cars.”

Use absolutes only for true invariants (safety, required outputs, hard prohibitions).

When something must not happen, mark it with “Never” so the model treats it as a hard limit.

“Never mention X.” “Never ask Y.”

Do not prompt only what the model must not do. First tell it what to do, then add the negation.

If a stage has too much logic, the model will start cutting corners. Split it into multiple stages on the same pipeline so each Objective stays small and self-contained.

If the stage needs a specific sequence, use a numbered list.

A fallback covers the case where the assumption in your instruction does not hold. Without one, the model invents.

Zero-shot fallback (no example, just the rule):

One-shot or few-shot fallback (include an example of the desired style):

‘Hello {name}, how are you doing?’ If you do not know it, greet without calling any name.”

Use few-shot when the desired format, tone, or phrasing is hard to describe in words. Keep examples close to real conversations and cover edge cases.

Objectives and next stage conditions are deeply related: an Objective usually exists to gather the information that a transition condition requires. Anything mentioned in a condition must also be asked for (or be reachable) from the Objective.

Bad example:

Good example:

Models follow instructions literally. If a rule must apply broadly, say so.

The Objective should describe what to do in the stage, not what the business is. Move prices, policies, FAQs, opening hours, and product details into the IKB or GKB. This keeps the Objective short and makes business facts reusable across stages.

Tell the model when the stage is done. Without an explicit success criterion, the model can keep asking follow-up questions or wrap up prematurely.

“The stage is complete when the human has confirmed its name, its email and a preferred date. As soon as all three are present, stop asking follow-up questions.”

Conditions are what makes the worker move from one stage to another. They are evaluated as triggers for transition tools — getting them wrong creates the worst class of bug: the worker silently transitioning to the wrong place, or never transitioning at all.

Each condition should communicate a single purpose in a single short sentence. If a condition needs more than two clauses — chained with “and”, “or”, “but”, or semicolons — split it into separate conditions inside the same group.

This applies to both group types. In an all group, instead of writing one sentence that strings several requirements together with “and”, write each requirement as its own condition — the group itself already means “all of these must be true”. In an any group, instead of writing one sentence that strings several alternatives together with “or”, write each alternative as its own condition — the group itself already means “any of these makes it true”. Letting the group do the work keeps each condition focused on a single fact, which the model can evaluate cleanly instead of collapsing the whole chain into a single fuzzy check.

A sentence with embedded negatives (“…but not if X”; “this is only true after Y”) is the strongest sign that decomposition is needed. The negatives usually belong as their own atomic conditions, or as qualifiers folded into the positive triggers — restating the positive shape often makes the negative redundant.

Same vocabulary as the Objective. Not “lead”, not “customer”, not “client”.

Not “you” or any other pronoun.

Avoid “shared” when talking about what the human said. Use “mentioned”.

“The human mentioned that he/she is interested in…”

Adding “explicitly” tells the model the condition only fires when the trigger is unambiguously present in the message. This is the single most effective lever for reducing false positives.

“If the human explicitly mentioned…”

If two conditions look similar but lead to different stages, the model will guess. Reference condition A inside condition B to expose the difference.

Condition A: “If the human explicitly mentioned its preference is X.” Next stage: Stage A.

Condition B: “If the human explicitly mentioned its preference is Y, which is different from X because of…” Next stage: Stage B.

To trigger a transition based on the return value of a tool, name the tool and describe the value the return contains.

“If the return of the tool indicates X.”

When possible, quote the literal token the return uses so the model does not have to interpret it.

“If the return of the tool explicitly contains the word ‘patient’.”

A dead zone is a value that no condition covers. The model will pick one of the adjacent conditions, usually the wrong one.

What happens at exactly 50? Either include the boundary in one of the two conditions (≥ 50 and < 50) or add a third condition for the equality case. The same applies to dates, ranges, and any other continuous variable.

For numbers, dates, and times use unambiguous comparators (≥, ≤, <, >, =, between X and Y inclusive). Avoid colloquial words like “more than”, “a few”, “soon”, “recently” unless the audit rubric has a definition for them.

Use a new block of information for every new topic, and give each block a descriptive name (Promotions, Location, Contacts, General Rules, etc.). One topic per block keeps the model’s retrieval clean.

If a piece of data is very large (for example a product catalog), it does not belong in a text block. Move it to a catalog (spreadsheet), file, or website where the worker can fetch it via a retrieval tool.

The FAQs section is for question / answer pairs that the worker should reuse verbatim or near-verbatim. Use it only for a 1:1 relationship between a question and an answer. Mixing logic, branching, or long-form policy into FAQs degrades retrieval quality.

Anything that should hold for every worker in the workspace goes in the GKB. Anything that only applies to one worker (its personality, its prices, its scripts) goes in the IKB. This keeps knowledge reusable and avoids one worker’s quirks leaking into another.

If an instruction belongs to one stage’s Objective, leave it there. Putting it in the knowledge base too creates a redundancy that the model will eventually treat as a conflict.

Use these two verbs and quote the tool name.

“Execute the tool .” (where tool_name is the name of the tool) “Call the tool .” (where tool_name is the name of the tool)

If you prompt a tool call inside a stage Objective, that tool must be available in the tools section of that stage. Otherwise the model can hallucinate a call to a tool it does not have.

If you prompt a tool call from the IKB or GKB, that tool must be available in every stage where the worker could reach the prompt. Otherwise the model can hallucinate the call in stages where the tool is missing.

A tool call without a downstream instruction is wasted work. Describe what should happen for each value the tool can return.

“If the return of the tool indicates the human has debt, mention…” “If the return of the tool indicates the human does not have debt, continue with…”

If a tool is expensive, slow, or one-shot (cannot be repeated), state the conditions under which the model should NOT call it. Pair this with the positive trigger from rule 4.

“Call the tool only after the human has confirmed both the date and the location. Never call it before both pieces of information are present, and never call it more than once per conversation.”

Use the @ character as a command to select the file you want the worker to be able to send.