Module 2: Prompt, Context, and Workflow Engineering

A prompt tells the AI what to do, but dependable educational work also depends on what the system is allowed to know, what tools it can use, and how the result will be checked. A concise instruction with strong evidence is often better than a long persona-heavy prompt with weak context.

Separate the work into layers: instruction for task, audience, constraints, and desired behavior; evidence/context for syllabus, readings, examples, policy, or learner-safe data; tools for search, calculation, files, connectors, or code execution where authorized; output contract for the exact structure the result must follow; evaluation for acceptance criteria and test cases; and human decision for what must be reviewed or approved.

This separation helps diagnose failures. If the AI invents a policy requirement, the problem may be missing authoritative context rather than weak wording. If the result is correct but unusable, the output contract may be the problem. If a workflow works once and then fails on a different case, the missing layer may be evaluation.

This course uses T-E-A-C-H as a compact specification for everyday educational AI work.

• T — Task: What must be produced or decided?
• E — Evidence and Context: Which files, sources, examples, data, or policy control the work?
• A — Audience and Assumptions: Who will use the result, what do they already know, and what may not be assumed?
• C — Constraints and Criteria: What format, scope, quality rules, timing, pedagogy, privacy, or institutional constraints apply?
• H — Human Verification: What must a person check, approve, or resolve before use?

T-E-A-C-H is deliberately simple enough for basic AI users but strong enough to grow into agentic workflows. It prevents common omissions: asking for a lesson without the learner level, asking for an assessment without outcomes, or asking for grading without a rubric. For higher-consequence tasks, expand each letter into a structured field rather than relying on prose alone.

Context engineering is the deliberate construction of the information environment around a task. More context is not always better. Irrelevant files, old policies, contradictory instructions, and duplicate versions can make results worse.

For educational work, identify a source hierarchy before prompting. A practical order may be: current institutional policy or curriculum → approved syllabus/outcomes → adopted references → instructor-provided examples → secondary materials. State which source wins if two files conflict.

Also control revision identity. A syllabus labelled “final” may still be older than the version used in class. Ask the workflow to identify filenames, dates, editions, or version labels when they matter. If a required source is missing, the correct behavior is usually to surface the gap—not to fill it with a plausible assumption.

Good context engineering reduces hallucination by narrowing what the system is permitted to treat as authoritative.

An output contract specifies the fields and structure expected from a response. It turns a conversational answer into an artifact that can be inspected, reused, and passed to another stage.

For a lesson-planning task, a contract can require fields for learning outcome, prerequisite, activity, evidence of learning, time, assumption, and human review. For grading, it can require criterion, submission evidence, proposed level, proposed score, uncertainty, and reviewer decision.

Structured outputs reduce hidden omissions and make comparison easier. They also support automation because downstream steps do not need to guess where information is located. The contract should include uncertainty behavior such as INSUFFICIENT EVIDENCE or NEEDS VERIFICATION so the model is not forced to invent a complete-looking answer.

Examples can teach the model what a good output looks like, but they should not silently redefine the task. Use exemplars when style, structure, rubric interpretation, or level of detail is hard to describe abstractly.

A strong exemplar should be representative rather than unusually polished, clearly labelled as an example rather than authoritative evidence, consistent with the current rubric or policy, stripped of unnecessary personal information, and accompanied by a note identifying what should be imitated.

When using student work as an exemplar, follow institutional privacy and consent requirements. For scoring workflows, use benchmark responses only when they are valid anchors for the rubric. An exemplar can improve consistency, but it can also bias a model toward surface similarity; the rubric and actual evidence remain controlling.

A second AI pass is useful only when it has a different job. “Check your answer” often produces superficial agreement. Instead, assign the review pass explicit failure modes: locate unsupported claims; identify missing outcomes or blueprint cells; recompute numerical results; test whether an alternative interpretation is defensible; inspect privacy or accessibility risks; or search for evidence that would overturn the draft.

For important work, independent evidence matters more than independent wording. A second model repeating the same unsupported assumption does not create verification. Ask the reviewer to cite the source, calculation, rubric criterion, or policy behind each blocking finding.

Adversarial review is especially helpful before publishing assessments, automated workflows, and high-stakes feedback.

Reusable prompts should be improved against representative test cases, not only against the last failure. Keep a small evaluation set containing normal, edge, incomplete, and failure cases. For example, an assessment-generation prompt might be tested on a well-specified outcome, an ambiguous outcome, a missing reference, and a topic with two defensible interpretations.

When a test fails, change the responsible layer: instruction failure → improve task or constraints; evidence failure → improve source selection; formatting failure → improve output contract; unsafe action → tighten permissions or approval gates; recurring reasoning failure → add a deterministic check or human review.

After changing the workflow, rerun earlier cases. This regression mindset prevents a fix for one scenario from breaking another.

Allow 75–90 minutes for the full module or 50–60 minutes in a condensed workshop. The essential live demonstration should show one weak prompt, the same task rewritten with T-E-A-C-H, and a verification pass that catches a deliberately planted problem.

Participants should build one reusable teaching prompt plus a compact evaluation set of at least three cases. The output should be stored as a template they can reuse in later modules.

• Prompt engineering — OpenAI. Official guidance on instructions, context, reusable prompts, and prompt design.
• Model optimization — OpenAI. Evaluation-first guidance for testing and improving AI outputs.
• Guidance for generative AI in education and research — UNESCO. Human-centred guidance for generative AI in education and research.