1. Learn New Skills for Your BusinessExpanded talk trackThis session is where useful AI answers start becoming repeatable business processes. In the first workshop, the core habits were asking clearly, checking the result, and keeping important decisions with a person. The second workshop added the facts, examples, and voice that make an answer fit the business. Today we connect those pieces. We will give the work a reliable context, build one small process, test it with both an ordinary case and an exception, and save the repair where someone else can use it. The goal is not a giant automation system. The goal is one narrow process that another person can follow without needing the original author beside them. As you move through the session, keep one recurring task in mind. Something small, common, and frustrating is ideal. We are moving from “that answer was helpful” to “this is a capability the business can use again.”Participant recap, exercise, and public sourcesRECAPThis session turns a useful AI answer into a repeatable business process. The goal is a small process another person can run and test.TRY ITChoose one recurring task that wastes time or produces inconsistent results. Keep the first version narrow enough to test today.
2. Same request. Different context.Expanded talk trackThese two responses began with the same fictional request. The difference was the context available to the AI. A blank chat could write something plausible, but it had no approved business policy, no current customer facts, and no named owner for scheduling or safety decisions. The prepared Project could point to dated sources, preserve an unanswered safety question as unknown, and leave the commitment with the correct human role. That does not make a Project automatically correct. Bad or outdated source material can still produce a confident answer. The value is that the answer can show where its facts and rules came from, which gives us something to inspect. Ask yourself: which statement in the blank response sounds reasonable but has no business source behind it? Better prompting may improve one answer. A reliable context home makes approved knowledge available across related tasks. That is the difference we will build on throughout this session.Participant recap, exercise, and public sourcesRECAPThe same request can produce a different answer when the AI has access to approved context, business rules, and examples. Context improves relevance, but it does not prove that the source material is current or correct.TRY ITRun one safe, fictional, or sanitized request in a blank chat. Then run the same request in a Project with approved sources. Compare what each answer can cite and which decisions still require a person.PUBLIC SOURCESOpenAI: Projects in ChatGPThttps://help.openai.com/en/articles/10169521-projects-in-chatgpt
3. Probabilistic judgment and deterministic executionExpanded talk trackAI is useful when the work requires interpretation, comparison, drafting, or judgment. It can summarize a request, identify missing information, suggest a structure, or compare options. Those are tasks where more than one reasonable answer may exist. Other parts of a workflow need a hard guarantee. A total must add correctly. A spending limit must hold. A permission must block an unauthorized action. A required approval must occur before anything is sent or purchased. Put those exact parts in formulas, code, business rules, permissions, or a named approval step. A Project can improve the information available to the model. Testing can reveal gaps. A reusable package can preserve steps. None of those turns a language model into a calculator or policy engine. Try splitting one of your workflows into two columns: “judgment” and “must be exact.” Let AI support the first column. Put the guarantee for the second column outside the model.Participant recap, exercise, and public sourcesRECAPLanguage models are useful for interpretation, comparison, drafting, and other judgment work. Exact calculations, limits, permissions, and required approvals belong in formulas, code, rules, or explicit human gates.TRY ITSplit one workflow into two columns: judgment work and exact work. Assign the exact work to a deterministic system or named approver.
4. A Project gives the work a home.Expanded talk trackA Project is a home for related work, not one endless conversation. It can hold approved instructions, examples, and source material that should remain available across several tasks. A focused chat still handles one outcome at a time. The important distinction is authority. A policy may define required fields and who can approve a commitment. A customer brief can supply facts about one request. An example can show preferred formatting. Those sources do not all have the same job, and an attractive example cannot authorize a promise. The next layer is the tested process: a small set of steps that survives both a routine case and a case designed to expose a missing rule. Only after that path works should we package it into a reusable Skill, Gem, template, or tool. Think of the Project as the workbench. The tested process is the proof that the workbench produces something another person can actually use.Participant recap, exercise, and public sourcesRECAPA Project can hold approved sources and instructions for related work. A focused chat handles one outcome. A tested process proves whether the steps survive real cases before anyone packages them into a reusable tool.TRY ITCreate a Project only after you can name its purpose, approved sources, decision owners, privacy boundary, and first test case.PUBLIC SOURCESOpenAI: Projects in ChatGPThttps://help.openai.com/en/articles/10169521-projects-in-chatgpt
5. Learn it. Try it. Test it. Teach it.Expanded talk trackThis four-part loop is the spine of the workshop. Learn it means grounding the task in approved sources, real examples, and the decisions the business has already made. Try it means running one contained, low-risk case rather than asking the AI to solve the entire department at once. Test it means using a contrasting case that could reveal a missing field, unclear owner, unsupported promise, or point where the process should stop. Teach it means writing the repaired steps so another person or a fresh chat can follow them. The test matters because a fluent answer can look expert even when the process underneath is incomplete. Confidence is not evidence. Before you write your own card, choose one routine case and one exception. The routine case checks whether the basic path works. The exception checks whether the process recognizes its limits. We learn against a source and a test, not against the model’s confidence.Participant recap, exercise, and public sourcesRECAPThe working loop is Learn it, Try it, Test it, Teach it. Learn from sources and examples, try one contained case, attack the process with a contrasting case, then write a card another person can follow.TRY ITPick one routine case and one exception case before you start writing the process. The exception should expose a missing rule or a point where the workflow must stop.
6. The customer clicked. Now what?Expanded talk trackThe fictional customer message looks simple: they want service and they want a quick response. The business still needs more information before it can route the request or promise anything. Start by separating four categories. First, what facts did the customer actually provide? Second, what required inputs are still missing? Third, which business rules govern the next step? Fourth, which decisions belong to a person? A customer-supplied document or image may reveal equipment labels, access details, or the wording of the request. It cannot prove the current condition of the equipment, that a site is safe, or that an appointment has been approved. Keep unknown information labeled unknown. Before offering timing, price, scope, or a technical conclusion, identify the owner who has authority to make that commitment. Ask the room: what would you need before promising an appointment? A useful response begins by separating visible facts, missing inputs, and owner decisions.Participant recap, exercise, and public sourcesRECAPA customer request rarely contains every fact the business needs. Separate visible customer facts, missing inputs, governing business rules, and decisions owned by a person.TRY ITFor your task, list the required fields before drafting the response. Mark unknown items as unknown. Do not treat a customer's request as authorization to promise timing, price, safety, or scope.
7. The interview reveals decisions.Expanded talk trackThe AI interview is useful when it exposes the small number of answers that materially change the process. Cap it at five questions. If a question does not change the next step, decision owner, stop rule, or completion check, it probably does not belong in the first version. Before the AI drafts anything, have it name the source it is relying on and what authority that source has. Then turn the answers into a one-page Process Card: the outcome, the trigger, required inputs, sources or owners, five to seven steps, decision points, a stop rule, and an observable completion check. Watch for explicit owner markers. If scheduling, pricing, safety, or scope requires a human decision, the card should say so rather than smoothing over the gap. The interview can discover where the business needs a rule, but it cannot invent that rule on the business’s behalf. The business supplies the answer and keeps the authority.Participant recap, exercise, and public sourcesRECAPA short interview can reveal the rules that matter. The AI may ask questions, but the business supplies the answers and retains authority over material decisions.TRY ITLimit the interview to five questions that would actually change the next step. Build a one-page card with an outcome, trigger, inputs, sources or owners, five to seven steps, decision points, a stop rule, and a completion check.
8. A routine case checks the happy path.Expanded talk trackNow run the card using a common, low-risk case. Give the person or fresh chat only the card and the named source. Do not silently fill in missing instructions from your own knowledge. Check four things. Did the case reach the intended next action? Is the next owner clear? Did the result avoid unsupported commitments? Did any stop rule that should have fired actually fire? A good routine result records known facts, preserves unknowns as unknown, and routes the request without inventing certainty. For example, an unanswered safety question should remain unanswered and become a required follow-up. It should not quietly become “safe.” One successful run does not certify the process. It only shows that the basic sequence was executable for that case. Record what passed, what required interpretation, and where the card still depended on the author’s unstated knowledge. The exception case is where we find out whether the process knows its limits.Participant recap, exercise, and public sourcesRECAPA routine case checks whether the normal path works. One friendly pass proves only that the basic sequence is executable.TRY ITRun the card with a common request. Check whether known facts are recorded, unknowns stay unknown, the next owner is clear, and the result avoids unsupported commitments.
9. The exception exposes the missing rule.Expanded talk trackAn exception case should pressure the process at the point where continuing normally would be wrong. Use a missing field, conflicting instruction, safety concern, unusual deadline, or approval boundary. Run the case exactly as written and do not rescue the card with knowledge that never made it onto the page. If the card continues when it should stop, identify the first failing step. Then make the smallest repair that fixes the failure. Sometimes the card was unclear. Sometimes the governing source lacked a rule. Sometimes the decision owner was never named. Repair the correct layer and rerun the same case. The improved process should stop, route, or request approval without diagnosing a situation or promising an outcome it cannot verify. This is a process-design exercise, not professional safety guidance. Ask: where should this workflow stop instead of trying harder? A process begins to earn trust when it survives a case designed to break it.Participant recap, exercise, and public sourcesRECAPAn exception case tests whether the process knows when to stop. Repair the reusable card or governing source, then rerun the same case.TRY ITCreate one edge case with a missing field, conflicting instruction, safety concern, unusual deadline, or approval boundary. Record the first step that fails and the smallest repair that fixes it.
10. AI can work from what you see.Expanded talk trackA screenshot can give an AI useful visual context when you are dealing with an unfamiliar screen, a confusing error, or a formatting problem. Treat the image as input, not proof. Crop away everything the task does not need. Remove customer names, account numbers, notifications, unrelated tabs, and private messages. Ask the AI to describe only what is visible before it interprets the cause. Then ask it to separate observations from assumptions and suggest one next step. A screenshot cannot prove the current state of the underlying system, the meaning of a legal notice, the safety of equipment, or what will happen after a consequential click. Use it to orient yourself, then verify against the real application or authoritative source. Before actions such as Send, Submit, Buy, Delete, or Publish, stop and confirm the target and expected result. Show the model what you see, then verify what the image cannot prove.Participant recap, exercise, and public sourcesRECAPA screenshot can help the AI orient to an unfamiliar screen, error, or formatting issue. It cannot prove system state, safety, legal meaning, or the result of a consequential click.TRY ITCrop and redact first. Ask the AI to describe only what is visible, separate observation from inference, and give one next step. Verify before Submit, Send, Buy, Delete, or Publish.
11. Quote Hammer uses both engines.Expanded talk trackThis example combines two kinds of work. AI can help a person design the structure, identify required inputs, document the workflow, and explain what each section should do. A deterministic calculator owns the arithmetic. Governed settings and a price list supply approved inputs. Formulas and lookups calculate the result. A clean output presents it to the user. Documentation explains how to operate and check the system. The important test is a known case: enter a fixed set of inputs and compare the result with an expected total. If the numbers do not match, repair the formula or governed input. Do not ask the language model to guess its way to the right total. This workshop example does not claim that any sample rate, tax treatment, or business rule is ready for production. AI can help make the calculator, but the language model should not impersonate the calculator. Exact work needs an exact engine and a human review of the governing assumptions.Participant recap, exercise, and public sourcesRECAPAI can help design a spreadsheet or calculator, while formulas own the arithmetic and a person verifies inputs, policy, and known cases. The workshop's Quote Hammer example is intentionally not linked because public access was not verified.TRY ITGive a calculator one known input with an expected result. If it fails, repair the formula or governed input rather than asking the language model to guess the total.
12. A Skill packages a process that already works.Expanded talk trackA reusable Skill, Gem, or similar package should preserve a process that has already passed testing. Consider an invoice workflow. A customer name and total are not enough. The process may need a template, required fields, approved pricing and tax sources, payment terms, numbering rules, a stop when information is missing, and a visual check of the finished document. Package those ingredients only after the underlying card works for a routine case and an exception. The product names on this slide are examples of ways different platforms package reusable context and instructions. Features, labels, plan eligibility, and regional access can change, so check the linked product documentation before choosing a platform or teaching a live exercise. The principle remains stable even when the product menu changes: do not hide an untested guess inside a polished reusable tool. Test the process first. Package the stable path second.Participant recap, exercise, and public sourcesRECAPA reusable Skill, Gem, or similar package should contain a process that already works. It needs approved sources, required fields, decision owners, stop rules, examples, and checks.TRY ITPackage only after the card passes a routine case and an exception. Product names and plan availability change, so confirm the current documentation before choosing a platform.PUBLIC SOURCESOpenAI: Skills in ChatGPThttps://help.openai.com/en/articles/20001066Anthropic: Use skills in Claudehttps://support.claude.com/en/articles/12512180-use-skills-in-claudeGoogle: Use Gems in Gemini Appshttps://support.google.com/gemini/answer/15146780Google: Organize projects with notebooks in Gemini Appshttps://support.google.com/gemini/answer/16972047
13. Choose one repeated task.Expanded talk trackChoose one task you actually repeat. It might be preparing a meeting summary, checking an intake form, drafting a follow-up, formatting a recurring report, or reviewing a public document against a checklist. Everyone uses the same artifact: a Tested Process Card. The levels change the depth, not the assignment. Base captures a routine path. Stretch adds one exception and repairs the card. Pioneer adds a deterministic check for something that must be exact. A live Project is optional; paper or an ordinary chat is enough. Use public, fictional, generic, approved, minimized, or sanitized material. Keep sensitive, regulated, privileged, and secret information out of this first test. Narrow the job until you can run it during the workshop. One small artifact that reaches a clear next action is more useful than an impressive workflow that cannot be tested. Pick the task, then name its source, decision owner, and completion check.Participant recap, exercise, and public sourcesRECAPEvery participant builds the same artifact: a Tested Process Card. Base completes the routine path, Stretch adds one exception, and Pioneer adds a deterministic check.TRY ITUse public, fictional, generic, approved, minimized, or sanitized material. Keep sensitive, regulated, privileged, and secret information out of the exercise.
14. Build the card. Test as you go.Expanded talk trackUse this work period to make the smallest card that can survive a test. Start with the outcome and trigger. Add the required inputs and the source or person that governs each material decision. Write five to seven steps in plain language. Add the point where the process must stop, escalate, or ask for approval. Finish with something observable that proves the task is complete. If the AI produces a long interview, trim it. Keep only questions that change the process, owner, stop rule, or completion check. As you build, keep returning to three coaching questions: What source governs this? Who owns this decision? What proves the task is complete? Test pieces as you write them rather than waiting for a polished final card. If you finish early, add one exception. A small process that another person can run is the win. A complete-looking process that depends on unwritten knowledge is not ready.Participant recap, exercise, and public sourcesRECAPBuild around three questions: Which source governs the answer? Who owns the material decision? What observable result means the work is complete?TRY ITIf the AI produces a long questionnaire, stop it. Keep only questions whose answers change the process, owner, stop rule, or completion check.
15. The card passes only when the case passes.Expanded talk trackHand the card to a partner or a fresh chat with only the named source and the prepared case. The author may not explain what the card was supposed to mean. That rule is intentionally uncomfortable. It reveals which steps exist only in the author’s head. Check whether the case reaches the expected next action, every material decision points to a source or owner, the response makes no unsupported commitment, and the stop rule fires when required. Mark each check PASS or REPAIR. If something fails, name the exact step where the reader got stuck or made an unsupported inference. This is not a certification of legal, tax, safety, or professional correctness. It is a test of whether the process is executable and respects its authority boundaries. Ask the partner: where did you need the author to help? If the process only works when its creator stands beside it, it is not ready to hand off.Participant recap, exercise, and public sourcesRECAPA card passes when the case reaches the expected next action, every material decision points to a source or owner, no unsupported commitment appears, and the stop rule fires when required.TRY ITGive a partner or fresh chat only the card, the named source, and the test case. Do not explain what you meant. Mark each check PASS or REPAIR and name the exact failing step.
16. Save the repair where future work can find it.Expanded talk trackThe test is useful only if the next run benefits from what you learned. Start by repairing the exact point that failed. If the process step was unclear, update the card. If the business rule itself was missing or outdated, update the approved source or instruction that future work will consult. Do not bury the correction inside one chat and assume everyone will remember it. Then write a next-use sentence: “When I next do this task, I will use this card, check this risk, and keep this decision with this person.” Put the card where the real task happens, not in a folder nobody opens. Schedule one low-risk use while the test is fresh. After that run, record one new failure or improvement and update the reusable source again. Corrections become valuable when the next person, the next chat, and Future You can actually find them.Participant recap, exercise, and public sourcesRECAPA repair becomes reusable only when future work can find it. Update the governing source when the business rule changed, and update the card when the process step was unclear.TRY ITFinish this sentence: When I next do [task], I will use [card], check [risk], and keep [decision] with [person]. Put the card beside the real task and schedule one trial.
17. Useful answers become business capability.Expanded talk trackThe progression across the series is now visible. Clear requests and verification improve the individual interaction. Approved context makes the result fit the business. A tested card turns that context into a process another person can run. A Project keeps relevant sources available. Routine and exception tests expose the gaps. A reusable package preserves the stable path. Formulas, code, permissions, and approval gates own the parts that must be exact. None of those removes human judgment. They make it clearer where judgment belongs and what evidence supports it. Before you leave, choose the next real use for your card. Keep it small and safe. After the run, capture what failed or changed and repair the reusable source instead of leaving the lesson inside one conversation. If nobody else can follow the process and nothing can test it, you have useful notes. You do not yet have a business capability.Participant recap, exercise, and public sourcesRECAPUseful answers become business capability when the process can be handed off and tested. Projects hold context, tests expose gaps, reusable packages hold stable steps, and deterministic tools own exact work.TRY ITPick the next real use now. After that run, capture one failure or improvement and update the reusable source instead of leaving the lesson in a single chat.
18. Sources and takeawaysExpanded talk trackUse this final slide as a source map and a reminder to recheck product details. The linked public pages explain the product capabilities referenced in the workshop. The Tested Process Card beside the presentation is the take-home artifact. Features, product labels, plan access, and regional availability can change, so confirm the current documentation before you build a workshop exercise or commit your process to one platform. The broader method does not depend on a particular vendor: use approved context, name decision owners, test a routine case, test an exception, repair the correct source, and keep exact guarantees outside the language model. When reviewing any claim from the session, ask what source supports it, when that source was current, and what it does not prove. The goal is not to memorize a product menu. The goal is to leave with a process you can inspect, test, and improve.Participant recap, exercise, and public sourcesRECAPThese public product pages support the capability examples used in the workshop. The Tested Process Card PDF is included beside this deck. Private StarForge files, local build paths, the fictional VoltGuard source packet, and the unverified-access spreadsheet were intentionally not linked.TRY ITBefore re-hosting or delivering the session, recheck the product pages because features, plan eligibility, and labels can change.PUBLIC SOURCESOpenAI: Projects in ChatGPThttps://help.openai.com/en/articles/10169521-projects-in-chatgptOpenAI: Skills in ChatGPThttps://help.openai.com/en/articles/20001066Anthropic: Use skills in Claudehttps://support.claude.com/en/articles/12512180-use-skills-in-claudeGoogle: Use Gems in Gemini Appshttps://support.google.com/gemini/answer/15146780Google: Organize projects with notebooks in Gemini Appshttps://support.google.com/gemini/answer/16972047
