A prompt and context engineering practice gives a team a repeatable way to build, evaluate and maintain LLM features. It connects product requirements with the instructions, evidence, tools and release controls that determine behaviour.
The practice needs owners and usable artefacts. A collection of clever prompts is difficult to maintain when nobody can explain which version is running or which failures it was tested against.
Keep a small set of maintained artefacts
Maintain a versioned release configuration, evaluation dataset, tool and response contracts, and operational runbook. Link them through stable identifiers.
The release configuration identifies what is running and links to the evaluation evidence for that version. Contracts define acceptable data and actions, while the runbook explains how to diagnose and recover from failures.
A prompt registry can be simple. The important properties are recoverable versions, ownership and a clear route from an observed response to its configuration.
Assign decisions to the right owners
Product and domain owners define acceptable behaviour, including ambiguity and missing information. Engineers implement context assembly, validation and execution controls. Reviewers establish labels and assess difficult cases.
One person may hold several roles in a small team, but the decisions still need to be explicit. “The model chose it” is not a product rule for refund eligibility or data access.
Give evaluation and monitoring maintenance an owner. New incidents should become reviewed cases, while obsolete requirements and duplicated cases should be retired deliberately.
Review traces with a question in mind
A regular review can examine recent failures, disagreements and a small representative sample. Ask where the system first lost the information or constraint needed for success.
Classify the issue before proposing a fix. Distinguish missing evidence, poor selection, ambiguous instructions, invalid output, tool failure or an incorrect business rule.
A longer prompt is only one possible response. Sometimes the appropriate repair is a database constraint, a clearer source document or a narrower tool permission.
Keep an experiment record
An experiment should state the hypothesis, baseline, change, dataset, grader, results and decision.
Hypothesis:
Adding the policy exception will improve answers for dispatched orders.
Controlled change:
Include clause 4.7 when clause 4.2 is selected.
Measures:
Correct decision, supported next step, input tokens and response time.
Decision:
Accept only if exception-case performance improves without a critical
regression elsewhere. Record the observed results and uncertainty.
The record should preserve failures as well as accepted changes. That prevents later teams from repeating an attractive idea without seeing the evidence against it.
Capstone: build an order support assistant
Use a fictional order dataset and a short versioned policy. The assistant should answer eligibility questions, identify missing information and propose a cancellation only through an authorised tool.
The project should produce:
- A task specification and baseline prompt.
- A context builder with source IDs and a token budget.
- A response contract with answer, clarification and abstention paths.
- A tool executor with ownership checks and duplicate action protection.
- An evaluation report covering normal cases and failures.
- A release manifest, monitoring plan and rollback procedure.
Use simulated services while developing the workflow. Do not connect the exercise to real customer accounts or payments.
Demonstrate competence through evidence
A complete submission shows both a successful run and a failed run handled correctly. Include an unanswerable question, a conflicting source, an unauthorised order and a lost tool response.
Explain why each control is placed where it is. A prompt instruction expresses intended behaviour; an execution check enforces an action boundary. A citation identifies evidence; a support check assesses whether the evidence establishes the claim.
The course assessment checks understanding of these decisions. The practical project provides a separate opportunity to demonstrate implementation, diagnosis and judgement. Keep those forms of evidence distinct when describing what completion means.