Real Use Cases

What can you actually do with this?

Not a list of features. Real scenarios showing how the platform works — from a problem you recognise to a result you can open on your board.

Learn about real-world use cases
📸 Use Case 1 Document Existing UX Flows with AI ⚡ ~15 min · Zero screenshots · On autopilot → 🧠 Use Case 2 Model Before You Code 🗣️ One conversation · 9 steps · Catch gaps before sprint 1 → 🤝 Use Case 3 Run Meetings That Actually Produce Something 📋 Visual agenda · Every change recorded · Clear outcomes every time →
📸 Use Case 1

Document Existing UX Flows with AI

Automatic Domain Discovery using Claude Code — on autopilot, in ~15 minutes

⚡ ~15 min total 🤖 Zero manual screenshots 📋 Zero documentation effort 🔍 Finds things you didn't know were there
👩‍💼

Sara is a software architect. In two days she has a domain modeling workshop with the business team. The agenda: map out how their Customer Onboarding flow actually works so they can redesign it. Normally she'd spend a morning taking screenshots, writing descriptions, and organizing them into something usable. She tries something different instead.

⏱ The old way — 3–4 hours
  • Taking screenshots of every screen, one by one
  • Writing descriptions for each step by hand
  • Organizing flows into a logical structure
  • Missing edge cases nobody thought to check
  • Result is subjective — you document what you think matters
  • Boring. Easy to skip. Often done badly.
⚡ With AI Discovery — 15 minutes
  • Agent navigates every visible flow automatically
  • Screenshots taken at every meaningful screen transition
  • Placed directly on the board as a visual storyboard
  • Finds paths nobody thought to look for
  • Objective — it sees the product like a first-time user
  • Fully on autopilot. You go make coffee.
How Sara did it — step by step
1
Install the agent kit
One command sets up everything — agent loop, board connection, skills installed in Claude Code: npx @eventmodelers/agent-modeling-kit@latest install
2
Add the Chrome DevTools MCP
Gives Claude Code a real browser to navigate with: claude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latest
3
Run /discover-storyboard — answer two questions
Claude asks: "What URL?" and "Any guidance?". Sara types https://app.hercompany.com and "Focus on the customer onboarding flow." Then she goes to make coffee.
4
The agent navigates, screenshots, and documents — like a real user
Claude opens the browser, clicks through every flow, fills forms with plausible test data, and at every meaningful screen transition takes a screenshot and writes: what it shows, how the user got there, what they can do next.
5
The board is ready — 9 screens, 3 timelines, zero effort
Sara opens Eventmodelers. Three chapters are there — each with real screenshots and descriptions. The workshop can start immediately. No blank canvas, no "so where do we begin?"
What appeared on the board — screens the agent discovered automatically
Login Page
Login & Registration
Signup Form
Login & Registration
Email Verification
Login & Registration
Onboarding Wizard — Step 1
Onboarding Wizard
Onboarding Wizard — Step 2
Onboarding Wizard
Onboarding Wizard — Step 3
Onboarding Wizard
Dashboard — First Visit
First Dashboard Experience
What Sara discovered — things nobody had noticed
🔎
The "Resend email" button is almost invisible
The agent documented it: "user can resend verification email (small text link at the bottom)." Sara's team had never discussed this. It went on the workshop agenda.
🔀
The wizard asks company size before company name
Seeing the sequence documented objectively made it obvious. Someone immediately said: "Wait, that's backwards." No one had noticed because they all knew what the wizard was supposed to do.
👆
The dashboard has 6 competing calls-to-action
The agent listed all six possible actions on the first-time dashboard. Seeing them all written together made the problem impossible to argue with.

The agent didn't read the docs or the code. It looked at the actual product, the way a real user would. And it built a starting point for the workshop in 15 minutes, on autopilot. Domain discovery doesn't have to mean writing boring documentation. Sometimes it just means letting an agent show you what's really there — including the things you didn't know were broken.

Try the Platform Free → Read the Agent Docs Requires Claude Code + Chrome DevTools MCP
🧠 Use Case 2

Model Before You Code — Understand Your Business Case with an Agent

Run the full Event Modeling workflow in one conversation — and discover what the business actually needs before anyone writes a line of code

🗣️ One conversation, 9 structured steps 🔍 Surfaces gaps before they become bugs 📐 Complete model, ready for code generation 🤝 Works with domain experts in the room
👨‍💻

David is a senior developer about to start a new feature: a subscription management flow for a SaaS product. The business gave him a one-pager, a Figma mockup, and a Confluence doc with bullet points. He has sprint planning in two days. He types /orchestrate-event-modeling and answers five questions.

⏱ The old way — build first, regret later
  • Read the requirements doc, nod, assume you understand it
  • Open the IDE, start with the database schema
  • Discover mid-sprint that "subscription" means three different things to three people
  • Find missing edge cases in QA — or in production
  • Refactor the model after the business changes their mind about what "cancelled" means
  • Half the spec is implicit knowledge nobody wrote down
⚡ With /orchestrate-event-modeling
  • Agent interviews you about the domain — fills gaps immediately
  • Brainstorms every event the system could produce
  • Sequences events into a coherent narrative before you touch any code
  • Builds UI storyboards showing exactly what data flows where
  • Generates Given-When-Then specs for every command — including failures
  • Validates the model and catches structural problems before sprint 1
