AI Augmentation Scenarios

A scenario is a complete piece of work an architect comes to AI Power Tools to get done: install AI Power Tools and check that it works, build a model from a requirements document, build a modeling language, validate a model against a standard, produce a reporting database. Each scenario names who it is for, what you end up with, which skills carry the work, where you must decide, and how to check that the result is right.

Parts 3 and 4 describe the parts. This part shows them working together, and shows where a human has to decide. There are 39 scenarios. After Getting started and operations, they are grouped by the four things AI does for an architect: Modeling, Analysis, Governance and Stakeholder Engagement. AI-Augmented Enterprise Architecture describes the practice behind the four.

How to read a scenario

The structure of every scenario

Every scenario follows one structure, so you can find the same thing in the same place.

Who decides in a step

In every scenario the AI plans and drives, and AI Power Tools does the computing and checking, through deterministic or rule-based steps. See section 0.5 for what each label means. The marks on each step say which part is which.

Engine steps are the deterministic or rule-based computing done by the code engines in Code engines. Where a scenario depends on an engine, its Where it runs table says what happens on a surface without local code execution. When the AI hands you a step marked AI with computer use; otherwise you, it tells you what to do and asks what you see, and the scenario still completes. A dialog that EA raises is handled the same way in every scenario. With computer use, the AI sees the dialog in EA's window, reads it, uses the message to correct the call, dismisses it and carries on. Without computer use, you take a screenshot of the dialog and paste it into the conversation so the AI can analyze it, and then you dismiss the dialog so processing can continue.

You marks the points where the AI should stop and ask. Some are choices that are yours because the result is visible to your organization: names, the shape of a model, which stereotypes a language includes. Others are approvals before something that cannot be undone. A write step with no You before it is one to be careful with.

Where it runs

Every scenario has a Where it runs subsection straight after its Goal. It answers one question before you start: can I do this on the AI client I use? The answer depends on four capabilities. The MCP server is always present. The other three vary by surface, which is the AI client you work in. The table of surfaces is in Capabilities and surfaces.

Each scenario has one row for each of four surfaces: Claude Code, Claude Cowork, Claude Desktop chat, and VS Code with GitHub Copilot. A row says one of these:

A row can combine these and name what is left out. Starting EA and opening the model, and dealing with any dialog EA raises, are UI steps in every scenario that touches a model.

Who does each step. With computer use the assistant can start EA, read and dismiss its dialogs, look at the real EA window, and carry out tasks that exist only in EA's interface. With local code execution it runs the engines. The step marker shows who does each task.

The index below lists, for each scenario, what it needs beyond the MCP server. Starting EA and clearing its dialogs are common to every scenario that touches a model and are not repeated there. Computer use is listed when the scenario has UI steps of its own.

Examples use Westbrook Bank

Every example uses Westbrook Bank, a fictitious bank, with the modeling technology WBA (version 1.1.1), the display name WestbrookBankArchitecture, 15 element stereotypes such as WBABusinessApplication (qualified as WBA::WBABusinessApplication), 3 connector stereotypes (Uses, Flows and realizes), and the model file WestbrookBank.qea.

Westbrook is an illustration, not a prerequisite. You do not need the Westbrook model, and no scenario depends on it. Wherever a Westbrook name appears, substitute your own technology, stereotypes, packages and file paths.

Prompts are starting points

The prompts are written in plain language on purpose. The skills tell the AI what to do, so you do not need to name operations, and the AI should not ask you to. Expect the AI to restate its plan, name the model it is about to change, and ask before its first write.

Before any scenario

Three habits apply to every scenario that touches a model.

1. Run the start-of-session check. It confirms the server answers, which model is open, and which modeling technologies are really loaded and enabled. See ea-start-here and Start a session safely. Most failures come from a model that is not the one you think is open.
2. Take a baseline before a bulk or destructive change. See Protect a change with a baseline. Deletions made through EA's automation interface cannot be undone.
3. Look at what was built. A result that says it succeeded means data was written. It does not mean the diagram looks right. Reload and render it, or look at it in EA.

Scenario index

Scenarios by persona

The personas are roles, and one person often holds several. Start with the persona that matches your job, then follow the cross-references. A persona is a hint about who a scenario is written for, not an access control.

If you have never used AI Power Tools, start with Install and verify and Start a session safely, then Trace dependencies (it reads the model and changes nothing) before any scenario that writes.

Impact and traceability questions

Impact analysis across the repository, traceability coverage ("which requirements have no realizing element?") and as-is and to-be gap analysis are answered from deterministic operations: trace_connectors, find_paths and get_traceability_tree in ea_analyze, direct model queries, and baseline comparison. You ask in plain language, and the AI picks the operation.

The Analysis scenarios put these questions to work: Assess the impact of retiring a system, Check traceability coverage and Compare the as-is and to-be architecture, built on Trace dependencies. prol-impact-analysis (Trace the impact of a change in Prolaborate) is a different thing: it traces impact through Prolaborate's own query surface, not through the EA repository.

What to expect from a run

• The AI plans from the skill, so context matters more than wording. Say what you want, which model it applies to, and what must not change.
• Results vary by model. Each scenario's recommended-models table rates fit from the kind of reasoning the task needs. Open-ended design, long plans and visual judgment favor the stronger models. Procedural work that AI Power Tools or a code engine computes runs well on the lighter ones. The ratings are guidance.
• Long scenarios split. Large builds are best run one phase per session, seeding each session with a targeted question about the current state of the model rather than an open-ended request to describe it.
• Models that run on your device. VS Code with GitHub Copilot can also use AI models that run on the device. The model guidance in this part is written for Claude models. A scenario whose work is mostly done by code engines depends least on the model, and a scenario that relies on AI judgment depends most.
• One EA instance. The server drives the EA instance that is already running. Never start a second instance against the same model file, and do not repeat a request that appears to hang before looking at EA for a dialog. With computer use the AI sees the dialog in EA's window, reads it, uses the message to correct the call, dismisses it and carries on. Without computer use, you take a screenshot of the dialog and paste it into the conversation so the AI can analyze it, then dismiss the dialog so processing can continue. Troubleshooting covers the symptoms.