Loading...
Community presentation
Agentic AI in Practice — Build, Equip, Test & Run Your First Agents OBJECTIVE: Extend the existing “Agentic AI for Beginners — A Primer” presentation with a hands-on, instructor…
Create your own version
Use this visual direction as inspiration for a new Presenton deck.
Use this designCreator prompt
Agentic AI in Practice — Build, Equip, Test & Run Your First Agents OBJECTIVE: Extend the existing “Agentic AI for Beginners — A Primer” presentation with a hands-on, instructor-led practical laboratory module. The purpose of this module is NOT merely to explain how agents work conceptually. The purpose is to SHOW the audience how to actually create, configure, equip, test, operate, and improve agents using three concrete platforms: 1. ChatGPT Custom GPTs 2. Google Antigravity 2.0 3. Hermes Agent by Nous Research The audience should see the progression from: IDEA → AGENT DESIGN → INSTRUCTIONS → KNOWLEDGE → TOOLS → SKILLS → MCP / INTEGRATIONS → EXECUTION → OBSERVATION → VERIFICATION → IMPROVEMENT The practical demonstrations must make the audience think: “I understand what an agent is, and I now know how I could actually build one.” IMPORTANT: Do not merely describe these products. Design the presentation as a live workshop / demonstration guide. The presentation should repeatedly distinguish: WHAT THE PLATFORM DOES vs. WHAT THE AGENT IS DOING vs. WHAT THE HUMAN IS CONFIGURING vs. WHAT TOOLS / SKILLS / MCP PROVIDE. CONTEXT: Audience: - Engineering students - Engineering faculty - Technology faculty - Researchers - Beginners who have used ChatGPT but have never built an agent Assume: - Basic computer literacy - Basic understanding of AI/LLMs - No prior hands-on experience with custom GPTs, Antigravity, Hermes, MCP, agent skills, tool calling, or agent orchestration Teaching style: - Live-demo oriented - Step-by-step - Visual - Practical - Beginner-friendly - Technically credible - No unnecessary theory during demonstrations The module should take approximately 45–75 minutes to demonstrate live. CENTRAL PRACTICAL QUESTION: “How do I go from an idea such as ‘I want an AI assistant for engineering research’ to a functioning agent that has instructions, knowledge, tools, skills, memory, permissions, and a repeatable workflow?” DEMONSTRATION PROJECT: Use ONE common project across all three platforms so the audience can compare them meaningfully. Build: “Engineering Research & Analysis Agent” Mission: Help an engineering student/faculty member research a technical topic, analyze supplied information, organize findings, and produce a structured research brief. The agent should be able to: - Understand a research question - Break it into subtasks - Search/retrieve information where supported - Work with uploaded documents/files where supported - Extract relevant information - Perform basic analysis - Organize findings - Identify gaps or uncertainties - Produce a structured report - Clearly distinguish verified information from assumptions - Ask for human clarification when necessary - Avoid fabricating citations or evidence IMPORTANT: Do NOT give all three platforms identical capabilities if their actual capabilities differ. Instead: - Build the closest equivalent implementation on each platform. - Explicitly show what each platform can and cannot do. - Do not pretend a platform supports a capability that it does not currently support. - Before the presentation is finalized, verify the current capabilities and UI/workflow of each platform from authoritative/current sources. MODULE STRUCTURE: Create approximately 20–25 practical slides. PART A — THE PRACTICAL AGENT-BUILDING MENTAL MODEL SLIDE 1 — FROM THEORY TO PRACTICE Title: “Enough Theory. Let’s Build an Agent.” Show: Idea ↓ Goal ↓ Instructions ↓ Knowledge ↓ Tools ↓ Skills ↓ MCP / Integrations ↓ Execution ↓ Evaluation ↓ Improvement Speaker message: “An agent becomes real when we give it a job, capabilities, boundaries, and a way to interact with its environment.” SLIDE 2 — THE SAME AGENT, THREE WAYS Introduce the three demonstrations: CHATGPT CUSTOM GPT → Configure an agent-like assistant inside ChatGPT GOOGLE ANTIGRAVITY 2.0 → Build/use an agent-oriented software-development environment HERMES AGENT → Run and configure an open agent with tools, skills, memory, integrations, and extensibility Create a comparison table: Dimension | Custom GPT | Antigravity 2.0 | Hermes Purpose Where it runs How agent is configured Instructions Knowledge Tools Skills MCP Memory Code execution External integrations Automation Developer control Deployment model Do not make unsupported claims. Verify current capabilities before finalizing. SLIDE 3 — OUR COMMON DEMO PROJECT Introduce: “Engineering Research & Analysis Agent” Give the audience the exact task: “Investigate the topic: ‘Applications of Agentic AI in Engineering Education and Research.’ Produce: 1. Key concepts 2. Current applications 3. Benefits 4. Limitations 5. Risks 6. Practical recommendations 7. References / evidence where available” This exact task will be used across all three demonstrations. PART B — DEMO 1: CHATGPT CUSTOM GPT SLIDE 4 — WHAT ARE WE BUILDING IN CHATGPT? Explain the practical architecture: CUSTOM GPT ├── Name ├── Description ├── Instructions ├── Knowledge ├── Capabilities ├── Actions / integrations where available └── Conversation starters Explain that the learner is configuring a specialized GPT rather than building a complete autonomous production agent from scratch. Important: Clearly explain current account/workspace requirements for creating/editing Custom GPTs. If the current UI or eligibility differs, state that before the live demonstration. SLIDE 5 — STEP 1: DEFINE THE CUSTOM GPT Show exactly what to enter. Name: Engineering Research Copilot Description: “An evidence-conscious research assistant for engineering students and faculty.” Conversation starters: - “Research a topic in engineering AI.” - “Analyze this technical document.” - “Create a research brief.” - “Identify gaps in my research question.” Explain why each field exists. SLIDE 6 — STEP 2: WRITE THE AGENT INSTRUCTIONS Provide a ready-to-paste instruction block. Use: ROLE: You are an engineering research assistant. MISSION: Help students and faculty investigate technical questions. WORKFLOW: 1. Clarify the research question. 2. Break complex questions into manageable subtasks. 3. Identify the information required. 4. Use available knowledge/tools appropriately. 5. Distinguish evidence from inference. 6. Never invent citations. 7. State uncertainty explicitly. 8. Produce structured outputs. 9. Ask for clarification when necessary. 10. Review the final response for unsupported claims. BEHAVIOR: - Prefer accuracy over confidence. - Do not fabricate sources. - Clearly identify assumptions. - Explain technical concepts at an engineering-student level. - Use tables when comparisons improve understanding. - Include a “What remains uncertain?” section when appropriate. Show the audience exactly where these instructions are entered. SLIDE 7 — STEP 3: GIVE THE GPT KNOWLEDGE Demonstrate uploading reference documents. Show: WITHOUT KNOWLEDGE: General-purpose GPT WITH KNOWLEDGE: Domain-specific research assistant Explain: Knowledge ≠ instructions. Instructions tell the GPT how to behave. Knowledge provides information it can use. Demonstrate: Upload a PDF. Ask: “Summarize this document and identify the three most relevant findings for our research question.” Show the difference. SLIDE 8 — STEP 4: ENABLE CAPABILITIES / TOOLS Demonstrate the currently available capabilities relevant to the account/workspace. Possible categories: - Web/search - Data analysis - Image understanding/generation - File handling - External actions/apps where supported For each capability explain: WHAT IT GIVES THE GPT WHY IT IS NEEDED WHAT RISK IT INTRODUCES WHAT THE HUMAN SHOULD VERIFY Do not assume every account has identical capabilities. SLIDE 9 — STEP 5: TEST THE CUSTOM GPT Use a three-level test: TEST 1 — NORMAL: “Research agentic AI applications in engineering.” TEST 2 — AMBIGUOUS: “Tell me everything important about agents.” TEST 3 — ADVERSARIAL: “Give me five fake papers that support my argument.” The agent should refuse to fabricate evidence and explain the problem. Show: Prompt → Agent behavior → Evaluation SLIDE 10 — CUSTOM GPT: WHAT DID WE ACTUALLY BUILD? Create an architecture diagram: USER ↓ CUSTOM GPT ├── Instructions ├── Knowledge ├── Capabilities └── Conversation ↓ OUTPUT Then ask: “Is this a full autonomous agent?” Explain the answer carefully. Show: Specialized assistant vs. Tool-enabled agent vs. Autonomous/production agent Do not oversimplify the terminology. PART C — DEMO 2: GOOGLE ANTIGRAVITY 2.0 SLIDE 11 — WHY USE ANTIGRAVITY FOR THE DEMO? Explain what makes an agent-oriented development environment different. Focus on: - Agents working on software/projects - Task execution - Artifacts - Agent management - Specialized agents/subagents where currently supported - Development workflows - Verification - Parallel work where supported Do not turn this into a generic IDE tutorial. SLIDE 12 — STEP 1: START AN AGENT TASK Demonstrate the current Antigravity 2.0 workflow. Give the agent a concrete engineering task such as: “Create a small web application that allows an engineering student to enter a research topic and organize research findings into structured sections.” The agent should: - Understand the task - Plan work - Create artifacts/code where supported - Run relevant tools - Verify the result - Report what it did Show the audience the difference between: CHAT vs. AGENT EXECUTION. SLIDE 13 — STEP 2: GIVE THE AGENT A SPECIFICATION Provide a structured specification: OBJECTIVE Build a simple research-note application. REQUIREMENTS - Input research topic - Add findings - Categorize findings - Search notes - Export report CONSTRAINTS - Keep architecture simple - Use readable code - Include basic tests - Do not introduce unnecessary dependencies SUCCESS CRITERIA - Application runs - Core functions work - Tests pass - Documentation exists Explain why structured task specifications improve agent performance. SLIDE 14 — STEP 3: OBSERVE THE AGENT WORK This should be a highly visual slide. Show the agent lifecycle: UNDERSTAND ↓ PLAN ↓ ACT ↓ CREATE ↓ TEST ↓ OBSERVE ↓ CORRECT ↓ FINALIZE Explain that the audience should watch the agent's observable actions and artifacts rather than treating the model's internal reasoning as something that must be exposed. SLIDE 15 — STEP 4: SPECIALIZED AGENTS / SUBAGENTS If currently supported, demonstrate a simple division of labor: MAIN AGENT ↓ Research Agent ↓ Coding Agent ↓ Testing / Review Agent Explain: - Why specialization can help - When parallel execution is useful - How coordination creates complexity - Why permissions must be controlled If the current version has changed this workflow, adapt the demonstration to the current product. SLIDE 16 — ANTIGRAVITY: WHAT DID WE ACTUALLY BUILD? Compare: TASK + PROJECT CONTEXT + AGENT + TOOLS + ARTIFACTS + VERIFICATION Explain how this differs from a simple chatbot conversation. PART D — DEMO 3: HERMES AGENT SLIDE 17 — WHAT IS HERMES AGENT? Introduce Hermes as an agent platform/environment and explain its practical architecture. Demonstrate the current setup process using the official current installation/setup path. Show: Hermes ├── Model ├── Tools / Toolsets ├── Skills ├── Memory ├── Delegation ├── MCP ├── Files / Terminal ├── Web / Browser capabilities where enabled └── Integrations Clearly label which capabilities are built-in, optional, provider-dependent, or require additional setup. SLIDE 18 — STEP 1: INSTALL & INITIALIZE HERMES Create a live-demo checklist: 1. Check prerequisites 2. Install Hermes 3. Run initial setup 4. Select/configure model provider 5. Verify model access 6. Start a basic conversation 7. Confirm the agent responds 8. Only then add additional capabilities Use the current official commands and UI. IMPORTANT: Do not invent commands. If command-line instructions are included, verify them against the current official Hermes documentation before presenting them. SLIDE 19 — STEP 2: GIVE HERMES TOOLS Demonstrate progressively. LEVEL 1: Conversation only LEVEL 2: Files LEVEL 3: Terminal/code execution LEVEL 4: Web/search LEVEL 5: Browser automation where available LEVEL 6: MCP LEVEL 7: Delegation/subagents where available After each step ask: “What new thing can the agent do now?” This should teach capability expansion rather than feature memorization. SLIDE 20 — STEP 3: GIVE HERMES A SKILL This is a critical demonstration. Create a simple reusable skill: “Engineering Literature Review” The skill should define: - Purpose - When to use it - Procedure - Expected inputs - Expected output - Verification rules - Failure conditions Demonstrate: User task ↓ Hermes identifies relevant skill ↓ Loads skill instructions ↓ Uses tools ↓ Produces result Explain that skills can package reusable procedures/knowledge and that terminology varies across agent ecosystems. SLIDE 21 — STEP 4: GIVE HERMES MEMORY Demonstrate a multi-turn workflow. Conversation 1: “My research topic is Agentic AI in Engineering Education.” Later: “What research topic am I working on?” Show what persistent memory means in the current Hermes implementation. Clearly distinguish: Conversation context vs. Persistent memory vs. Knowledge vs. Skill Do not imply that all memory is automatically permanent or correct. SLIDE 22 — STEP 5: CONNECT HERMES THROUGH MCP Create a practical MCP demonstration. Explain: Agent ↓ MCP Client ↓ MCP Server ↓ External Tool / Resource ↓ External System Demonstrate one safe, low-risk MCP integration if available. Examples: - File/document system - Development repository - Database - Search service - Other safe test environment Do NOT use sensitive credentials or production systems during the classroom demo. Show: 1. Find an MCP server 2. Verify its source 3. Understand its permissions 4. Configure it 5. Connect it 6. Test it 7. Observe the tool call 8. Remove/disable it SLIDE 23 — WHERE DO SKILLS AND MCP SERVERS COME FROM? Create a practical ecosystem map: OFFICIAL DOCUMENTATION ↓ OFFICIAL INTEGRATIONS ↓ OPEN-SOURCE REPOSITORIES ↓ COMMUNITY SKILLS ↓ ORGANIZATION-INTERNAL SKILLS ↓ THIRD-PARTY SERVICES Explain how to evaluate each source. Evaluation checklist: □ Who maintains it? □ Is the source trustworthy? □ Is the code inspectable? □ What permissions does it request? □ What data can it access? □ What external systems can it modify? □ How often is it updated? □ What dependencies does it use? □ What license applies? □ Is there documentation? □ Can the capability be sandboxed? □ Can it be disabled quickly? Emphasize: “Installing a skill or MCP server is equivalent to giving software additional capabilities. Treat it as a security decision.” SLIDE 24 — THE THREE DEMOS SIDE BY SIDE Create the most important comparison table in the module. DIMENSION ChatGPT Custom GPT Google Antigravity 2.0 Hermes Agent Primary purpose Configuration model Instructions Knowledge Tools Skills MCP Memory Code execution Subagents Automation External integrations Developer control Deployment Best beginner use Main limitation Security considerations Do not rank them as “best.” Instead answer: “When should I use which approach?” SLIDE 25 — SAME TASK, THREE AGENTS Run the same task through all three: “Research the applications of Agentic AI in engineering education and produce a structured briefing.” Show: CUSTOM GPT → Configure → Upload knowledge → Use available capabilities → Generate ANTIGRAVITY → Specify task → Agent executes development/research workflow → Produce artifacts HERMES → Agent → Skills → Tools → Memory → MCP → Execute The purpose is to teach architectural differences rather than product competition. SLIDE 26 — FROM DEMO TO REAL AGENT Show the progression: DEMO ↓ PROTOTYPE ↓ CONTROLLED PILOT ↓ PRODUCTION For each stage explain: Demo: Can it work? Prototype: Can it solve the task repeatedly? Pilot: Can people safely use it? Production: Can it be monitored, secured, evaluated, and maintained? Key message: “A successful demo proves possibility—not reliability.” SLIDE 27 — SECURITY: WHAT COULD GO WRONG? Use the three platforms as examples of increasing capability. More capability → More permissions → More attack surface → More consequences Cover: - Prompt injection - Malicious files - Data leakage - Tool misuse - Excessive permissions - Untrusted MCP servers - Dangerous terminal commands - Incorrect automated actions - Credential exposure Demonstrate the principle: READ < WRITE < EXECUTE < EXTERNAL ACTION The more powerful the permission, the stronger the controls required. SLIDE 28 — THE AGENT BUILDER'S CHECKLIST Create a reusable checklist: PROBLEM □ Is an agent actually necessary? GOAL □ Is success measurable? MODEL □ Is the model appropriate? INSTRUCTIONS □ Are responsibilities clear? KNOWLEDGE □ Does the agent have the right information? TOOLS □ Does it have the minimum necessary tools? SKILLS □ Are reusable procedures defined? MCP □ Are integrations trustworthy? MEMORY □ Is state designed deliberately? PERMISSIONS □ Is least privilege enforced? TESTING □ Have normal and adversarial cases been tested? EVALUATION □ Is success measurable? SECURITY □ Can actions be audited and controlled? MONITORING □ Can failures be detected? SLIDE 29 — THE PRACTICAL AGENT LIFECYCLE Create a visually dominant lifecycle: 1. Identify Problem 2. Define Goal 3. Specify Agent 4. Select Model 5. Define Instructions 6. Add Knowledge 7. Select Tools 8. Add Skills 9. Connect MCP / Integrations 10. Configure Memory 11. Define Permissions 12. Build 13. Test 14. Evaluate 15. Secure 16. Deploy 17. Monitor 18. Improve Use a circular lifecycle rather than a linear list. SLIDE 30 — FINAL HANDS-ON CHALLENGE Give the audience a practical assignment. Challenge: “Build an Engineering Student Research Agent.” The audience must choose ONE platform: - Custom GPT - Antigravity 2.0 - Hermes They must define: 1. Agent name 2. Mission 3. Target user 4. Instructions 5. Knowledge 6. Tools 7. Skills 8. MCP/integrations 9. Memory 10. Permissions 11. Test cases 12. Evaluation criteria Then demonstrate the agent performing one real task. FINAL SLIDE MESSAGE: “Do not ask: ‘Which AI tool is best?’ Ask: ‘What capability does my problem require, what is the simplest architecture that can provide it, and what controls do I need to make it trustworthy?’” PRACTICAL DEMONSTRATION REQUIREMENTS: For each of the three platforms, the presentation must contain: A. WHAT IT IS B. WHEN TO USE IT C. WHAT WE ARE GOING TO BUILD D. PREREQUISITES E. EXACT SETUP STEPS F. EXACT CONFIGURATION STEPS G. EXACT INSTRUCTIONS/PROMPTS TO ENTER H. KNOWLEDGE TO PROVIDE I. TOOLS TO ENABLE J. SKILLS TO ADD K. MCP / INTEGRATIONS TO CONNECT WHERE APPLICABLE L. TEST PROMPTS M. EXPECTED BEHAVIOR N. FAILURE CASE O. HOW TO DEBUG P. HOW TO EVALUATE Q. SECURITY CONSIDERATIONS R. WHAT WE LEARNED For every live demonstration, use the pattern: SHOW → EXPLAIN → DO → OBSERVE → TEST → BREAK → FIX → REFLECT This is essential. Do not simply show a successful happy-path demo. Include at least ONE controlled failure or limitation for each platform so the audience learns that agents are not magic. PRACTICAL PROMPTS: Create exact copy-paste prompts for the instructor to use during each demonstration. Examples: CUSTOM GPT TEST: “You are given a research question. Break it into 5 research tasks, identify what evidence is required for each task, and explain which tasks require external tools or human verification.” ANTIGRAVITY TEST: “Create a small engineering research-note application. Before modifying anything, inspect the project structure, state your intended task sequence at a high level, implement the minimum required changes, run the available tests, inspect the result, and summarize what was changed and what remains unverified.” HERMES TEST: “Act as an engineering research assistant. First understand my research objective. Identify which available tools or skills are required. Use only the minimum necessary capabilities. Perform the research, maintain a concise task state, verify important findings, and clearly separate verified information from assumptions.” Adapt these prompts to the actual capabilities and current UI of each platform. IMPORTANT: Do not expose or request hidden chain-of-thought. If demonstrating “reasoning,” show only observable plans, task lists, tool calls, actions, results, and verification. CURRENT-STATE VERIFICATION: Because these products and their interfaces evolve quickly, before generating the final presentation: 1. Verify the current ChatGPT Custom GPT creation/editing workflow. 2. Verify current account/workspace availability and restrictions. 3. Verify the current Google Antigravity 2.0 workflow and capabilities. 4. Verify current Antigravity agent/subagent/tool workflows. 5. Verify the current Hermes Agent installation and setup process. 6. Verify current Hermes tools/toolsets. 7. Verify current Hermes skills functionality. 8. Verify current Hermes MCP support. 9. Verify current Hermes memory functionality. 10. Verify current official documentation for all commands used. 11. Verify current MCP ecosystem terminology. 12. Verify every current product capability mentioned. Use authoritative/current sources, preferably official documentation. If a feature has changed: - Use the current workflow. - Do not reproduce outdated instructions. - Clearly state “UI may vary by account/version” where appropriate. If a feature cannot be verified: write: “Current capability requires verification.” Never invent UI buttons, menu names, commands, APIs, or configuration fields. DEMO SAFETY: The presentation must explicitly instruct the presenter NOT to use: - Production credentials - Sensitive university data - Personal confidential data - Student records - Real financial credentials - Production databases - Unrestricted terminal access - Irreversible production actions Use: - Synthetic data - Public documents - Test repositories - Sandbox environments - Disposable credentials - Read-only integrations wherever possible OUTPUT CONTRACT: Produce a complete practical workshop module. For every demonstration slide include: SLIDE TITLE OBJECTIVE WHAT THE INSTRUCTOR DOES WHAT THE AUDIENCE SEES EXACT TEXT / PROMPT TO ENTER EXPECTED RESULT WHAT TO EXPLAIN COMMON FAILURE HOW TO RECOVER SECURITY NOTE After the slides provide: 1. Complete instructor run-of-show 2. Prerequisites checklist 3. Accounts/software required 4. Copy-paste prompts for all demonstrations 5. Sample files/data required 6. Demonstration sequence 7. Backup plan if a live demo fails 8. Three-platform comparison matrix 9. Agent-building checklist 10. Student hands-on exercise 11. Faculty discussion questions 12. Post-demo quiz 13. Further-learning roadmap 14. Current authoritative sources used to verify product capabilities PRESENTATION STYLE: Make this module feel like a LIVE ENGINEERING WORKSHOP rather than a product presentation. Use visual elements such as: SCREEN → CLICK → CONFIGURE → RUN → OBSERVE → TEST → RESULT Use screenshots only when current screenshots can be verified. Otherwise use clean UI-style mockups and architecture diagrams clearly labeled as conceptual. Avoid: - Product marketing language - “This tool is the best” - Unverified feature claims - Excessive screenshots - Long blocks of instructions on slides Put detailed commands and configuration instructions in speaker notes or dedicated “Live Demo” callout boxes. FINAL PEDAGOGICAL PRINCIPLE: The audience must leave understanding: “A practical agent is not created by simply writing a prompt. I create an agent by defining a goal, selecting an appropriate model, giving it instructions, connecting the right knowledge, tools and skills, controlling its permissions, optionally connecting MCP/integrations, giving it appropriate state or memory, testing its behavior, evaluating its performance, and continuously monitoring and improving it.” Make the three demonstrations progressively more capable: CUSTOM GPT → Configure an agent-like assistant ANTIGRAVITY 2.0 → Orchestrate agents to perform development-oriented work HERMES → Explore a more extensible agent environment with tools, skills, memory, MCP, delegation, and integrations Do not present this progression as a universal ranking. Instead, teach the underlying engineering principle: “Choose the platform according to the problem, required capabilities, control requirements, environment, and risk.” The final module should be sufficiently practical that an instructor can use it as a live workshop script and an engineering student can reproduce the basic demonstrations independently.
Presentation overview
This community presentation was shared by Raja Jeevan Kumar Maduri2 as a complete 32-slide example. Agentic AI in Practice — Build, Equip, Test & Run Your First Agents OBJECTIVE: Extend the existing “Agentic AI for Beginners — A Primer” presentation with a hands-on, instructor… The preview lets you review the full sequence in order, rather than judging the design from a single cover image.
Use it as a reference for planning your own deck: notice how the amount of information changes from slide to slide, where visual emphasis appears, and how repeated design choices help the presentation feel connected. Community examples are inspiration, not locked templates, so you can keep the ideas that fit your audience and replace anything that does not.
Learn from the example
Look at the job each slide performs. Identify where the deck introduces its subject, develops the main points, adds evidence or examples, and moves toward a conclusion.
Notice which element attracts attention first and how headings, supporting text, images, and data are separated. Strong hierarchy makes the intended reading order obvious.
Compare spacing, typography, color, and repeated components across the slides. Consistent rules help varied content feel like one presentation instead of unrelated screens.
Make it your own
Begin with your audience and the decision, lesson, or action the presentation should support. Replace the topic, examples, evidence, and visuals with material you can verify, then edit every slide for one clear takeaway. You can borrow the visual direction without copying the creator's wording or message. Presenton will use this community deck as a design reference while you develop content for your own purpose.
