EventStorming for Agentic AI: Design the Process Before You Build the Agent

The shift to agentic systems is no longer theoretical. Brands are already experimenting with autonomous workflows, adaptive experiences, and multi-agent collaboration to relieve pressure on teams and unlock new growth. But the toughest part is not the technology - it is knowing where to start. EventStorming is the quickest path to that answer. It pulls cross-functional knowledge onto the table and gives teams a shared view of where human effort is carrying unnecessary weight, and where intelligent agents can take the load.

Most teams building agentic AI begin at the wrong end. They pick a framework - LangGraph, CrewAI, AutoGen - spin up a prototype, and then search for a business process to attach it to. The result is a technically impressive demo that rarely survives contact with production.

A more reliable path is to model the business process first, identify where decisions are made and where autonomy would add value, and then design agents to fill those roles. That is exactly what EventStorming enables.

What Is EventStorming?

EventStorming is a collaborative workshop format created by Alberto Brandolini. The setup is deliberately simple: domain experts and engineers gather in the same room with a long wall and a stack of sticky notes, then map out how the business actually operates - not the idealized version from a process diagram, but the real flow from end to end.

The building blocks:

• Domain Events (orange) - Things that happen. “Order Placed,” “Payment Failed,” “Shipment Dispatched.”
• Commands (blue) - Actions that trigger events. “Submit Order,” “Process Refund.”
• Actors (yellow) - Who or what issues the command. A person, a system, or - and this is the key insight - an AI agent.
• Policies (purple) - Business rules that connect events to commands. “When payment fails, retry twice, then notify the customer.”
• Read Models (green) - The data someone needs to make a decision.

What comes out is a timeline of events that captures the full business process - edge cases, failure modes, and decision points included. The kind of detail that never makes it into a requirements document.

Why EventStorming Works for Agentic Systems

EventStorming was designed to surface how work actually flows, not the polished version that lives in documentation. It is fast, somewhat chaotic, and remarkably effective at breaking down silos.

When merchandisers, content leaders, engineers, operators, and analysts map their world event by event, the friction shows up immediately: stalled handoffs, manual bottlenecks, inconsistent inputs, hidden dependencies. These are precisely the spots where agent intervention makes the most sense - because the people in the room already feel the pain.

For organizations beginning their agentic journey, this reframe matters. The goal is not to build sci-fi automation. It is to find the places where an agent can observe, decide, or act in ways that remove real, existing friction. EventStorming uncovers those opportunities naturally, and it builds organizational buy-in as it goes.

Agentic systems are fundamentally different from traditional software. They reason, plan, and act with a degree of autonomy. So the design question shifts from “what API should this call?” to “what decisions should this system make on its own, and where does a human need to stay involved?”

EventStorming answers that question directly. When you map a process like claims adjudication, supply chain planning, or customer onboarding, three things become clear:

• Where autonomy adds value. Repetitive, data-heavy decisions where speed matters and the rules are well-understood. An agent that classifies support tickets, routes them, and drafts an initial response is a straightforward win.
• Where autonomy creates risk. High-stakes decisions with regulatory implications or ambiguous data. An agent that adjusts insurance payouts without human review needs guardrails before it ships.
• Where the boundaries are. EventStorming reveals natural seams in the process - what Domain-Driven Design calls “bounded contexts.” These seams tell you where one agent’s responsibility ends and another’s begins.

Agents as Bounded Contexts

The most practical pattern we have found: treat each agent as its own bounded context - a clear boundary, a specific purpose, and its own internal language.

Take a supply chain system. EventStorming might surface three distinct domains:

1. Demand Forecasting - predicts what customers will need based on historical data, seasonality, and market signals.
2. Inventory Optimization - determines stock levels and placement, balancing cost against availability.
3. Supplier Coordination - manages purchase orders, lead times, and vendor relationships.

Each of these is a natural candidate for an agentic bounded context. Each has its own vocabulary, data sources, and decision logic. And each communicates with the others through well-defined domain events rather than reaching into one another’s internals.

This separation delivers three advantages that monolithic agent designs cannot:

• Testability. Validate each agent’s behavior against its own domain rules in isolation.
• Replaceability. Swap out a forecasting model without touching inventory logic.
• Governance. Apply different levels of trust and human oversight to different agents based on the risk they carry.

The Anti-Corruption Layer

One pattern that proves its worth repeatedly is the Anti-Corruption Layer (ACL). When an agent interacts with external systems - legacy APIs, third-party data sources, other agents - the ACL translates between the agent’s clean internal model and the complexity of the outside world.

