Deriving AI Agents from EventStorming

We are publishing our report, “Identifying AI Agents and Innovating Processes with EventStorming and Domain-Driven Design.” It walks through how the sticky notes placed in an EventStorming workshop carry over into an AI agent’s triggers, tool calls, guardrails, knowledge base and boundaries of responsibility, which bottlenecks should get an agent first, and finally the enterprise adoption roadmap and its realistic limits.

1. Overview and research trends
2. Mapping EventStorming artifacts to AI agent architecture
3. Diagnosing process bottlenecks (hotspots) and prioritizing agent adoption
4. Multi-agent system design and a five-stage enterprise roadmap
5. Business process innovation benefits and technical limits
6. Conclusion

The technical maturity of generative AI and large language models (LLMs) is accelerating the shift beyond simple question-answering assistants toward agentic workflows and multi-agent systems (MAS) that autonomously plan complex business workflows and call tools to execute them¹. Yet attempts to deploy intelligent agents into real enterprise processes keep running into structural obstacles⁴. The cause is less a lack of general reasoning ability in the models themselves than system-level defects that stem from missing company-specific domain knowledge and poorly defined work boundaries⁴. An LLM without domain context behaves in ways that look plausible on the surface but violate actual business rules and invariants, and in multi-agent environments unclear ownership, data leaking across contexts and unexpected coupling have been shown to reproduce software engineering’s classic ‘Big Ball of Mud’ anti-pattern at the agent layer².

To remove this bottleneck, academic researchers and industry architects are adopting domain-driven design (DDD) and its hands-on analysis technique, EventStorming, as core tools for identifying AI agents and engineering agent systems¹. DDD’s bounded context and EventStorming’s event-driven analysis provide an ideal engineering foundation for fixing each autonomous agent’s cognitive boundary and for establishing asynchronous collaboration contracts between agents¹.

In academia, framework studies that systematize scalable multi-agent architectures from the outputs of EventStorming workshops continue to be published¹. In enterprise architecture practice, Amazon Web Services (AWS) has demonstrated a method that splits large-scale processes spanning flight operations and the customer journey into bounded contexts, derives a dedicated AI agent for each, and builds a collaboration topology among the agents for disruptions such as flight cancellations⁷. Global digital transformation consultancies such as Orium and Composable have also applied EventStorming to business process reengineering (BPR), establishing and fielding practical frameworks that diagnose manual-work bottlenecks and derive priorities and execution roadmaps for intelligent agent adoption⁵.

EventStorming is a collaborative technique for visually modeling the flow of events in a business domain along a timeline that runs from left to right⁶. The standard visual artifacts produced in the workshop correspond strictly one-to-one with the building blocks of a multi-agent system: triggers, tool-call interfaces, system-prompt guardrails, persistent state stores and more⁴.

A domain event is a business-relevant fact that has already happened in the system, written on an orange sticky note⁶. In an agentic architecture, a domain event either acts as the asynchronous trigger (input event) that starts an agent, or becomes the result message (output event) that an agent publishes to a distributed message bus after completing a piece of reasoning and work⁶. This is the foundation of the communication interface that lets individual agents interact in a loosely coupled way, without direct dependencies, in an event-driven architecture (EDA)⁶.

A command represents a user’s intent or a system’s work instruction to change system state, shown on a blue sticky note⁶. In an agent system, a command becomes the explicit task goal an agent must complete and the specification of a tool call (tool execution / function calling) that invokes external tools and APIs⁴. User-initiated commands are execution instructions derived from an operator’s or customer’s natural-language prompt, while system-triggered commands are backend transactions invoked automatically in response to an event from the previous step⁶. Policy-driven commands, triggered by business rules, are actions an agent executes after judging on its own whether their conditions are met, and invariant-enforcing commands act as interceptors that validate an agent’s output in advance so it cannot compromise system integrity⁶.

A business policy, written on a lilac sticky note, expresses a reactive causal rule: “whenever an event occurs, run a given command”⁹. In agent engineering, policies translate directly into system prompts, conditional routing rules and guardrails that block model hallucination and drift⁴. Business rules stated on the EventStorming board act as clear constraints when an LLM generates code or makes autonomous decisions⁴. For example, once a policy states that users cannot rate their own posts, the LLM reflects that rule and produces a specification that includes an explicit HTTP 403 Forbidden response or blocking logic for the prohibited case⁴.

A read model, on a green sticky note, is the set of information an actor consults when making a decision; it maps to the RAG (retrieval-augmented generation) knowledge base, vector database indexes and runtime memory views an AI agent uses while reasoning⁶. An aggregate, grouped in yellow, is the unit that guarantees the transactional integrity of state changes, and it defines the scope of data an agent may write to and persist (state persistence)².