How David did it — step by step
1
Install the agent kit
One command sets up everything — skills installed in Claude Code, board connection configured: npx @eventmodelers/agent-modeling-kit@latest install
2
Run /orchestrate-event-modeling — answer five questions
The agent opens with a short interview: "What are you modeling?", "What's your goal — learning, production code, or design validation?", "Any constraints?". David pastes in the requirements doc and answers in plain English. The agent confirms its understanding before touching the board.
3
The agent runs 9 structured steps — one at a time
Step 1 brainstorms every domain event. Step 2 sequences them. Step 3 sketches the UI storyboard. Steps 4 and 5 identify commands and read models. Step 7 writes Given-When-Then specs for every command — not just happy paths. At each step, the agent asks targeted questions and writes phase summaries before moving forward.
4
The agent builds the board in real time
Every event, command, read model, and scenario spec is placed directly on the Eventmodelers board as the conversation progresses. David can open the board at any point and see the model taking shape — timelines filling in, screens appearing, spec cells populating.
5
Validation pass — PASS verdict, model ready
Step 9 runs a completeness and consistency check. Every field has an origin and a destination. Every command has scenarios. The agent returns a PASS verdict and writes a summary. David goes into sprint planning with a board he can share — not a requirements doc that three people will interpret differently.
What David discovered — before writing a single line of code
💥
There was no event for a failed payment retry
The agent's scenario step asked: "What happens when the payment processor returns a transient error?" Nobody had written this down. It would have been discovered in production — or not at all, silently swallowing failures.
🔀
"Cancelled" meant three different things to three different people
The event brainstorm surfaced SubscriptionCancelled, SubscriptionPendingCancellation, and SubscriptionImmediatelyCancelled as distinct events. Seeing them side by side forced the first real conversation about what the product actually does at end-of-billing-period. That conversation had never happened before.
📐
The storyboard revealed a missing read model
The UI storyboard step drew the subscription management screen and listed every field it needed to display. One field — the next billing date — had no event that produced it. The agent flagged this in the completeness check. Without the model, this would have become a last-minute backend scramble.

The agent didn't write the code. It asked the right questions — the ones that expose assumptions, reveal missing events, and force the team to agree on what "cancelled" actually means. That conversation, structured into 9 steps, is worth more than a sprint of code written against a misunderstood spec. Model first. Code second.

Try the Platform Free → Read the Agent Docs Requires Claude Code + the modeling kit installed
🤝 Use Case 3

Run Meetings That Actually Produce Something

A shared board as the agenda, the whiteboard, and the minutes — all at once

📋 Visual agenda, not a bullet list 🔁 Every change is recorded and replayable ✅ Clear outcomes after every session 🚫 No more meaningless agendas
👥

The team used to start every refinement with the same question: "So — where were we?" Twenty minutes gone before a single decision. Now the first thing anyone does when a meeting starts is open the board. The model is the agenda. What's on it drives the conversation. What changes during the session is captured automatically. The meeting ends with something tangible — every time.

⏱ The old way — talking in circles
  • Agenda is a list of topics — nobody knows what "discuss payments" means
  • Half the meeting is reconstructing context from last time
  • Decisions happen but nobody wrote them down the same way
  • Whiteboard gets erased, sticky notes get lost
  • Follow-up email tries to summarise — different people remember it differently
  • Next meeting starts from scratch again
⚡ With a shared model board
  • Open the board — the model is the agenda, visually
  • Context is immediate: everyone sees what was there before
  • Changes made during the session are recorded as they happen
  • Board history lets you replay every move after the fact
  • Export a screenshot at the end — your meeting minutes, done
  • Next meeting picks up exactly where this one left off
How a session unfolds — from opening to outcome
1
Open the board — the model is already there
No deck, no document, no "let me share my screen." The board is open, the timeline is visible, the context from last session is still there. The conversation can start immediately.
2
The model guides every discussion
Instead of abstract topics, the team points at specific events, commands, and flows. "This command — what happens if it fails?" is a better question than "So, about the payment flow…". The visual structure keeps the conversation grounded.
3
Every change lands directly on the board
A new event gets added. A command gets renamed. A missing read model gets flagged. All of it goes onto the board in real time — not into someone's notebook to be typed up later.
4
Board history records every move automatically
Every change to the board is captured — who moved what, when. After the session you can scrub through the full history and replay exactly how the model evolved. Nothing gets lost. Even the reasoning behind a decision is visible in the sequence of changes.
5
Export a screenshot — your meeting minutes in one click
At the end of the session, one person exports a screenshot of the board. That's the summary. Not a write-up. Not an email. The model speaks for itself — and everyone who was in the room already agreed on what's on it.
Board history — every change recorded and replayable
Board history showing all recorded changes with a timeline scrubber
What the team discovered — once meetings had structure
🗣️
Conversations became specific instead of circular
When the agenda is a visual model, vague topics disappear. You can't have a 20-minute debate about "the subscription flow" when the flow is right there on screen. Either the model is right or it isn't — and the team can see which.
⏪
Board history settled a dispute no one remembered
Two weeks after a session, the team disagreed on whether a particular event had been intentionally removed or accidentally deleted. They opened the history, scrubbed to that moment, and saw exactly what happened — and why. Case closed in 90 seconds.
📋
Nobody writes meeting minutes anymore
The screenshot at the end of each session replaced the follow-up email that nobody read anyway. The board is the record. If a decision isn't on the board, it didn't happen.

The board doesn't just capture what the team decided — it changes how they talk. When everyone is looking at the same visual model, the conversation becomes about the model. Not about opinions, not about who remembers it differently. The structure is the discipline. And every meeting ends with something real: a board that reflects what was agreed, recorded change by change.

Try the Platform Free → See the Board in Action Real-time collaboration · History included in all plans

More use cases in progress — join the newsletter to be notified when the next one lands.