Situation
Who is asking, what they need and by when.
AI practice scenarios are role-play tasks where a learner uses AI on a realistic work situation, then explains what they changed. In Tosheo.ai each scenario is planned to be scored against a rubric the learner sees before submitting.
Rewrite a launch email. Keep the promise specific. Remove the claim you cannot prove.
Use a fictional brief, name the audience and set the constraints.
Make a draft, inspect what changed and try again with clearer instructions.
Check evidence, protect information and explain your final decisions.
An AI practice scenario is a short role-play that asks the learner to apply AI to a realistic work situation and make the judgement calls a real task needs. A typical planned brief: a client wants a campaign plan by tomorrow; use AI to produce a first draft, then explain what you changed and why.
Scenarios sit alongside lessons as a practice mode. A lesson teaches one skill with a worked example; a scenario combines several skills under realistic pressure, such as a deadline, an unhappy customer or a brief with a gap in it.
Every planned scenario has five parts, and the learner sees all of them before starting.
Who is asking, what they need and by when.
The facts the learner is allowed to use, such as a policy, a brief or a data table.
What must not happen, such as no promises outside policy or no figures beyond the table.
The output to submit: an email, a summary, a plan outline or a reply.
A short note on what the learner kept, changed or removed from the AI draft, and why.
Here is an illustrative Support scenario. A customer of a fictional homeware shop, Copperleaf Home, writes that a lamp arrived two weeks late and asks for a full refund plus free delivery on the next order. The supplied policy allows a refund for late delivery on request, and says nothing about free delivery.
The learner prompts their AI tool: "Draft a reply to this customer. Apologise for the late delivery and follow our refund policy, pasted below. Do not offer anything the policy does not cover." The first draft is warm and fluent, but it promises the refund "within 24 hours" and offers free delivery on the next order. Neither appears in the policy.
The reviewed version keeps the apology, confirms the refund under the late delivery rule, gives the timescale only as the policy states it and replaces the free delivery offer with a line saying the request has been passed to the team that can decide. The learner's note says: "Removed the 24-hour promise and the free delivery offer because the policy does not support either."
The rubric is planned to be visible before submission, with a small number of criteria that each describe what a strong answer does. For the Copperleaf scenario it might read like this.
Feedback should then point to the work. A useful comment would be: "Policy fidelity is strong. Tone could be warmer in the first line, which currently opens with the policy rather than the apology." There can be more than one acceptable answer, so the rubric rewards judgement rather than an exact match to one paragraph.
| Criterion | What a strong answer does | A common miss |
|---|---|---|
| Policy fidelity | Every commitment can be traced to the supplied policy | Keeping an AI-invented timescale or goodwill offer |
| Tone and reader | Acknowledges the problem plainly and has one clear next step | Long apology with no answer to the actual request |
| Review decisions | The note names what changed and why | "Made it better" with no specific change named |
The learner can flag any score they disagree with. A flagged score goes to a review queue, where it is checked by a person or by a second-model review. Every evaluation is planned to be logged, so the reviewer sees the submission, the rubric and the original feedback together.
This exists because AI grading can be wrong. The flag-and-review route is how the product plans to handle that openly, rather than leaving a learner to accept an unexplained score. It is not an assurance that every score will be correct.
Use a scenario as a conversation starter, not a verdict. Ask which information was supplied, what the learner checked independently and which judgement they kept for themselves. A polished answer without a review trail is a weaker signal than a modest answer with clear reasoning.
The manager view is planned to show skill progress and completion, not raw learner chats. Treat the result as one piece of evidence and keep applying your normal approval rules to real work.
Scenarios teach judgement in common work situations. They do not replace training on your own regulated processes, legal sign-off or compliance approval. They also do not teach the menus of a particular AI tool; the vendor's own help pages are better for that.
Every scenario on this website is illustrative and uses fictional companies. It is not evidence of a validated assessment or a productivity gain, and the product itself is pre-build.
No. Scenarios are designed so that several answers can score well. The rubric describes what a strong answer does, such as keeping every commitment traceable to the source, rather than matching a model paragraph.
A flagged score is planned to go to a review queue for a human or second-model check. The reviewer sees the submission, the rubric and the original feedback.
Not by default. Scenarios supply fictional source material. On the Growth plan, uploaded company documents can shape examples, but learners should still follow company policy on what goes into an AI tool.
No. Managers are planned to see skill progress and completion rather than raw chat logs. The exact fields will be documented before launch.
Explore the planned role-specific lessons, practical tasks and manager view.