Design AI support prompts, guidance and task workflows
The short answer
Keep business knowledge, communication guidance, procedures and permissions in separate places, each with its own owner. Give every task entry conditions, required information, allowed tools, saved progress and exit rules. A prompt can guide how the agent behaves, but it cannot enforce who may do what or confirm that an action happened. Your application has to do that.
Give each rule a clear home
Most agents start as one long prompt, and that works until several people need to change it. A single file mixes facts, tone and procedure, so a wording tweak from support can break a refund rule, and nobody can tell who owns which line. Splitting the content by type gives each part an owner and a way to check it.
| Content | Example | Owner and enforcement |
|---|---|---|
| Business fact | The public return window for this product | Knowledge owner; approved source |
| Communication guidance | Use short sentences and avoid promises about estimates | Support lead; model evaluation |
| Procedure | Check order state, explain options and confirm an eligible cancellation | Support and engineering; task state plus tools |
| Permission | This account may cancel this order under these conditions | Application code; server-side checks |
| Handover policy | Transfer a safety complaint to the specialist queue | Support owner; verified assignment and stop rule |
The last column matters most. Facts live in approved sources, so changing the return window means editing one article. Permissions live in code, because the model can be talked out of a written rule but cannot talk its way past a server-side check.
Write a task contract
A task is a procedure the agent follows to get something done, such as canceling an order or changing a delivery address. Write each one down as a short contract. Start with the customer outcome and the business boundary, then list examples that should trigger the task, close examples that should not, and cases where no task applies at all. “Cancel my order” is a request to act. “Can I cancel if it arrives late?” is probably a policy question, and treating it as permission to act would be a mistake.
Next, state which fields the task needs, where each one may come from, which tools it may use and what ends it. The customer’s account identity must come from trusted application context, such as a signed-in session, never from what they type. An order number can come from the customer, but the server still has to check that this account is allowed to touch that order.
Then test overlapping tasks. Decide what happens when one message contains two requests, and whether the agent can pause a task to answer a related question and then pick it up again. Track confirmed steps, pending decisions and fields the customer has since corrected, so the next turn doesn’t restart a completed operation or ask again for something it already has.
Use small, testable guidance
Guidance is the set of instructions about how the agent communicates: tone, wording, when to ask a follow-up question. Give each piece of guidance an audience and a scope. A rule written for refund conversations should not quietly change how the agent handles a technical troubleshooting task. Keep facts out of guidance, so the team can change a policy without editing every example.
Use examples that show a decision, not just a preferred tone. A good pair might show a delivery estimate described as uncertain (“it usually arrives in 3 to 5 days”) next to a confirmed dispatch described as fact (“it was shipped on Tuesday”). Keep a few counterexamples on file, too: a false promise, a repeated question and a claim that an action was completed when there is no record of it.
When two pieces of guidance conflict, define which wins outside the prose where you can, for example with an explicit priority or scope on each rule. Resist adding ever more “always” and “never” statements to a growing prompt. Narrow or remove rules that are no longer needed, and re-test the cases they affected.
Make handover an operation with evidence
Handing a conversation to a person is an action, not a sentence. It needs a destination, a summary, a reason and a confirmed result. The summary should cover the customer’s request, whether their identity was verified, the relevant facts, what has already been done and what is still open. Keep it readable. Pasting the raw tool output into the summary makes the human dig for what matters.
Before the agent tells the customer anything, confirm that the receiving team can see the case and that the agent will stop replying publicly. “I’ve transferred you to our team” is only true once your application has confirmed the transfer. Decide what happens outside business hours and when assignment fails. If the queue is unavailable, send the approved fallback message and raise an alert for your team, rather than leaving the customer waiting on a transfer that never happened.
Measure task selection as well as wording
A well-written reply from the wrong procedure is still a failure, so test which task and guidance the agent picks, not just what it says. Build labeled cases for each task: clear positives, near-misses that should not trigger it, questions where no task applies and messages that overlap two tasks. Record false starts and missed triggers separately, because they have different fixes.
Agree on release rules for critical cases before you run the tests. If “cancellation after dispatch must never start the cancellation task” is a blocking case, a nicer average score cannot outweigh it.
If you support several languages, test intent and task selection in each one, including customers who switch language partway through a task. Good translation alone does not show that the agent respects the same action boundaries in every language.
Ask AI to explain this guide
Build decisions and checks
Use these decisions to turn the worked case into your own implementation. A check is complete only when you have evidence for the stated result.
Separate knowledge, guidance and procedures
Required. One long prompt is hard for teams to review and can apply rules in the wrong context.
Build. Store business facts, communication guidance, handover policy and task instructions as separate content. Define which takes precedence and where each applies. Give the model only the rules relevant to the current case. Keep permission checks in application code.
Check. A policy change has a clear owner and doesn't change an unrelated task. Review catches conflicting instructions.
Define task triggers and boundaries
When it applies. Similar requests can start different procedures, and a broad trigger can pull in unrelated work.
Build. Give each task a purpose, entry conditions, realistic trigger examples and close negative examples. Define the data it needs, the tools it may use, when it ends and when it escalates. When AI helps draft a task, use a schema and a preview.
Check. Before you turn a task on, test near-miss questions, missing data and overlapping tasks. Label positive, near-miss, none-applies and overlapping cases with the task or guidance you expect. Record false starts and missed triggers. Set release rules for critical cases before you run the test.
Keep task progress across turns
When it applies. The agent can repeat a step it already finished or lose a customer's correction.
Build. Track completed checks, collected fields, confirmed results and pending decisions. Define rules for interrupting, resuming, restarting and switching tasks. A procedure should only ask for information it doesn't have yet.
Check. Interrupt a task, correct a field and come back later. Completed actions aren't repeated.
Control tone, clarification and language
Required. Friendly wording doesn't make up for a missing answer or a false promise.
Build. Define tone, answer length, terminology, the claims the agent may make and when it should ask a question. Use examples for chat and for email. Keep important amounts and dates exact. Keep handover and error wording consistent across supported languages.
Check. Check that short replies still include the facts the customer needs to act. Test how the agent asks for clarification on incomplete requests.
Make handover a completed operation
Required. Saying "I've transferred you" doesn't assign a human or stop the bot.
Build. Define who receives the case, what context they need and what happens outside working hours. Record whether the assignment succeeded. Pass along the relevant facts and tool outcomes. Stop AI replies until someone deliberately hands control back.
Check. Confirm the human can see the case and its summary. Test a failed assignment and a human takeover in the middle of a tool call.
Ask AI to apply these decisions
Templates and examples
Every file uses synthetic data. Adapt it to your own policies and test it somewhere safe before it touches customers.
- task-contract.jsonJSON fixture or schema
- handover-template.mdTemplate (Markdown or text)
- selection-cases.jsonJSON fixture or schema
Keep it working
Launch is the start of the work, not the end. These are the recurring jobs this part of the agent needs, and who usually owns them.
| Cadence | Owner | Work |
|---|---|---|
| Monthly | Support lead | Remove duplicate guidance and review contradictions. |
| Weekly | Support lead | Review false starts and missed tasks, and add representative examples. |
| Weekly | Engineering | Review stalled tasks and repeated questions. |
| Weekly | Support lead | Review customer feedback and new policy wording. |
| Daily | Support lead | Review completed transfers, repeated handovers and time to first human response. |
Test your decision
The customer asks, “Could you cancel it if it has not shipped?” Is this immediate permission to execute?
Show the expected decision
Not yet. First confirm which order they mean and check its current state. Then follow the company’s confirmation policy for conditional requests, which usually means stating what will happen and asking the customer to confirm. Never turn an informational or ambiguous question into an irreversible action.
