Step 7: Run and explain the application

Time: 10 minutes

What you’ll be ready to explain

You’ll run the complete application and explain its state, tool boundaries, permission boundary, and report limitations.

See the whole agent system

The finished application is an agent host. Its session coordinates a model, application-owned functions, and a browser running in another process:

Console application
  |
  +-- CopilotClient -------- runtime connection
       |
       `-- CopilotSession --- one conversation and its context
            |
            +-- accessibility_rule_lookup
            |     same process, application-owned data
            |
            +-- write_accessibility_html_report
            |     same process, fixed report output only
            |
            `-- Playwright MCP
                  separate process, scoped permission handler
                       |
                       `-- Browser target

Take the design beyond this workshop

Understanding these boundaries lets you reuse the design in another application instead of only reproducing the workshop code. A database lookup, deployment service, or issue tracker may use different tools, but the same ownership and trust questions apply.

The complete flow is URL -> Playwright inspection -> C# WCAG lookup -> structured accessibility report -> constrained local HTML writer.

Take a victory lap

There is no additional code to change. Keep the completed Step 6 application in place so this run tests the report generator and its constrained HTML report writer.

Run it

dotnet run --project workshop-app

Use the workshop target:

https://jamesmontemagno.github.io/workshop-accessibility-agent/target-app/

Watch for all six stages:

The client connects and creates one session.
Playwright navigates to the exact target and creates an accessibility snapshot.
The narrow local reader returns that current-run snapshot.
The local catalog is called for browser-supported findings.
The response follows the report contract and states its limits.
The fixed-output writer creates reports/accessibility-report.html, which you can open and filter locally.

The controlled target intentionally includes browser-observable issues: a missing text alternative, no main landmark, an illogical heading sequence, and a textbox without an accessible name. Compare the report with the published target HTML; do not accept a finding that is absent from both the snapshot and source.

Troubleshooting the complete run

Symptom	Fix
A known issue is omitted	Agent output can vary. Rerun once, but require evidence rather than forcing a predetermined answer.
A reported issue is not in the page	Reject it as ungrounded; the prompt requires specific browser evidence.
A tool is denied	Check that `browser_navigate` uses the exact entered target.
The reader finds no snapshot	Keep the prompt order: navigate before calling `read_latest_accessibility_snapshot`.

You have completed the core workshop when: the report is grounded, the tool names are visible, the HTML artifact stays in its fixed report location, and you can answer the architecture questions below without reading the code.

Check your understanding

What state belongs to the session?
Why is the WCAG catalog local?
Why is Playwright external?
Where are permissions enforced?
Why does the report writer use a fixed output path instead of accepting a path from the model?
What changes when another MCP server is added?

Compare your explanation

The session owns one conversation’s messages, model response, and tool results.
The application owns the catalog data and deterministic lookup, so the function stays local.
Playwright is a reusable browser capability with its own Node.js process and dependencies.
The MCP tool allowlist exposes only navigation, and WorkshopPermissionHandler approves only the exact target. The trusted local reader accepts no path and reads only a new generated snapshot; the catalog is also read-only. Those application-owned tools skip permission.
A fixed output path limits file creation to the report artifact; a model-controlled path would unnecessarily broaden the application-owned tool’s authority.
Add the server configuration, expose only needed tools, define its trust policy, and keep observing its calls through the same session event stream.

Keep exploring

Try Optional: Select a model if your application needs explicit control over model choice. Otherwise, the core workshop is complete.

Complete references: