Model domain behavior before an agent implements it

Use Event Storming in My Architect when a change spans commands, events, policies, or service boundaries. The useful outcome is a behavioral model with explicit gaps and decisions that an agent can read alongside the work’s requirements.

Model the behavior on the relevant work

Attach the diagram to the epic or initiative it explains. Record actors, commands, aggregates, events, policies, read models, and external systems where they matter to the scenario. Use hotspots for unresolved questions, such as which component owns a failure-recovery decision.

An agent can use create_diagram with diagramType: "event-storming", a verified nodeId, and the diagram DSL. Use get_diagram to inspect an existing diagram’s exact content before editing. update_diagram replaces the complete DSL; preserve unrelated content and other contributors’ changes.

A small example of the supported text format is:

event-storming
group "Checkout"
  [command] "Place order"
  [aggregate] "Order"
  [event] "Order placed"
  [hotspot] "When should an unpaid order expire?"
connect "Place order" -> "Order"
connect "Order" -> "Order placed"

This is a starting model, not an implementation specification or evidence of correct business behavior.

Inspect sequence gaps

get_diagram returns a sequence analysis for an Event Storming board. Creation and updates can also return that analysis. Review reported gaps such as events without causes, commands without outcomes, disconnected policies, isolated cards, or unresolved hotspots.

Refine the board and read it back. The analyzer checks modeled relationships; it cannot decide an unresolved business rule or prove that the implementation follows the diagram.

Preserve questions beyond the workshop

After reviewing the node’s boards, call sync_diagram_hotspots with the exact project and node:

{
  "pid": "Example Project",
  "nodeId": "epic-checkout"
}

Replace these illustrative IDs with verified values. The tool creates OQ requirements for unmatched hotspot titles and preserves approved decisions. Its matching uses exact titles within the node. A still-draft OQ whose title no longer appears among the node’s board hotspots is deprecated; review that scope before invoking synchronization.

Record the decision and rationale when a question is resolved. Removing a card alone is not evidence that someone made the required decision.

Turn the model into claimed work

Link the applicable requirements and decisions to proportionate work items, then follow multi-agent coordination. Agents need their own claims before executing managed work. A diagram does not create an assignment or bypass open-question and delivery checks.

Use WBS for decomposition, User Story Mapping for release journeys, or Box for structure when those views better fit the task. For final acceptance, follow verify delivery.

Model the accepted checkout change in My Architect. Read the current diagram and requirements, identify missing behavioral steps and open decisions, and preserve the questions in the relevant work. Propose separable implementation tasks with clear acceptance conditions before claiming them.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.