A bounded context is the logical boundary within which the ubiquitous language keeps a single business meaning². In multi-agent design, a bounded context takes one of two architectural forms². The first is the cognitive agent style, which models the context itself as a single intelligent agent with its own expertise and prompts; the second is the workspace style, in which many fine-grained specialist agents interacting inside the context share a common domain model². Both act as isolation walls that keep agents from intruding directly into domains they are not authorized for or leaking data indiscriminately².

Table 1. EventStorming artifacts and the AI agent architecture elements they map to

The most important value of bringing EventStorming into business process innovation and AI adoption analysis is that it exposes the company’s ‘as-is’ reality without embellishment⁵. Formal process diagrams and internal policy documents describe only idealized workflows with the exceptions removed, whereas an EventStorming session with diverse stakeholders lays bare the manual workarounds, system gaps and informal collaboration that actually happen on the ground⁵.

As participants validate the timeline and trace cause and effect between domain events, red or neon-pink hotspot stickies are placed wherever they disagree or delays keep recurring⁹. These hotspots typically cluster around delays in manually processing unstructured data, manual handoffs over Excel or email because departmental systems are not connected, implicit decisions that rely only on one person’s experience and were never turned into rules, and cognitive overload where people must cross-check several monitors⁵.

In agent-centric EventStorming analysis, each hotspot cluster is examined to see whether an intelligent agent could observe the situation at that point of friction, decide with the context in mind, and act appropriately⁵. Bottlenecks that meet these conditions are immediately reclassified as green-sticky ‘agent opportunities’⁵.

Not every hotspot identified, however, is a good fit for an AI agent⁵. Work driven by structured data and deterministic business rules is better handled, in both cost and stability, by conventional API integration or RPA (robotic process automation); conversely, areas with extremely high regulatory risk or enormous costs of failure should be excluded from full autonomy⁵. Companies therefore need to choose the technical approach carefully, based on whether the work is deterministic, what form the data takes, and how much risk can be tolerated⁵.

Table 2. Choosing an automation type by the nature of the work

At the prioritization stage, the severity of the friction is cross-analyzed against implementation risk, and the first pilot is a single task that causes the business real pain while its system risk stays controllable (high impact, low risk)⁵.

Once domain events, bounded contexts and agent opportunities are identified, they are turned into a distributed architecture on LangGraph, CrewAI, AutoGen, cloud-based runtime services and the like⁷. The core principle of multi-agent system design is to confine each agent’s responsibility strictly within the boundary of a specific bounded context².

For example, if a complex airline operations and travel management domain is built as one large AI model, flight scheduling, fare policies and passenger compensation rules collide inside a single context, which easily leads to hallucination and loss of control². Applying DDD principles instead isolates the system into clear bounded contexts—flight operations, reservations and customer service—each staffed by a dedicated agent specialized for that context⁷.

In a disruption scenario where bad weather causes mass cancellations, the flight operations agent publishes a cancellation-confirmed event, the reservation agent receives it and publishes an event for finding seats on alternative flights, and finally the customer service agent gives passengers their new itinerary and hotel vouchers, so the agents work together seamlessly⁷. Each agent is responsible only for its own domain’s ubiquitous language and invariants, and communication between contexts happens asynchronously through predefined domain event interfaces².

Figure 1. In the cancellation scenario, the agent of each bounded context collaborates through domain events

To embed such multi-agent systems across the organization, industry applies a five-stage execution roadmap (the 5-Stage Agentic Roadmap)⁵.

1. Align — Domain experts, software developers and AI engineers join a big-picture EventStorming session to surface raw events and visualize the end-to-end flow of work⁵.
2. Prioritize — The agent opportunities found in hotspot clusters are assessed for business impact and risk, and exactly one core pilot task is chosen⁵.
3. Design — An Architecture on a Page is written, specifying the trigger and output events the agent will handle, the external APIs and tools it may access, the RAG knowledge base schema, and the approval points that require human intervention⁴.
4. Build — A lightweight agent is developed on a modern framework such as LangGraph or CrewAI, observability tooling is connected, and a minimal deployment is made against real operational data⁵.
5. Iterate & Scale — Operational data is evaluated on a four-week cycle, prompts are fine-tuned, and agents that have proven themselves are gradually extended and linked into adjacent bounded contexts⁵.

Table 3. Five-stage roadmap for enterprise AI agent adoption

What EventStorming delivers

The signature result of using EventStorming as a combined tool for business process innovation and AI adoption is uncovering the tacit knowledge hidden inside the organization⁸. A company’s core competitive strengths and its real points of friction live not in documented manuals but in practitioners’ everyday habits and experience⁸.

