Applied prompting on business tasks

What you'll learn

• Combine several instructions, including conditional ones, into one prompt whose outputs agree.
• Explain what delimiters do for a prompt, and what they cannot guarantee.
• Refine a prompt in stages: structure first, then length and focus.
• Design an output contract that code parses, validates and routes, with a fallback to a person.

Lessons 1 to 3 of T3.1 built single patterns and compared models on them. A production prompt usually combines several patterns and feeds its reply to code, not to a reader.

Picture the Larkspur support inbox. A ticket in Portuguese says a server stopped responding. A prompt detects the language, picks a category, translates the ticket and drafts a reply. The model returns a reply with one field misspelt and the category written as a sentence. The code that routes tickets reads the category, finds no match and drops the ticket into a default queue, where it waits a day (illustrative). Nothing was wrong with the patterns. Nothing checked the reply.

Notebook 04a works through five business tasks with the patterns from lessons 1 and 2 of T3.1. This page follows the techniques each task adds, then the contract and validation the notebook leaves out.

Notebook 04a sends each task to gpt-4o and to Llama 3.2 90B on Groq, both at temperature 0. Each task adds one technique that a production prompt needs:

Table 1: The five tasks and what each adds.

Several instructions, one pass

The review prompt asks for a summary of at most 3 lines, the positives and negatives, the overall sentiment, 3 to 5 emotions, and a reply email. The email instruction is conditional: thank the customer if the sentiment is positive or neutral, apologise if it is negative. One call returns every field, and the fields agree with each other because the model wrote them together. A separate call for the email could thank a customer the sentiment call marked as negative.

Delimiters around the input

The tasks with an input wrap it in delimiters, triple backticks in most and triple quotes for the IT tickets. A delimiter marks where the text to work on starts and ends, and the model can tell the instruction from the review or ticket it applies to. Delimiters make an instruction hidden in a review easier to ignore; they do not guarantee it.

The IT ticket prompt also shows a small mismatch: its instruction says the message is in triple backticks, while the message sits inside triple quotes. A prompt should name the delimiter it uses.

One source, several audiences

The same paper abstract on ethics in generative AI for healthcare goes through three prompts. Each keeps the persona, Act as a Artificial Intelligence Expert, and changes only the target line:

Table 2: One abstract, three readers. The persona is constant.

Version 3 is a directional stimulus from lesson 1 of T3.1: the three data types tell the model how to organise the summary.

Refinement in steps

The phone advert goes through three versions, each fixing one thing:

Figure 1: Refine structure first, then length and focus.

Version 2 fixes the layout: a product name, a description, and a two-column Feature and Specification table with exact numbers where they exist, focused on the foldable display, processing power, RAM, camera and battery. Version 3 fixes the length and focus: at most 60 words on the display and camera. Changing one thing per version makes it clear which instruction caused which change in the reply.

An output contract

The IT support prompt asks for JSON with six fields:

Table 3: The IT support output contract in notebook 04a.

The six tickets are in Portuguese, Italian, Japanese, Russian (two) and Turkish. One prompt detects the language, classifies, translates and replies in the customer's language. An output contract is this list of named fields the reply must contain, so that code can read the reply without guessing.

Synthetic examples

The last task asks for five positive and five negative movie-review tweets of at most 250 characters, then three positive and three negative laptop reviews of at most 200 words, each with a sentiment and up to three key topics. Generated examples like these can seed a few-shot prompt or a test set, once a person has checked their labels. Unchecked, they bring the model's own mistakes into the examples that later teach it.

Two details in the notebook are worth copying the other way round:

Table 4: Two habits to reverse.

We call the first one the unchecked contract: the prompt asks for structure, and nothing confirms the structure arrived. The second is a silent fallback: a configuration mistake reaches downstream code as if it were a reply.

A production version parses and validates every reply, and fails loudly:

Figure 2: Validate every reply. A failure goes back once with the error message; the retry's reply is checked the same way.

If the retry also fails, the ticket goes to a person, not to the customer. One retry is a deliberate limit: a reply that fails twice usually means the ticket itself is unusual, and a person reads it faster than a loop of model calls.

The same contract triages Larkspur support tickets. The handbook already defines the routing: tickets go to one of three categories, Billing for invoices, refunds and credits; Technical for servers, storage and the API; Security for access and suspected incidents.

1. Fix the category list in the prompt. category must be exactly Billing, Technical or Security, as the few-shot classifier in lesson 1 of T3.1 fixes its labels. Code can route on an exact value; it cannot route on a sentence.
2. Keep the language fields. orig_lang and trans_msg let an English-speaking team read a Portuguese ticket.
3. Ground the draft reply. The response field is filled by the answer step from lesson 3 of T3.1, from the retrieved handbook passages only.
4. Validate before routing. Parse the JSON, check every field is present and the category is one of the three, retry once with the error, and send a second failure to a person.

The Portuguese ticket from the opening now arrives as Technical, with an English translation and a draft that points to the reboot instructions. A reply with a misspelt field fails validation, gets one retry, and reaches a person instead of a default queue.

Key distinction: the prompt asks for a contract; only code enforces it.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• One prompt can carry several instructions, including conditional ones, and return fields that agree because the model wrote them together. Wrap the input in delimiters, and name the delimiter you use.
• Refine a prompt in steps: fix the structure first, then the length and focus. Keep the persona and change the target line to reuse one source for several readers.
• Give structured output a contract with a fixed category list, parse and validate every reply, retry once with the error, and send a second failure to a person.