Once the goal of the work is clear, a useful AI exercise needs a bounded task and a way to check the result. Here is how I would run that part of a session with university staff, product teams, and engineers.
Once the goal of the work is clear, a useful AI exercise needs a bounded task and a way to check the result. Here is how I would run that part of a session with university staff, product teams, and engineers.
This retrospective entry was prepared from an October 4 draft and first published on October 27, 2026. Its September archive placement is an editorial date.
This is part of the three areas of my university AI work.
For an AI consultation with someone at a university, I asked them to bring a specific task they wanted to automate and tell me what access they already had.
Those questions give the session somewhere to go. We can look at the work, try a small part of it, and decide whether the result is useful. We can also avoid spending most of the hour discovering that nobody can open the system we planned to use.
Choosing a task starts with understanding what the person is trying to accomplish. Once we have a task worth trying with AI, this is how I would structure the exercise.
Start with something a person already does and understands.
For example, suppose a team turns a project-status export into a weekly summary. Someone reads the rows, identifies blocked work, checks unclear entries, and writes an update. That gives us inputs, decisions, and an output to examine.
Narrow the first attempt to drafting the summary from a small approved sample. Leave sending it, updating the source system, and scheduling future runs outside the exercise.
Ask the person who does the work to describe a good result before opening the AI tool. Which details must survive? What would make the summary misleading? What should happen when a row is incomplete?
That person already knows things the prompt needs.
Before the session, establish which tools the university permits for this work, which accounts participants can use, and what data is allowed in them. Check whether the exercise needs permission to read, edit, or connect anything.
An account that opens successfully is only one part of that check.
Use approved material or synthetic examples that preserve the shape of the problem. For the status-summary exercise, invented project names and deliberately varied statuses can be enough. Include missing values and inconsistent wording so the exercise has something to catch.
Keep private records out of the training example unless their use in that specific tool and setting has been approved. Replacing names alone may leave other identifying details behind.
If access is unresolved, use the prepared sample. The real workflow can still guide the lesson.
A useful task description covers the input, the requested output, the rules, and the stopping point.
For our example:
“Use this sample export to draft a weekly project summary. Group entries by status, identify blocked items, and reference the source row for each claim. Mark missing information as unknown. Show the draft for review.”
Then add the boundary: do not send the summary or change the source data.
Ask participants to inspect that instruction. Does “blocked” have an agreed meaning? Should an overdue date change the status? If the source does not answer those questions, the model should not silently decide them.
This is where staff, product, and engineering knowledge becomes useful together. The person doing the work explains the exceptions. Product helps define the result. Engineering can assess what an eventual implementation would require.
Keep the sample and the generated summary visible together.
Check a claimed blocker against its row. Follow a source reference. Look for an item that disappeared. Find out whether the AI converted an uncertain status into a confident statement.
When something is wrong, save the input, the output, and the specific discrepancy. Then change the instruction and repeat the same example. Otherwise, it is easy to improve the wording without finding out whether the original failure is fixed.
This follows the approach I described in how I check AI work before calling it done: keep observations separate from explanations and require evidence for the behavior being claimed.
A clean first example leaves plenty untested.
Add a blank status. Repeat a row. Include two entries whose wording sounds similar but means different things. Check whether the summary preserves those differences and whether someone reviewing it can find the source.
If the exercise produces a dashboard, change the underlying sample and check the displayed values. If it produces a script, run it on test inputs and inspect the actual files or records it creates. A description of what the code should do cannot establish what it did.
Keep the checks understandable to the people responsible for the workflow. They need to be able to say why the result passes.
Before a prototype becomes routine work, identify its owner.
Who maintains the instructions or code? Who notices a failed run? Who reviews the result? Who can stop the automation and return to the manual process?
Those questions may lead to an engineering handoff, another small test, or a decision to keep the process manual. A useful training session can end at any of those points.
Leave behind the task description, the approved example, the checks performed, the known limitations, and the next owner. Keep human review at the point where an incorrect result could mislead someone or trigger an unwanted action.
If you want to work through AI with me, bring one recurring task you know well. Bring an approved or synthetic example and tell me what tools you can already access.
We can use that to work out what is worth trying, what needs checking, and where a person needs to stay involved.