The Team Project: Designing an AI-Assisted Solution

EveryEvery idea preceding this page in the module has been building towards one capability: the judgement to decide how AI should be involved in solving a real problem, rather than defaulting to "type the problem into a chat window and see what comes back." A one-prompt solution and a genuinely AI-assisted solution can look identical in a five-minute demo and be worlds apart in reliability, in how well the team actually understands what they built, and in what happens the moment the input changes slightly. This page is the synthesis: a practical framework for scoping, building, evaluating, and presenting a team project that uses AI deliberately rather than reflexively.

Scoping a Real Problem, Not a Demo

StartStart from a problem, not from a tool. "We'll build something with RAG" is a solution looking for a justification; "our department's onboarding documents are scattered across four systems and new starters ask the same six questions every week" is a problem that might — or might not — turn out to need retrieval at all. A useful early filter, adapted from project-based-learning design practice, is to require the problem to have sustained inquiry and authenticity — a real audience, a real constraint, and enough genuine uncertainty in the solution that the team is actually finding something out, not just executing a known recipe [1]. A project scoped this way naturally resists the one-prompt trap: if the honest answer to "what does success look like, concretely, for the people who'd actually use this" takes more than a sentence, the team already has real design work ahead of it, and the sentence itself becomes the first artefact of the project.

Write the scope down before touching a tool: who has this problem, what they do today without AI, what would have to be true for an AI-assisted version to actually be better than that baseline (not just different from it), and — critically — what would count as evidence the team got this right. This last question is the one teams skip, and it is the one the marking criteria for this project will keep coming back to.

Choosing Which AI Capability Actually Fits

OnceOnce the problem is scoped, the module's own toolkit becomes a decision, not a shopping list. Three questions, asked in order, cover most of the ground the preceding pages set out:

• Does the solution need to be grounded in specific documents or data the model wasn't trained on? If yes, some form of retrieval belongs in the design — see Retrieval-Augmented Generation for what that actually requires beyond "paste some text into the prompt": chunking choices, retrieval quality, and the difference between a system that retrieves relevant text and one that retrieves text that merely looks relevant.
• Does the task need a single well-formed output, or a sequence of steps where later steps depend on the results of earlier ones? A single-shot summarisation or drafting task is a very different design problem from one requiring the AI to plan, act, observe a result, and revise — the latter is the agentic pattern covered in LLM Orchestration, Context Engineering & Agentic AI, and it comes with real new failure modes (compounding errors across steps, the system confidently continuing down a wrong path) that a single-shot design simply doesn't have.
• Is a single AI capability actually enough, or does the real problem need two or three working together — retrieval to ground the system in the team's actual source material, generation to produce the output, and some orchestration to keep a multi-step task on track? Most genuinely useful project solutions turn out to be a combination, not a single technique, and naming that combination explicitly (rather than discovering it by accident halfway through implementation) is worth the up-front design time. See AI Fundamentals: A Landscape of Approaches for the underlying map of what each family of technique is actually good at.

Context Engineering at Project Scale

TheThe context-engineering discipline introduced for a single prompt — being deliberate about what information the model can see, in what form, and in what order — doesn't disappear at project scale; it becomes a team-level design artefact rather than an individual habit. A team building an AI-assisted solution should be able to point to, and justify, exactly what context their system assembles before generating an output: which source documents, which prior conversation turns, which retrieved passages, and why that particular selection was judged sufficient. Treat this as documentation the team owns and can defend, not an implementation detail buried inside a tool's default settings — a marker or a teammate should be able to ask "why did the system have access to this and not that" and get a real answer, not "that's just what the default prompt template included."

Building In Critical Evaluation, Not Bolting It On

ThisThis module's own learning outcomes require the ability to "critically assess the quality, reliability, and bias of AI-generated outputs in real-world contexts" — and the single biggest structural mistake a team project can make is treating that assessment as a paragraph added to the report after the system already works, rather than as an activity that shapes the build itself. Apply the same evidence-weighing discipline set out in AI in Business, Education & Society to your own system: for every output your solution produces, what would count as evidence it's actually correct or appropriate, and did you go and gather that evidence, rather than assuming a plausible-sounding output is a correct one? A team that runs its own solution against a handful of deliberately awkward, edge-case inputs and documents what broke has produced a stronger and more honest deliverable than a team that only ever demonstrates the cases where everything worked.

Kolb's experiential learning cycle offers a useful discipline for structuring this as an ongoing loop rather than a one-off check: a concrete experience (the system's actual output on a real input), observation and reflection on what that output got right or wrong, forming a more general conclusion about why, and then actively testing that conclusion by changing the design and trying again [2]. Run that cycle explicitly, more than once, over the build phase — a single evaluation pass at the end is not the same activity as a cycle repeated as the system develops, and only the latter genuinely improves the system rather than just describing its final state.

Presenting With Honest Reflection, Not Just a Demo

AA team presentation built entirely around "here is our system working" answers only one of the module's learning outcomes and skips the one about critical reflection on societal and ethical implications. Structure the presentation to include, deliberately, the same class of question this module has asked about AI generally, now turned on the team's own work: who could be disadvantaged, misled, or excluded by this system as built; what happens when it's wrong, and who bears that cost; and what the team would build differently with more time. Boud, Keogh, and Walker's model of reflection is precise about what separates a genuine reflective account from a retrospective narrative: it requires actively returning to an experience, attending to the feelings it produced (including the uncomfortable ones, such as noticing your own system did something you weren't proud of), and re-evaluating the experience in light of that — not simply describing, after the fact, what happened [3]. A presentation slide listing "limitations: sometimes gets things wrong" is description; a presentation that explains a specific instance where the team's system produced a biased or misleading output, why that happened given how the system was built, and what design change would address it, is reflection — and it is also, not coincidentally, a stronger and more credible piece of work. See AI Ethics for the broader framework these project-specific judgements sit inside, and Project Navigation & the Art of Triangulation and Getting Unstuck for general project-management practices (keeping a discovery log, re-checking your position against the literature and the problem) that apply here exactly as they do to any substantial project.

References

1. Larmer, J., & Mergendoller, J. (2015). Gold Standard PBL: Essential Project Design Elements. Buck Institute for Education (PBLWorks).
2. Kolb, D. A. (1984). Experiential Learning: Experience as the Source of Learning and Development. Prentice-Hall.
3. Boud, D., Keogh, R., & Walker, D. (Eds.). (1985). Reflection: Turning Experience into Learning. Kogan Page.