Give an AI demo that changes minds.
Sometimes the only way to convince someone that AI is worth exploring is to show them. The most useful demonstration starts with something that person cares about: their work, a problem they keep running into, or a decision they need to make. Build something they can imagine using.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How to run it
Choose a colleague or other stakeholder who's skeptical of AI. Tell your AI about their work and what they care about, using the prompt below. It will look for relevant context it can access and help you brainstorm a few quick tools. You can start with a rough description; you don't need a polished brief.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. ### Find a demonstration that matters to this person Help me prepare and give an AI demonstration for a skeptical colleague or other key stakeholder. Begin by asking: “Please tell us about a colleague or other key stakeholder who's very skeptical of AI. Walk us through their work and what they care about and let's brainstorm some quick tools we can build for them.” Wait for my answer. Treat this as an invitation to a conversation, not a questionnaire. Ask subsequent questions one at a time when they help. ### Understand their work and what would count as useful Use the person, role, project and issue names I supply to search relevant accessible emails, chats and other messages, meeting transcripts, calendar invitations, project documents and work data. Look for the work they actually do, recurring frustrations, decisions they face, goals they are responsible for, their stated objections to AI, and the examples or evidence they find persuasive. Use calendar and attendee information to understand the demonstration's audience and setting when that matters. Try relevant connections before asking me to reconstruct accessible history; stay within records relevant to this person and purpose. Show me a concise account of what seems to matter to them, with source references for important findings. Distinguish their expressed concerns from your interpretation. If records are unavailable, use my description and a relevant example I can supply; label unconfirmed assumptions. Ask me to correct material gaps before choosing a demonstration. Do not assume that a skeptical person needs a generic introduction or that their skepticism has the same cause as someone else's. ### Brainstorm quick tools they might want to use Suggest a few concrete tools rooted in that person's work. For each, explain the problem it addresses, what we would put in, what the person could do with the result, and the moment we could demonstrate live. Possibilities include a small website or app that assembles scattered information in one place, explores alternative budget cuts and their consequences, or helps inspect which customers are most expensive to serve. These are examples to adapt, not required projects. For financial examples, establish which costs and definitions the data actually supports; don't substitute revenue for cost to serve or invent savings. Favor a small, useful working tool with a clear interaction the person can try. Identify what source files, examples and data it needs and what you can gather yourself. Inspect your available building, file, browser and delivery tools to determine what can actually be made and shown here. Recommend a demonstration and explain why it fits this person; wait for my choice before building it. ### Prepare the build and the live demonstration Turn the chosen idea into a short specification: intended user, useful action, inputs, output and a concrete example that would show it works. Agree the important choices with me. Gather the usable source material and put the examples, data and build instructions together in one accessible place. Identify what is already prepared and what we will build live. If sample data is needed, label it clearly and keep claims about actual company results separate. Build and try the demonstration in advance so we know the task fits the available tools and time. Exercise the central interaction with a representative input, check the output against the sources or expected result, inspect the actual screen, and fix problems. Prepare a clean starting point for rebuilding the useful part live, along with the checked finished version we can show. Explain any prepared components plainly in the run-through. If the build belongs in a different tool, first work out a supported route. Prepare a complete handoff containing the chosen problem, specification, sources or files, decisions, exact build tasks, sample input, expected behavior and completion checks. Guide me through only the transfer or access steps you cannot perform, then continue through the returned build and verification. A handoff or specification alone does not complete the working demonstration. For a larger preparation task, use bounded assignments where available and useful: one agent can inspect a defined set of source records, another can implement an agreed component after the specification is settled. Give each its inputs, source references, deliverable and completion check; reconcile results yourself. Carry decisions, files, remaining work and check results into a fresh session if needed. ### Rehearse for this audience Prepare a short run of show: the recognizable problem, the example we start with, the useful part we build live, the result, and an invitation for the person to try a variation from their own work. Put the exact starting prompt and needed materials within easy reach. Keep the focus on their work rather than a tour of AI features. When a separate reviewer is available and useful, give it the actual demonstration and the documented audience context with source references, without your sales pitch. Ask what is clear, what remains unproven, and what someone with those concerns might ask. Label this as a simulated perspective, not the person's reaction. Resolve material findings and rehearse likely questions. Otherwise do a separate review pass and don't call it independent. Give me the checked tool, the organized preparation materials and the short run of show. Wait while I give the demonstration. Afterwards ask what the person actually tried, asked or said; distinguish that from what we expected. Help refine the tool or explanation in response. Do not claim that their mind changed without their response. Finish with the actual outcome and the useful tool they can return to. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
Choose a tool that makes a useful point quickly. A small website or app might put scattered information in one place, let someone explore possible budget cuts, or show which customers are most expensive to serve. Pick something grounded in this person's actual work. The AI will help gather the examples and data, build a version you can try, and prepare the live demonstration. Keep everything you need together so you're ready to begin.
Practice once, including the part you'll build live. Know what you'll type, what information you'll give the AI, and how you'll show that the result works. Have the checked finished version available too. Your AI can help prepare the demonstration and anticipate questions; you bring your knowledge of the person.
Give the demonstration. Start with the problem they recognize, build the useful part in front of them, then invite them to try it or suggest a variation. Let their questions guide the conversation. Afterwards, tell your AI what they actually said and tried so it can help improve the tool or the next demonstration.
How it goes
What the AI will do
- Investigate the stakeholder's work and expressed concerns, then brainstorm relevant quick tools.
- Build and check the chosen demonstration, organize its materials and help you rehearse.
What to have ready
- A skeptical colleague or stakeholder, what you know about their work, and any useful example or accessible source material.
Where you come in
- Correct the audience context, choose the tool and try the rehearsal.
- Give the live demonstration, invite the person's response and report what happened.
What you'll get
A working tool relevant to the person, a prepared live demonstration and their actual response to it.
You're done when
You've given the demonstration, the person has had an opportunity to try or question a working tool relevant to them, and you know what they actually found useful or still want to understand.
View full AI instructions
Give an AI demo that changes minds.
Sometimes the only way to convince someone that AI is worth exploring is to show them. The most useful demonstration starts with something that person cares about: their work, a problem they keep running into, or a decision they need to make. Build something they can imagine using.
Step 1 — For the user
Choose a colleague or other stakeholder who's skeptical of AI. Tell your AI about their work and what they care about, using the prompt below. It will look for relevant context it can access and help you brainstorm a few quick tools. You can start with a rough description; you don't need a polished brief.
Step 2 — For the user
Choose a tool that makes a useful point quickly. A small website or app might put scattered information in one place, let someone explore possible budget cuts, or show which customers are most expensive to serve. Pick something grounded in this person's actual work. The AI will help gather the examples and data, build a version you can try, and prepare the live demonstration. Keep everything you need together so you're ready to begin.
Step 3 — For the user
Practice once, including the part you'll build live. Know what you'll type, what information you'll give the AI, and how you'll show that the result works. Have the checked finished version available too. Your AI can help prepare the demonstration and anticipate questions; you bring your knowledge of the person.
Step 4 — For the user
Give the demonstration. Start with the problem they recognize, build the useful part in front of them, then invite them to try it or suggest a variation. Let their questions guide the conversation. Afterwards, tell your AI what they actually said and tried so it can help improve the tool or the next demonstration.
Done when
You've given the demonstration, the person has had an opportunity to try or question a working tool relevant to them, and you know what they actually found useful or still want to understand.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Find a demonstration that matters to this person
Help me prepare and give an AI demonstration for a skeptical colleague or other key stakeholder. Begin by asking: “Please tell us about a colleague or other key stakeholder who's very skeptical of AI. Walk us through their work and what they care about and let's brainstorm some quick tools we can build for them.” Wait for my answer. Treat this as an invitation to a conversation, not a questionnaire. Ask subsequent questions one at a time when they help.
Understand their work and what would count as useful
Use the person, role, project and issue names I supply to search relevant accessible emails, chats and other messages, meeting transcripts, calendar invitations, project documents and work data. Look for the work they actually do, recurring frustrations, decisions they face, goals they are responsible for, their stated objections to AI, and the examples or evidence they find persuasive. Use calendar and attendee information to understand the demonstration's audience and setting when that matters. Try relevant connections before asking me to reconstruct accessible history; stay within records relevant to this person and purpose.
Show me a concise account of what seems to matter to them, with source references for important findings. Distinguish their expressed concerns from your interpretation. If records are unavailable, use my description and a relevant example I can supply; label unconfirmed assumptions. Ask me to correct material gaps before choosing a demonstration. Do not assume that a skeptical person needs a generic introduction or that their skepticism has the same cause as someone else's.
Brainstorm quick tools they might want to use
Suggest a few concrete tools rooted in that person's work. For each, explain the problem it addresses, what we would put in, what the person could do with the result, and the moment we could demonstrate live. Possibilities include a small website or app that assembles scattered information in one place, explores alternative budget cuts and their consequences, or helps inspect which customers are most expensive to serve. These are examples to adapt, not required projects. For financial examples, establish which costs and definitions the data actually supports; don't substitute revenue for cost to serve or invent savings.
Favor a small, useful working tool with a clear interaction the person can try. Identify what source files, examples and data it needs and what you can gather yourself. Inspect your available building, file, browser and delivery tools to determine what can actually be made and shown here. Recommend a demonstration and explain why it fits this person; wait for my choice before building it.
Prepare the build and the live demonstration
Turn the chosen idea into a short specification: intended user, useful action, inputs, output and a concrete example that would show it works. Agree the important choices with me. Gather the usable source material and put the examples, data and build instructions together in one accessible place. Identify what is already prepared and what we will build live. If sample data is needed, label it clearly and keep claims about actual company results separate.
Build and try the demonstration in advance so we know the task fits the available tools and time. Exercise the central interaction with a representative input, check the output against the sources or expected result, inspect the actual screen, and fix problems. Prepare a clean starting point for rebuilding the useful part live, along with the checked finished version we can show. Explain any prepared components plainly in the run-through.
If the build belongs in a different tool, first work out a supported route. Prepare a complete handoff containing the chosen problem, specification, sources or files, decisions, exact build tasks, sample input, expected behavior and completion checks. Guide me through only the transfer or access steps you cannot perform, then continue through the returned build and verification. A handoff or specification alone does not complete the working demonstration.
For a larger preparation task, use bounded assignments where available and useful: one agent can inspect a defined set of source records, another can implement an agreed component after the specification is settled. Give each its inputs, source references, deliverable and completion check; reconcile results yourself. Carry decisions, files, remaining work and check results into a fresh session if needed.
Rehearse for this audience
Prepare a short run of show: the recognizable problem, the example we start with, the useful part we build live, the result, and an invitation for the person to try a variation from their own work. Put the exact starting prompt and needed materials within easy reach. Keep the focus on their work rather than a tour of AI features.
When a separate reviewer is available and useful, give it the actual demonstration and the documented audience context with source references, without your sales pitch. Ask what is clear, what remains unproven, and what someone with those concerns might ask. Label this as a simulated perspective, not the person's reaction. Resolve material findings and rehearse likely questions. Otherwise do a separate review pass and don't call it independent.
Give me the checked tool, the organized preparation materials and the short run of show. Wait while I give the demonstration. Afterwards ask what the person actually tried, asked or said; distinguish that from what we expected. Help refine the tool or explanation in response. Do not claim that their mind changed without their response. Finish with the actual outcome and the useful tool they can return to.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.