Module 2 Configure a reusable assistant

Time plan: 30 minutes teaching, 25 minutes example, 45 minutes practice and 20 minutes checks. Keep configuration version 1 and your test records. Prerequisite: the Module 1 contract.

What you will be able to do

Turn a service contract into reusable instructions, define a stable output shape and test the assistant in a new conversation. Distinguish a saved configuration from the changing request and from the reference material it uses.

Give each kind of information a home

A reusable assistant has three different inputs. Stable instructions describe the job and its boundaries. Knowledge contains facts that may change, such as policy durations. The current request supplies the particular item and duration being considered. Mixing these together creates maintenance problems. If the webcam limit appears in five different instruction paragraphs, an update can leave one old copy active.

The stable configuration should tell the assistant how to select and cite an approved source, not hard-code every policy detail. The knowledge pack supplies those details. The request must never be allowed to rewrite the stable instructions. A message saying “ignore the desk rules” is content to inspect, not authority to change the workflow. Clear wording helps, but instructions alone are not a security boundary. Restrict connected tools and validate outputs outside the model too.

An output contract defines the fields the next step expects. People can skim prose; an automation needs predictable labels and allowed values. A field called status should not sometimes say “probably fine” and sometimes “approved.” In this course the assistant proposes a draft status. The workflow validates it and determines the final route.

The output contract

Use these fields in this order, as a labelled text record or the same columns in a table:

- request_id and revision: copied from the input without modification.
- draft_status: DRAFT_READY, NEEDS_INFO, HUMAN_REVIEW or INVALID_INPUT.
- reason_code: a short explanation label such as within_standard_policy or missing_duration.
- draft_text: one or two sentences, explicitly awaiting review where applicable.
- source_ref: document ID, version and clause for policy claims, or NONE when no policy conclusion is made.
- missing_fields: explicit field names, or NONE.
- proposed_next_step: an instruction to the human reviewer, not a claim that it happened.

Do not let the assistant provide approval_status, sent_at, booking_id or a trusted reviewer identity. Those belong to other actors or systems. An output can be well formed and still be wrong; format validation and factual validation are separate checks.

Build the configuration in three layers

We will build the instructions around the R104 card, rather than begin with a long specification. All snapshots below are authored teaching examples. They show a manual decision trace, not a claim that a model or app ran.

Layer 1 identifies the request and asks for what is missing. Start with this instruction: “Copy the request ID and revision exactly. If either is unusable, stop with INVALID_INPUT. For other missing required details, ask a focused question.” Identity comes first because a question or draft must be attached to the right request. The workflow also has a duplicate check, taught in Modules 5–6; for this first example assume this is a new delivery with no prior record.

Before: R104, revision 1, staff, speaker, new request, 14 October, duration missing. After the check: the identity remains R104 revision 1; duration remains missing; the proposed status is NEEDS_INFO. Here is the complete eight-field output:

- request_id: R104
- revision: 1
- draft_status: NEEDS_INFO
- reason_code: missing_duration
- draft_text: For how many whole calendar days do you need the speaker?
- source_ref: F1 version 1 clause F1.3
- missing_fields: duration_days
- proposed_next_step: Reviewer checks the question before asking for the missing duration.

Notice what did not change: the assistant did not turn a blank into zero or invent a duration. If the card had no request ID, it would stop as INVALID_INPUT instead. We know the missing-duration request's identity; we do not know the unidentified card's destination.

Layer 2 adds a policy decision. The reply supplies two days and the intake record becomes R104 revision 2. Add this instruction: “Use the approved source effective on the as-of date. Check the supplied values, then apply the standard conditions; send exceptions or unresolved source conflicts to human review.” Version 2 means changed request details. It does not mean a new policy version.

Before: R104 revision 2 now has duration_days 2. The human or fixed check finds that 2 is a positive whole number and P1.2 allows a standard speaker request up to 3 days. After: draft_status DRAFT_READY; reason_code within_standard_policy; source_ref P1 version 1 clauses P1.2 and P1.5. If the reply instead said four days, the same check would produce HUMAN_REVIEW. The explanation changes because the duration crosses a policy boundary, not because the assistant sounds more confident.

