Run an AI hackathon
# Deployment & Adoption
# Codex
# ChatGPT
# Use Cases
# Work
# Workplace & Business
# Codex for Work
# Leaders & Admins
# Activators
A step-by-step guide to planning and running an internal AI Hackathon.
September 17, 2025 · Last updated on June 12, 2026Internal AI Hackathon Playbook
A Hackathon is a structured event where people come together to brainstorm, test, and prototype ideas in a short period of time.
Although Hackathons are often associated with software development, they can focus on many kinds of problem-solving. In the context of AI adoption, a Hackathon gives teams dedicated time to explore use cases, test workflows, build prototypes, and experiment with new ways of working.
A Hackathon is not only about what gets built. It can also help people:
- Build confidence applying AI to real work
- Learn from colleagues with different levels of experience
- Surface promising workflows and use cases
- Create shared momentum around AI adoption
- Identify ideas that are ready for further testing
The event itself is the starting point. The longer-term value comes from documenting what teams learned, deciding which ideas are worth continuing, and making the strongest examples easier for others to test.
How to Use This Playbook
Use this guide when you want to run a time-bound event focused on learning, experimentation, prototyping, or exploring new AI workflows.
Before you begin, choose the primary outcome that matters most:
- Learning: Help participants build confidence and practical AI skills.
- Exploration: Surface new workflow ideas and use cases.
- Prototyping: Build rough solutions, prompts, GPTs, Skills, Workspace Agents, Codex-supported prototypes, internal tools, or workflow concepts.
- Validation: Test whether a known workflow idea works with real users and real inputs.
- Community-building: Connect people across teams and create shared momentum.
Leaders should define the purpose, connect the event to business or adoption priorities, and make sure participants have time and support to take part.
Activators can help plan the event, seed examples, mentor teams, troubleshoot practical workflow questions, and capture the strongest ideas for follow-up.
How to Prepare
1. Form a Planning Group
Include the people needed to support planning and day-of execution.
Role | Responsibilities |
|---|---|
Leader or Executive Sponsor | Connects the Hackathon to a business or adoption priority, reinforces why it matters, and helps create time for participation. |
Facilitator or Organizer | Coordinates planning, manages the agenda, runs the kickoff and closing, keeps time, and supports the overall flow. |
Activators or Power Users | Share examples, mentor teams, answer practical questions, and help participants apply AI to real work. |
Workspace Admin, IT, or Technical Support | Confirms access, troubleshoots login or technical issues, and supports relevant tools, connectors, integrations, or environments. |
Judges or Review Panel | Reviews projects, asks questions, provides feedback, and recognizes useful work. |
Participants | Identify a problem, build or test an idea, document what they learn, and present the outcome. |
One person may fill more than one role.
2. Define the Objective and Theme
Choose one primary objective for the event, and a focused theme to give participants enough direction without prescribing the solution.
Objective | Example Theme |
|---|---|
Help employees build confidence using AI. | Improve a recurring team workflow. |
Identify useful workflows for a specific team. | Reduce time spent on manual preparation. |
Prototype solutions for a known business challenge. | Improve the quality or consistency of a common output. |
Explore how a function could use AI more effectively. | Make internal knowledge easier to find or use. |
Test a set of priority workflow ideas. | Improve a customer, employee, or manager experience. |
Build examples that can be shared with other teams. | Build a useful AI-supported tool or workflow for your function. |
Avoid trying to optimize for every outcome at once. A clear objective helps you choose the right participants, format, challenge statement, judging criteria, and follow-up plan.
3. Create Teams
Teams of three to six people are usually large enough to bring different perspectives while staying manageable.
When forming teams, consider:
- A mix of technical and non-technical participants
- Different functions or roles
- Experienced users paired with beginners
- People who understand the workflow
- People who can build, test, or present the idea
Avoid creating teams where no one understands the underlying work problem.
4. Confirm Access and Tools
Before the event, confirm that participants can access:
- The relevant tools, workspace capabilities, data, and systems.
- Development or prototyping environments, where relevant
- The submission or presentation template
Resolve access issues before the build time begins.
5. Communicate Logistics and Pre-Work
Share the following in advance:
- Date and duration
- Format: virtual, in person, or hybrid
- Objective and theme
- Who should participate
- How teams will be formed
- What participants should prepare
- What tools and resources will be available
- How demos and judging will work
- What happens after the event
Ask participants to arrive with one or more of the following:
- A recurring pain point in their work
- A task they want to improve
- A sample document, report, template, or process
- An existing prompt or prototype
- A question they want to explore
Keep pre-work light. The goal is to help participants arrive ready to build, not to complete the project before the event.
Choose the Right Format
Select the format based on the objective, number of participants, complexity of the challenge, and available facilitation.
Format and Duration | Best For | Sample Agenda |
|---|---|---|
1-Hour Sprint | Quick exposure, a single challenge, or a team-level activity. | 0:00–0:10 Kickoff 0:10–0:40 Brainstorm and build 0:40–0:55 Quick demos 0:55–1:00 Wrap-up |
Half-Day Hackathon | Departments or smaller groups that need time to brainstorm, build, and share. | 0:00–0:20 Kickoff 0:20–1:00 Brainstorm 1:00–2:30 Build and test 2:30–3:30 Demos and feedback |
Full-Day Hackathon | Deeper prototyping, cross-functional work, and structured testing. | 0:00–0:30 Kickoff and examples 0:30–2:00 Brainstorm and prototype 2:00–2:30 Break 2:30–5:00 Build and test 5:00–6:00 Demos 6:00–6:30 Recognition and close |
Multi-Day Hackathon | Company-wide or complex challenges requiring more build and testing time. | Day 1: Kickoff and prototype Day 2: Build and test Day 3: Finalize, demo, and recognize |
Run the Event
1. Open With the Purpose
At the kickoff, explain why the hackathon is happening:
- What participants should learn or produce
- How the work connects to a team or business priority
- What constraints or guardrails apply
- How success will be evaluated
- What will happen to the ideas afterward
Keep the opening short enough to protect build time.
2. Share Examples and Guardrails
Give participants enough inspiration to begin.
Useful kickoff materials include:
- A few relevant workflow examples
- A sample prototype
- A simple problem-framing template
- A list of available capabilities
- Safe-use and human-review guidance
Avoid overwhelming participants with too many examples or detailed instructions.
3. Define the Problem Before Building
Ask each team to clarify:
- Who experiences the problem?
- What task or workflow are they trying to improve?
- What happens today? What is slow, difficult, inconsistent, or frustrating?
- What would a better outcome look like?
- What does the team want to test during the Hackathon?
This keeps teams from building a solution before they understand the problem.
4. Build and Test
Encourage teams to create the smallest useful version of the idea. They might produce a tested prompt, reusable workflow, Skill, Workspace Agent, Codex-supported prototype, internal tool, or documented concept.
Ask teams to test with realistic examples where possible.
Remind them to document:
- Inputs
- Instructions or steps
- Output
- Human review
- Known limitations
- What they learned
5. Use Checkpoints
For longer events, schedule short checkpoints.
Make sure the problem is still clear. Ask:
- What has the team tested?
- What is working / not working?
- Does the team need help?
- What can realistically be completed before the demo, and what should be documented for follow-up?
Checkpoints should help teams make decisions, not become status meetings.
6. Demo the Work
Ask teams to present:
- The problem or workflow, including the users / role(s) or team affected
- What they built or tested and how it works
- What changed or improved
- What still requires human review
- What they learned
- What should happen next
Keep demos short and consistent.
Review and Recognize the Work
Create a judging or feedback rubric that matches the objective.
Criterion | Question |
|---|---|
Relevance | Does the idea address a real and meaningful problem? |
User Value | Could it make the work easier, faster, clearer, more consistent, or higher quality? |
Feasibility | Can the idea be tested or developed with realistic tools, access, and support? |
Usability | Can the intended user understand and use it? |
Human Review | Is it clear what the user must verify, decide, or approve? |
Repeatability | Could another person or team test or adapt the approach? |
Learning | Did the team surface a useful lesson, even if the prototype is incomplete? |
Recognition does not need to focus only on the most polished build. You can recognize:
- Most useful workflow
- Strongest customer or employee value
- Best cross-functional collaboration
- Most creative experiment
- Best learning from a failed test
- Most promising idea for continued development
- Best reusable asset
Outcomes and Follow-Up
A Hackathon loses much of its value if the outputs disappear after the demos. Document outcomes in a shared space, including:
- Prompts, prototypes, Skills, Workspace Agents, or internal tools
- Workflow ideas, lessons learned, known limitations, and access or governance blockers
- Recommended next steps and owners
Use a simple status to distinguish what happens next:
Status | Meaning |
|---|---|
Learning Example | Useful for education or inspiration, but not intended for continued development. |
Needs More Testing | Promising idea that requires additional validation, user feedback, or technical work. |
Ready for a Limited Pilot | Clear problem, owner, next step, and enough evidence to test with a small user group. |
Reusable Example | A tested workflow or asset that another person or team can try with available guidance. |
Not Moving Forward | The idea is not useful, feasible, or relevant enough to continue at this time. |
Not every project should move forward. The goal is to make a clear decision rather than treating every prototype as a commitment.
For each idea selected for follow-up, document:
- The next step / milestone and owner
- Support needed
- User group
- Access or approval requirements
- Evidence to collect
- Review date
Leaders can help decide which ideas align to priorities and deserve continued time or support. Activators can help refine the workflow, package the example, or coordinate a small follow-up test.
Workspace Admins, functional owners, or technical partners should be involved when the next step requires access, governance, process changes, or implementation support.
Share the Results
Send a short recap that includes:
- The objective
- A few highlighted ideas
- What teams learned
- Which projects will continue
- Where people can find the outputs
- How others can get involved
Celebrate participation, but make the follow-up decisions visible as well.
Tips for Success
- Set clear objectives. Share the theme, expected output, and success criteria before the event.
- Mix teams intentionally. Pair people who understand the workflow with people who can help test or build the idea.
- Protect build time. Keep the kickoff, checkpoints, and demos structured.
- Keep the scope small. Encourage teams to test one meaningful part of a workflow rather than attempting a complete solution.
- Use real work. Real inputs and familiar problems make the event more relevant and produce stronger learning.
- Make human review visible. Teams should explain where people must verify, edit, approve, or make decisions.
- Plan the follow-up before the event. Decide where outputs will be stored, who will review them, and when participants will receive an update.
Next Steps
- Define the objective and business or adoption priority.
- Identify the planning group.
- Choose the format and challenge theme.
- Prepare examples, templates, and guardrails.
- Confirm time, access, and support for participants.
- Facilitate the event and support teams.
- Capture the outputs, owners, blockers, and lessons.
- Classify what should stop, continue, or move into a limited pilot.
- Share the recap and follow-up decisions.
1
Sign in or Join the community
Create an account
Table Of Contents
Popular
Resource
The AI Champion role
Resource
Debug AI adoption blockers