Without it, implementation details contaminate the agent’s reasoning. A forecasting agent should not need to know that the ERP system returns dates in three different formats. The ACL absorbs that messiness so the agent can stay focused on its actual job: making good predictions.

This becomes especially important when agents talk to each other. Each one publishes domain events in its own language. The receiving agent’s ACL translates those events before processing them. That translation layer is what prevents the tight coupling that makes multi-agent systems fragile and difficult to evolve.

How to Run an Agent-Focused EventStorming Session

Keep the scope tight and the group small. Eight to twelve people who collectively own a discrete journey is the sweet spot - content from idea to publication, merchandising from planning to go-live, fulfillment from cart to doorstep. Go too broad and you lose the momentum that makes the format work.

You need four note types to stay organized as you move through each stage:

• Orange for domain events
• Blue for systems, commands, or policies
• Purple for pain points
• Green for agent opportunities

With those in hand, run three fast passes:

Pass 1: Raw Events

Everyone adds orange notes for every action in the flow. No debating, no refining. Capture reality as fast as you can and move to the next event.

Pass 2: Structure and Systems

Arrange the events into a timeline, then layer in blue notes to identify systems and dependencies. Missing context and awkward handoffs start to surface here.

Pass 3: Pain Points and Agent Opportunities

Participants add purple notes wherever things break down, slow down, or depend on judgment calls that no one has documented. Then ask the room: could an agent reasonably observe this, make a decision, or take action here? The answers become green notes - your candidate intelligent agents.

Because modern agents can reason across systems using plain-language instructions, even non-technical participants can describe handoffs without feeling out of their depth. The result is shared understanding and a list of opportunities the entire team believes in.

Turning the Board Into a Real Backlog

By the end of the session, clusters of purple notes will have formed. Those clusters are your first backlog items - the high-friction, real-world problems that agents are best positioned to solve.

Capture each cluster with a simple structure:

• Proposed agent role (e.g., “auto-enrichment assistant” or “availability signal monitor”)
• Success metric (e.g., “reduce content lead time by 30%”)
• Governance requirement (e.g., “human approval for SKUs with margin above X%”)

Pick one to start. Look for something meaningful but low-risk. A quick win builds trust far faster than a sprawling, multi-quarter initiative.

Architecture on a Page

You do not need a full enterprise blueprint to start building intelligent agents. You need clarity. Translate your sticky note clusters into a simple architectural snapshot by answering five questions:

• What triggers this workflow?
• Where does context need to persist?
• Which APIs, tools, or data sources does the agent rely on?
• Where is human oversight required?
• What is the ideal handoff between human and agent?

This single-page view becomes the fastest way to align engineers, product managers, and business owners around what you are actually building. The goal is clarity, not perfection.

Pilot, Measure, Iterate

The first version of any agent should be intentionally small. Ship it to a limited team and evaluate the results by pairing hard data with qualitative feedback. Ask the people using it daily: when does the agent help? When does it get in the way? Where do you trust it, and where do you not?

Start with light guardrails - permissions, fallback logic, approval steps - and revisit them as confidence grows. Every four weeks, review your data, tune the prompts, and update your assumptions. This iterative rhythm is how agentic systems mature into reliable, scalable tools rather than remaining disconnected experiments. Tools like LangSmith can help track agent behavior and support outcome evaluation along the way.

No rollout is flawless, but you can avoid the most common pitfalls with a bit of foresight:

• Trying to automate everything at once. Broad scope kills momentum. Start narrow.
• Skipping ownership. Every agent needs a champion who understands both its purpose and its boundaries.
• Ignoring governance until late in the process. Bring risk and compliance into the conversation early, not as a gate at the finish line.

Momentum comes from clarity and focus, not from scope.

Build Your Agentic Roadmap at a Sustainable Pace

You do not need a sweeping transformation plan. You need a path that keeps moving:

1. Align: Run the EventStorming session. Bring in the right voices and build a shared view of the work.
2. Prioritize: Convert friction points into a backlog. Choose one pilot with high impact and low risk.
3. Design: Define the agent’s role, KPIs, guardrails, and the collaboration model between humans and agents.
4. Build: Ship something lightweight with observability built in from day one.
5. Iterate: Refine based on data and feedback. Scale what works. Sunset what does not.

Sticky notes do not just reveal the story - they build momentum. When teams co-create the path forward, the case for intelligent agents stops being hypothetical and becomes obvious.

And once your organization has a pilot running in production, you are no longer “exploring what agents could do.” You are delivering agentic experiences that make life easier for your teams and more seamless for your customers.