Enablement · Single-day workshop

Introduction to AI

For people who have not used AI in a professional capacity yet. One day. Five objectives. How these systems work, how to brief them on a real task, and how to revise what comes back.

The day

An introduction, then practice.

This day is for people who have not used AI at work yet. They may have tried a chat box at home. They have not put it on a brief, a report, or a deadline. The morning builds a picture of what a model is doing. The rest of the day puts one live task from their job in front of a model and treats the output like a draft from a colleague.

No software to install and no stack to buy. A standard chat tool is enough. People who already ship with models in Unreal or Python belong in the technical workshops below, not this one.

Objectives

By the end of the day you will be able to:

01
Explain, in your own words, how a model produces an answer and why two runs of the same request can differ.
A shared vocabulary for the rest of the day. People should be able to say what the system is doing without turning it into mysticism or a computer science lecture.
02
Tell apart the AI systems you already sit next to at work: predictive models, generative models, and assistants that use tools.
So AI stops meaning only the chat box. People should be able to name which kind of system they are looking at in the software they already use.
03
Put a real piece of your work in front of a model and get a usable first pass from a written brief.
Practice, not a demo. Each person brings a task they already owe and aims the model at that job with a brief and source material.
04
Revise that output the way you would edit a colleague: against the brief, then with a pointed second request.
The draft is the starting point. The skill is reading it, marking it, and sending it back without throwing the thread away.
05
Leave with one weekly workflow, written down, that you have already run twice in class.
One job they will still have next week, captured as a method, tested on a second example before they walk out.

Agenda

Topic 01

Objective 1

How a model produces an answer

A working picture of what sits under the chat box: trained weights, prediction, and variation. Enough to use the system. No programming.

What a model is

The object itself, in ordinary language, so the rest of the day has one shared picture.

A model is a function trained on examples. It is not a filing cabinet of facts you can query by name.
Given your input, it predicts the next piece of a pattern: the next word, pixel, or token that fits what came before.

Training and use

The difference between how the system was built and what happens when you press send.

Training is the expensive, mostly one-time pass over large datasets that sets the model's weights.
Everyday use is inference: your request in, an output out, no new learning unless a separate system is built for that.

Why two drafts differ

Why the same request is not a lookup, and what that means when you compare outputs.

The system samples among likely next pieces. It is not looking up a single stored paragraph.
A small change in the brief, the order of notes, or the length you asked for will pull a different pattern forward.

Topic 02

Objective 2

The systems you already meet at work

Three kinds of AI already in business software, named clearly, so people can tell which one they are looking at.

Predictive AI

The quiet scoring and forecasting already running in tools people use every week.

Scores, forecasts, rankings, and labels: likely to renew, likely to need follow-up, likely demand next quarter.
It is often already running inside a CRM, ERP, ad platform, or fraud tool, without a chat box.

Generative AI

Systems that draft new material from a request: text, images, code, slides.

Text, images, code, and slides drafted from a request. This is what most people mean when they say AI this year.
It is a drafting partner. The quality of the draft tracks the quality of the brief and the source you attach.

Assistants that use tools

When a model can search, open a file, or take a step, not only write a paragraph.

A model that can search, open a file, or call a calculator is taking steps, not only writing a paragraph.
Multi-step work needs a trail you can follow: what it looked up, what it used, what it wrote.

Topic 03

Objective 3

Briefing a model on your work

How to put a live task in front of a model so the first pass is aimed at the job, not at a generic topic.

The brief

What you write before any source goes in: the task, the reader, the length, and what done looks like.

Name the task, the reader, the length, and the tone before you paste source material.
Write what done looks like: a one-page brief for a VP, a 150-word customer reply, a three-bullet agenda.

Context

The material the model is allowed to use, and the limit of that window.

Give it the source it needs: notes, a product sheet, last week's email, the outline you already have.
If a fact is not in the window, the model cannot use it. It will fill the gap with a fluent pattern instead.

The first pass

Getting a draft you can work with, including running the same brief twice.

Ask for a draft. Do not ask it to finish the job in one shot.
Run the same brief twice and set the two drafts side by side before you edit either one.

Topic 04

Objective 4

Revising the output

Treating the model's draft like a colleague's: check the assignment, mark what to change, send it back.

Read against the assignment

Whether the draft matches the brief, and whether the structure is doing the job.

Check whether the draft matches the brief you wrote, or a generic version of the topic.
Read structure first: order, headings, what is missing. Then read sentences.

Send a pointed revision

How to ask for the next pass without starting over in a blank chat.

Mark the weak part in plain language: too long, wrong reader, skipped the constraint, buried the ask.
Return the marked draft. Do not open a new blank chat and hope for a cleaner start.

Keep the substance yours

What stays from your material, and what you cut so the next pass stays aimed.

Names, figures, and claims come from your material. The model is there to phrase and arrange.
If a line is useful, keep it. If a line is filler, cut it in the open so the next pass stays tight.

Topic 05

Objective 5

One workflow you take back

One weekly job, written as a method, run twice before people leave so it is a process they can repeat.

Pick the job

A recurring task and a brief worth saving, not a one-off prompt.

Choose a task you already do at least weekly: agenda, summary, first draft, rewrite for a new audience.
Write the reusable brief for that job, not a one-off prompt you will forget.

Capture the method

The brief, the source, and the revision notes that actually moved the draft, written so someone else could follow.

Save the brief, the source you attach, and the two revision notes that actually moved the draft.
Name the output so a teammate could follow the same steps without you there.

Run it a second time

The same method on a new example, so it is tested in class, not only described.

Repeat the same job on a second example before the day ends.
Write down how long it took next to how you usually do that task, while the comparison is still honest.

Assessment

Multiple choice quiz

A short quiz after the morning blocks. Items cover how a model produces an answer, why two drafts can differ, and how to tell predictive systems, generative systems, and assistants that use tools apart.

Work sample

Each person turns in one packet from their own job: the brief, two first-pass drafts, one marked revision sent back to the model, and the weekly workflow written down and run on a second example. The packet is the evidence they met the last three objectives.

Also taught

Unreal and Python

For teams already in production. Introduction to AI is for people who have not used AI at work yet. These two were taught to professionals who had to ship in Unreal or in Python.

OpenAI API in Unreal Engine

Unreal engineers, technical artists, simulation and visualization teams

How to call a language model from inside Unreal: request, response, and where that output lands in a running scene or editor tool. Taught as a working class, not a slide deck. The same problem as a C++ wrapper plus Blueprint so people who do not live in native code can still fire the call.

API key, request shape, and streaming versus a full response
A C++ wrapper other systems can call, with Blueprint exposure for designers
Putting the result on an actor, a widget, or an editor action they already use

AI-assisted coding with Python

Developers, TAs, and anyone writing scripts who will use a model on real code

Using a model as a coding partner in Python: write a brief for the function, generate, read the diff, run it, send a pointed revision. People work on scripts they brought, not toy katas.

A brief that names inputs, outputs, and the failure you will test
Reading generated Python before you run it: imports, edge cases, what it invented
A revision loop: mark the break, send it back, keep the tests in your hands

If you want this for your team, email me.

Introduction to AI if they have not used it at work yet. The Anatomy of a Harness if they need a repeatable job around a model. OpenAI in Unreal or AI-assisted Python if they already ship. Email matt at sleektiki dot ai.

Email Matthew The Anatomy of a Harness