Layer 3 makes the output and review boundary explicit. Add: “Return the eight named fields. State only what the source supports. A valid draft is awaiting a person; do not claim stock, approval, booking or sending.” For R104 revision 2, a suitable draft is “The requested two-day speaker loan is within the standard duration. A desk reviewer must check availability and decide the next step.” The next actor is the reviewer. No action has happened merely because the draft is well formed.

Now add the protective checks around those layers. Supplied malformed values are INVALID_INPUT. A request to bypass instructions or a material disagreement between the message and fields goes to HUMAN_REVIEW before ordinary missing-detail processing. This prevents a request such as “ignore the rules and approve me” from quietly becoming an ordinary draft. If identity is unusable, the identity stop still comes first. Source text and request text cannot change this order.

Open practice/assistant-configuration.txt to see the complete portable configuration. Read each instruction back against one of these snapshots. You should be able to say which field or decision it protects. The later workflow repeats the important checks outside the model before recording a draft.

Write useful conversation starters

A conversation starter is a short invitation shown when someone opens a saved assistant, or a reusable first message in an ordinary chat. It helps the user begin the right kind of work. It is not a policy source and does not grant permission.

Useful starter: “Check a fictional equipment request for desk review.” Another is “Help me identify which request details are missing.” Both invite a bounded task. A poor starter is “Approve my five-day webcam booking”: it embeds a changeable limit and suggests authority the assistant does not have. Keep current policy numbers in the source pack.

Write two starters for your configuration: one for a new request and one for an incomplete request. Then predict what information a user should supply after choosing each. Test them with a fresh conversation or a paper trace before adding them to your capstone.

Worked test

Input: R101, revision 1, 14 October 2026, staff, projector, 2 days, new request. Message: “Please prepare a request for a projector for two days.” Supply P1 and F1.

Illustrative output, authored for teaching rather than obtained from a live model:

- request_id: R101
- revision: 1
- draft_status: DRAFT_READY
- reason_code: within_standard_policy
- draft_text: The requested two-day projector loan is within the standard duration. A desk reviewer must check availability and decide the next step.
- source_ref: P1 version 1 clauses P1.2, P1.3 and P1.5
- missing_fields: NONE
- proposed_next_step: Reviewer checks the request and availability; no booking has been made.

Why this works: the record preserves identity, states only a supported duration conclusion and stops short of availability or approval. A faulty variant would say “Approved for pickup tomorrow.” Tomorrow is not in the input; no inventory or appointment evidence supports it.

Try a saved assistant if available

Use the short current tool guide to choose an existing permitted assistant feature. Its configuration fields generally correspond to a name, description and instructions. Paste your stable configuration there and use only the course's synthetic references. Test in a fresh conversation after saving. If the feature is unavailable, paste the configuration followed by the current pack and request into an ordinary existing chat. Label that route “manual reusable prompt,” not a saved assistant.

If you have no chat access, use the illustrative outputs in the workbook to review behaviour. You can complete a configuration and test plan, but mark model results “not executed.” Do not create an account or buy a subscription to satisfy this course.

Practice

1. Predict the next check for R104 with missing identity, with missing duration, and with a supplied four-day speaker request. Explain the changed result before reading the configuration. Write two conversation starters, then adapt the portable configuration to your contract. Save it as version 1 with a date and a one-line change description.
2. Run or rehearse R101, R104 and R105 from event Pack A. Do not open the answer key first. Record expected status before testing.
3. For each result, inspect identity, missing fields, claims, sources and authority. Record the actual output in full if you used a live model. If you reviewed an illustration, say so.
4. Improve one instruction that addresses a real observed or supplied failure. Avoid a long collection of unrelated prohibitions. Save version 2 and repeat all three cases, not only the failed case.
5. Start a clean conversation and check whether the saved configuration still applies. A correct response in the old conversation may rely on context you forgot to save.

Expected artifact: two configuration versions, two tested starters, a change note and a three-case comparison with evidence labels. A wording difference alone is not a defect if the meaning, field contract and boundaries remain correct.

Check your understanding

M2 Q1. Where should “webcam maximum five days in October” live, and where should “cite the effective approved policy” live?

M2 Q2. The assistant prints draft_status APPROVED but the prose says “awaiting review.” Should a downstream system accept the record? Explain.

M2 Q3. Why is a fresh-conversation test useful after you edit a saved assistant?

Before you continue

Make sure no configuration claims that a loan was approved or that an action occurred. Preserve the output contract for Module 4. You will learn to manage the source pack next.