EventStorming works as a kind of organizational-anthropology probe, drawing out the manual workarounds and implicit exception-handling rules that staff have informally maintained and turning them into an explicit visual model⁸. This makes it possible to plan agents that solve the real problems actual users face⁵.

And because business staff, developers and AI engineers share the same visual model, departmental silos dissolve and the requirement mismatches that surface late in projects are cut off at the source⁵. Even non-technical staff can clearly understand, and agree on, when an agent steps in and at what point it must hand a decision to a person for approval, simply from where the sticky notes are placed⁵.

The domain boundaries and policy stickies clarified through EventStorming also give the LLM precise context, preventing the architectural debt of generating code outside the system’s scope and keeping hallucination-driven malfunctions within a controllable range⁴.

Limits and risks in practice

There are, however, clear technical limits and organizational risks that must not be overlooked in practice⁵. The ‘cold-start’ problem of having to come up with domain events in front of a blank wall at the start of a workshop causes participants considerable psychological resistance²⁰. AI assistants such as Qlerify and StormSpace now generate an initial event board automatically, but if participants sink uncritically into the model’s draft, anchoring bias can set in and the company’s unique exception handling and domain specifics get lost²⁰.

Another major cause of failure is that an organization which has uncovered vast inefficiencies through EventStorming is easily tempted to automate the entire process with multiple agents at once, in a big-bang approach⁵. As agent autonomy grows, system-wide unpredictability, token costs and debugging complexity increase exponentially, so an incremental approach that first validates a lightweight pilot on a single hotspot is essential⁵.

Most important of all, the essential judgment of domain modeling cannot be replaced by AI²¹. AI tools can help order events or draft API specifications, but strategic decisions—which bounded context is the real boundary of business ownership, which aggregates must be protected for business reasons, which domain terms should become the standard—still require the insight and judgment of domain experts²¹. In addition, the regulatory violations and legal liability that can arise when human approval (human-in-the-loop) guardrails are not properly designed into high-risk decision points are what to guard against most carefully when building agent systems⁵.

Using EventStorming and domain-driven design to identify AI agents and innovate existing processes is not a mere academic hypothesis; it is a core current of modern software engineering, systematically validated by global cloud vendors, academic researchers and enterprise consulting practice¹.

What decides the success of an enterprise AI system is not limited to the parameter count or fine-tuning technique of the underlying language model; it depends on how clearly the boundaries and responsibilities of business processes are defined and handed to the agents⁴.

EventStorming makes the hidden friction and hotspots of real work visible, selects the best opportunities for agents to step in, and establishes boundaries of responsibility and communication contracts between agents through bounded contexts and domain events, providing the most practical engineering analysis framework for building a stable, step-by-step enterprise AI roadmap².

Organizations that want to innovate their existing processes should therefore avoid adopting agent technology blindly, first face the reality of their domain through EventStorming, and hold to a domain-centric engineering strategy that gradually expands domain-specific agents that are clearly isolated and verifiable under the bounded context principle².

References

1. Designing Scalable Multi-Agent AI Systems: Leveraging Domain-Driven Design and Event Storming — ResearchGate
2. Agent as Bounded Context — Part 1 — Philipp Kostyra, Medium
3. Day-21: Event Storming To Code — Medium
4. From Stories to Code: Collaborative Modeling and LLMs — codecentric
5. EventStorming for Agentic AI: From Alignment to Action — Orium
6. Designing Scalable Multi-Agent AI Systems — DZone
7. Transforming Travel: How Domain-Driven Design Unlocks the Power of Agentic AI Systems — AWS Builder Center
8. From Sticky Notes to Intelligent Agents — Composable.com
9. EventStorming Glossary & Cheat sheet — Domain-Driven Design Crew
10. Event Storm - AI Agent Skill — k8mak
11. Event Storming — Florian Krämer
12. What is Event Storming? A practical guide with example — Rubicon
13. EventStorming Cheat Sheet — Xebia
14. How developers' role changes with AI — Port.io
15. Using EventStorming to prioritize technical and product improvements — Eduardo Matos
16. Event Storming and Context Mapping for Data & AI Product Managers — DataChef
17. Cloud Native Professional Course Proposal (PDF, Korean) — uEngine Solutions
18. MSA School curriculum — MSA School
19. The Evolution of AI-Assisted Development — X Gate
20. Leveraging the power of Event Storming and AI for domain-driven design — Medium
21. Der Synergetic Blueprint revisited – und warum KI alles verändert — codecentric
22. StormSpace — collaborative interactive Event Storming — GitHub