I would review the problem before the AI demo

TL;DR: Before reviewing an AI demo, I would ask the team to describe the problem without naming the product it plans to use. The opening recap in this CS221 concluding lecture offers a useful sequence: modelling, inference and learning. It helps engineers and product leaders distinguish a task from the interface wrapped around it.

The lecture begins with a real-world problem, an abstraction of that problem, a way to reason within the abstraction, and data that can improve an incomplete model. Stanford’s course materials also show how broad the toolkit is: search, learning, decision processes, constraints and logic all belong in the subject.

That breadth is the useful reminder. A chat box does not tell us which part of a problem requires language generation, which part requires prediction and which part is already a well-defined calculation.

I would make the first review produce a problem description that remains useful if the preferred vendor disappears tomorrow.

Separate understanding the request from allocating the work

Consider a hypothetical support operation assigning incoming requests to specialists. A demo might show an agent reading the message, selecting a person and explaining its decision. The smooth sequence hides several questions.

Interpreting a vague description could require a language model. Predicting the effort involved could use historical cases. Assigning work while respecting availability and specialist coverage is a constrained allocation problem. Those pieces can cooperate without sharing the same implementation.

I would first write down the required output: an assignment that respects named constraints, with unresolved requests sent for clarification. Then I would ask which information is known, which must be estimated, and which conditions the system must always satisfy.

A model can propose a category for the request. Ordinary validation can check that the category exists. An allocation method can consider capacity. An explanation can describe the resulting choice. That decomposition makes it possible to find the cause when a plausible answer is operationally impossible.

If a specialist was unavailable, improving the prose will not repair the scheduling rule. If the request was misunderstood, a perfect optimiser may simply allocate the wrong work efficiently.

Make the simplest alternative visible

For the first experiment, I would compare the proposed approach with a small baseline that uses the same inputs and success criteria. The point is to discover where added complexity earns its place. It is perfectly reasonable for the language model to remain central if it solves the difficult part.

The limitation is that a classroom taxonomy does not choose the production architecture for you. Real tasks overlap, available data may be poor, and implementation costs matter. The exact edition of the reposted recording also remains unresolved, so I would use its opening framework without attaching claims about a particular syllabus or promised business outcome.

A good demo shows that something can happen. A useful project review explains why the chosen method should handle the problem when the easy example changes.

Describe the decision, uncertainty and constraints before deciding which AI product should carry them.