uEngine AX Consulting · Workshop
Agent Storming
A workshop for designing how people and AI work together. The people who do the work uncover how it really flows, then design, run and improve processes where people and AI agents collaborate.
Background
Agents succeed or fail on the boundaries of the work, not on the model
When companies put AI agents to work, the obstacles come less from the model’s reasoning than from a lack of understanding of the work. Without domain context, a model gives answers that look reasonable while breaking real business rules. With several agents, responsibility blurs, data leaks between contexts and the agents become entangled. The ‘Big Ball of Mud’ that software engineering has long warned about reappears at the agent layer.
That is why architects in academia and industry have begun using domain-driven design (DDD) and EventStorming to find and design agents. AWS divided flight operations and the customer journey by bounded context to derive dedicated agents, and consultancies such as Orium use EventStorming to diagnose manual bottlenecks and set adoption priorities and roadmaps.
The value of EventStorming is that it shows a company’s reality as it is. Manual workarounds, system gaps and informal collaboration that appear in no policy document come up on the wall, and the hotspots marked there become agent opportunities. Domain events lead to triggers, commands to tool calls, policies to guardrails and read models to RAG context.
Agent Storming is uEngine’s workshop approach for carrying this out in the field, organized into workshop steps, decision criteria, role assignments and an adoption roadmap.
Why Agent Storming
Agent adoption fails in two places at once
Enterprise AI doesn’t succeed or fail on the size of the model. It depends on how clearly you hand agents the boundaries and responsibilities of the work.
Share of agentic AI projects expected to be canceled by the end of 2027
GartnerShare of day-to-day work decisions agents are expected to make autonomously by 2028
GartnerRange of task failure rates across seven major open-source multi-agent systems
UC Berkeley MAST, 1,642 execution tracesShare of all failures that arise in design and collaboration structure
UC Berkeley MASTFailure in choosing what to automate
Where to use agents
Choosing targets around the technology drives up cost, blurs the business value and weakens risk control. Many use cases marketed as agentic don’t need an agent at all (Gartner).
Failure in designing the units
How to divide them
Dividing by technology or org chart loses the meaning of the work. Merge everything and you overload context; split too finely and you get broken context and conflicting decisions. Adding or removing agents alone doesn’t fix it.
Three Design Outputs
One EventStorming session finds the place, the boundary and the design material
Three design outputs that move past the limits of a technology-first approach.
Place · Where to use them?
Where agents belong
Turn hotspots where observing, deciding and acting are possible into agent opportunities.
Failures it prevents: targets with unclear value, use cases chosen by trend
Responsibility · How far to trust them?
The agent’s boundary
Assign a bounded context with consistent terms and rules as the area of responsibility.
Failures it prevents: context overload, conflicting decisions, blurred responsibility
Material · What drives them?
The agent’s design material
Carry the nine artifacts from the workshop into the system architecture and code.
Failures it prevents: broken business rules, hallucinations from conflicting policies
Workshop
A five-step workshop lays out the work and draws the boundaries
Lay out the work as events in time order, draw boundaries and specify agent candidates. We recommend 8 to 12 people who know one work journey together.
Lay out events
Arrange what happened in the work, as past-tense events, in time order.
Mark pivotal events
Mark points of no return in bold to set reference points.
Draw boundaries
Divide contexts by pivotal events, changes in terms and changes in ownership.
Mark hotspots
Find bottlenecks and unclear spots and mark them with a red diamond.
Opportunity and spec
Pick candidates per context and choose the first pilot most likely to succeed.
From Stickies to Agents
The stickies on the wall become an agent’s design material
How the nine artifacts of an EventStorming workshop translate into the parts of an AI agent.
| Sticky | Meaning in the domain | Role in an AI agent |
|---|---|---|
| Domain Eventorange | A fact that has already happened | Asynchronous trigger input; task-completion output message |
| Commandblue | A command and intent that cause a state change | Agent task instructions; tool-call (Function Calling) signals and actions |
| Policylilac | A business rule that reacts to conditions | System prompt, conditional routing and guardrails (rules that stop execution outside the allowed scope) |
| Read Modelgreen | An information view for decision-making | RAG context, in-memory view, data lookups for judgment and context |
| Aggregateyellow | The smallest unit of transactional consistency | Persistent state store; scope of write permissions |
| Actoryellow | Whoever performs the work | An AI agent or a person (human-in-the-loop) |
| External Systempink | Third-party and legacy services outside the domain | External SaaS subscriptions; legacy core-system APIs |
| Hotspotred | Friction, delays, bottlenecks and unresolved risks | Prime candidates for automation and innovation |
| Bounded Contextdashed boundary | The boundary within which terms and models hold | A single agent’s area of responsibility, or a multi-agent team’s priorities and boundaries |
Validate the Opportunity
Not every hotspot should become an agent
For each hotspot, O.D.A tests whether an agent can observe, decide and act on its own. If any answer is no, consider rule-based automation or leaving it with people.
O · Observe
Observe
Can it receive the events and data it needs?
D · Decide
Decide
Can it set a course using policy and context?
A · Act
Act
Can it carry out the work through tool calls?
If all three are “yes”
Reclassify it as an agent opportunity and rank it as a first-pilot candidate.
Choose who does the work by its nature
| Category | Rule automation and RPA | Intelligent AI agents | People |
|---|---|---|---|
| Decision type | Deterministic (same input, same result) | Contextual, adaptive | Strategic, political judgment |
| Form of data | Structured data | Unstructured data | Tacit knowledge, complex stakeholder interests |
| Tolerance for failure risk | Very low | Medium (offset by guardrails and human intervention) | Very low (legal and ethical accountability concentrates here) |
| Typical work | Account provisioning, simple data migration, fixed-amount approvals on structured data | Assisting unstructured claims review, predicting supply-chain bottlenecks, rebooking complex journeys | Final approval of large credit reviews, reorganizations, strategy for new domains |
Boundary
Decide where the boundary goes, not how many agents you have
A good unit emerges when five conditions line up inside one boundary. A bounded context is a design hypothesis that ties them together, and domains and agents are not fixed one-to-one. Keep testing and adjusting against authority, state, cost, risk and responsibility.
| Condition | Definition | DDD element | Problem it prevents | Where EventStorming finds it |
|---|---|---|---|---|
| 1. Consistent language | Terms in prompts, tool descriptions and data share one meaning | Ubiquitous language | Context overload, confused terms | Where terms change |
| 2. Owned state | The data an agent may change is clearly scoped | Aggregate | Conflicting decisions | Aggregate |
| 3. Explicit rules | The business rules to follow sit together inside the boundary | Policies, invariants | Broken business rules | Policy |
| 4. Narrow interface | Exchanges with other units happen only through agreed events | Domain event | Broken context, tangled dependencies | Domain event |
| 5. Clear responsibility | The owning team and human approval points are defined | Team that owns the context | Blurred responsibility | Actor |
Four signals for drawing a boundary
Where a term’s meaning changes
Is the same word used to mean different things?
Pivotal events
Is this a point of no return?
Where ownership changes
Does the work pass to another team?
How far state changes together
Is this data that must stay consistent in one step?
Where several signals overlap is the strongest boundary candidate, and domain experts always make the final call. Data areas with different security or regulatory classifications become separate contexts regardless of other signals (per Microsoft).
Blueprint
An eight-step blueprint for reshaping the value stream
It ties design thinking, EventStorming, lean and domain-driven design into one cycle to design, run and learn from collaboration between people and AI.
- 1DiscoverFind the problem
- 2UnderstandSet the baseline
- 3EventStormVisualize the events
- 4EnvisionFind AI opportunities
- 5RedesignRedesign roles
- 6OrchestrateDesign the BPMN
- 7ExecuteConfirm execution
- 8LearnMeasure results
The limits of autonomy, and final responsibility with people
People
Handle value judgments and exceptions. Hold the highest authority and final approval.
Agents
Handle pattern analysis, drafting and repetitive work. Limited autonomy, operating under human approval conditions.
External systems
Handle record keeping and tool execution. Run automatically after final human approval.
Five lanes (requester, agent, owner, approver, system) define who does what and when. AI helps work move quickly and efficiently, but exceptions and final decisions return to people by designed rules.
Roadmap
A five-stage roadmap for company-wide AI agent adoption
Don’t convert everything at once. Release a single pilot to a limited group first, adjust through four-week evaluations and expand carefully into adjacent contexts.
| Stage | Core activities | Key deliverables |
|---|---|---|
| 1. Align | Big-picture EventStorming, surfacing business events, identifying context boundaries | Integrated timeline board, draft contexts, ubiquitous language glossary |
| 2. Prioritize | Turning hotspots into agent opportunities, assessing impact and risk, selecting a pilot | Agent opportunity backlog, single-pilot definition, key performance indicators (KPIs) |
| 3. Design | Defining event schemas and state models, defining approval guardrails | Architecture on a Page, OpenAPI spec, guardrail spec |
| 4. Build | Building the RAG retrieval base, orchestration and tool-call integration; release to limited users | Workflow code, monitoring dashboard, performance evaluation suite |
| 5. Iterate & Scale | Four-week evaluations of operating data, tuning prompts and guardrails, expanding to adjacent contexts | Agent performance report, context map diagram, governance guidelines |
Three final deliverables for executives
Multi-agent collaboration map
Specifies goals, responsibilities and authority for people and agents.
Executable BPMN process
Orchestration including approval steps and exception-handling gateways.
Results and experiment metrics (KPIs)
Tracks the pre-adoption baseline, quality and cost, and the human intervention rate.
Every deliverable, from event discovery through opportunity finding and authority design to final execution metrics, stays traceable end to end.
Limits of adoption and responses
| Area | Limit or risk | Response |
|---|---|---|
| Cold start | Psychological resistance to a blank page; AI anchoring bias that misses exceptions | Use AI drafts only as a starting point, and always fill in exceptions with domain experts. |
| Big-bang attempts | Automating everything brings unpredictability and a surge in cost and debugging difficulty | Start with a lightweight pilot on one hotspot, evaluate every four weeks, then expand. |
| Domain judgment | Tools or AI can’t decide real ownership boundaries and standard terms on their own | Domain experts set bounded context boundaries and terms themselves. |
| High-risk zones | Without human control: regulatory violations and legal liability | Hard-code human-in-the-loop approval guardrails into the context spec. |
Facilitator Consultant
The facilitator consultants who lead the workshop
They guide the conversation at the wall and settle the boundaries and first pilot with you. The work is led by practitioners who have carried out process and architecture transitions in the enterprise, and taught them.
Jinyoung Jang
CEO & President, uEngine Solutions
- Founder of uEngine BPMS and Open Cloud Engine
- Lead instructor at MSA School; extensive cloud (MSA, DDD) teaching
- SAFe Agile Certified Consultant (SPC)
- Technical advisory member, Digital Platform Government
- Certified instructor, Korea Software Technology Association (KOSTA)
- Former member of the OMG/SEMAT international standards tools subcommittee
Yongju Park
uEngine Director & MSA Consultant
- Lead instructor at MSA School; author of microservices course materials and textbooks
- Instructor, LG CNS EventStorming training (2019)
- Instructor, microservices training at SK, KT, Doosan and KOSTA (2019–2021)
- MSA DT master plans, PoCs and pilots
- Adjunct professor, Department of Computer/AI Engineering, Sejong Cyber University
Seongyeol Yoon
CEO, DreamFlow
- Lead instructor at MSA School; extensive microservices teaching
- MSA development, domain analysis and design, and server development projects
- Expert instructor, BAPF Forum and Curriculum Committee, Korea Software Technology Association (KOSTA)
- Former vice-chair, TTA IoT Special Technical Committee SPG11
- Former adjunct professor, Gachon University
Seokbin Yoon
Special-appointment professor, Sogang University · CEO, TrustConnector Inc.
- Researches enterprise AI and blockchain, after IBM and Oracle
- Author of “The AI Orchestrator and the Super One-Person Company” (Good Morning Media)
A track record of teaching EventStorming and DDD
Cumulative MSA School trainees
As of 2024MSA School training sessions
As of 2024Total MSA School training time
As of 2024Members in the DDD and EventStorming community we run
EventStorming is a hands-on topic in MSA School’s intermediate and advanced courses; the trainee count covers all of MSA School. Major client companies include SK C&C, Hanwha Group, Samsung SDS, LG CNS, LG U+, GS Group, Kyobo Life, Hana Financial Group, KB Kookmin Bank, Shinhan Investment, ITCEN Group and Moornmo.
Trainee satisfaction
Average Rating
MSA School results, as of 2024Average satisfaction
Cloud Native Professional course, 257 sessions · 7,410 traineesTrainee rating
Cloud-native flipped-learning course, September 2024“I liked how the whole flow, from EventStorming to code generation and development, was connected right inside the web browser.”
“There were plenty of examples and exercises, and it was a valuable course for seeing how DDD translates into real code and how the tools link together along the way.”
“Both the instructor and the assistant instructor answered every question kindly and explained things simply and in detail so that no one was left behind.”
uEngine’s project history
EventStorming · DDD · MSA
Understanding the work together and designing along its boundaries
- 2025Gov24 cloud-native microservices consulting
- 2023~2024Microservices architecture consulting: KB Wallet, SK Networks and more
- 2023Shinhan Investment Corp. MSA implementation training
- 2022~2023Samsung SDS cloud-native implementation training
- 2022Kyobo Life Digital Acceleration Tech Track; Hanwha Systems MSA implementation training
- 2021Hanwha Systems SIT MSA transition cloud consulting
- 2020~2021SK C&C MSA Intensive training
- 2019LG CNS EventStorming-based Microservice training, LG MSA standard development methodology manual design, LG U+ microservices transition pilot
BPM · BPM engine R&D since 2001
Running the workflows of finance, government, manufacturing and telecom
- 2026SKT OSS domain: process asset creation and agentic automation build (Process GPT)
- 2025Awarded the Hanwha Life BPM system build
- 2023~2024LG Energy Solution OCAP, LG Chem overseas branch management and closing optimization, LG CNS LGES next-generation ERP, Hana Bank Project ONE
- 2022LG Display BPM automation system development
- 2015~2023IBK Industrial Bank of Korea post-next-generation BPM subscription
- 2010~2011Hyundai Merchant Marine integrated logistics, Korea Atomic Energy Research Institute, Koramco Asset Trust, Kyungdong Navien, POSCO ICT PI, Hanwha Group enterprise systems
- 2007~2009Hyundai/Kia new-vehicle quality management, Green Cross Life new contract and reinstatement underwriting, SK Telecom, Daewoo Securities, Korea Securities Finance
Full company history · BPM case studies · MSA training results
Where to Start
Start at the size that fits your organization
EventStorming isn’t reserved for companies of a certain size. The AI Work Class for Your Company applies a simplified form in its value stream analysis; organizations where several departments work together run the full workshop.
AI Work Class for Your Company
Small businesses · Individuals
- Value stream analysis applies a simplified form of EventStorming to real work cases.
- Bring one real task and practice it with Process GPT Lite.
- The initial installation of Process GPT Lite in your agreed environment is included.
- Afterward, a mentoring subscription can carry the improvement forward.
Company-wide workshops and consulting
Larger organizations where several departments move together
- 8 to 12 people who know one work journey together find the contexts and hotspots.
- Release a single pilot to a limited group first, then expand through four-week evaluations.
- Executives and development teams set the transition strategy together through AX Transformation Consulting Training.
Scope and structure are set with you in consultation.
Download
The Agent Storming Workshop Guide
A 50-page guide for executives and business leaders, from the problem through the adoption roadmap, in diagrams and tables. The guide is in Korean.
Contents
- Part 1The problem and the starting pointp. 3
- Part 2EventStorming and finding opportunitiesp. 13
- Part 3Agent responsibility and boundariesp. 24
- Part 4Execution and learningp. 36
Download
Get the PPTX to present or edit, or the PDF for a quick read. Both are in Korean.
This guide is a proposal-stage draft. It is not a validated standard or a specification of current Process GPT features.
Based on: Deriving AI Agents from EventStorming. Sources include Gartner, UC Berkeley MAST, Anthropic, Microsoft, OpenAI and Alberto Brandolini; the full list is on page 50 of the guide.
Guide preview
Click a figure to enlarge it.
Find the first boundary where people and AI can work together
We can help you scope the workshop, choose participants and select a first pilot.
Contact: help@uengine.org