> For the complete documentation index, see [llms.txt](https://dyns.ntd.asia/power-dynamics/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dyns.ntd.asia/power-dynamics/artificial-intelligence/study-copilot-studio/testing-and-capstone/capstone-the-full-northwind-outfitters-agent.md).

# Capstone: The Full Northwind Outfitters Agent

Session 8.3 (capstone, Group 8 complete): the full Northwind Outfitters agent — conversational, autonomous, and multi-agent — run together for the first time, with three flagged gaps re-checked live.

{% hint style="info" %}
**Session 8.3 of 3 — Group 8 (Testing & Capstone), final session.** This completes Group 8 and the full eight-group Copilot Studio learning plan.
{% endhint %}

Twenty-six sessions built one agent in pieces: a topic here, a tool there, a trigger, five agent connections, a governance layer, a test set. Nothing in this course has ever run all of it — conversational core, autonomous trigger, and multi-agent handoff — as one system, tested together. This session does that, then spends its last few paragraphs on something more honest than a victory lap: re-checking, today, whether the three gaps this course flagged and deliberately left open ever got fixed. They didn't. A finished system that still knows its own edges is the actual endpoint of the mission's knowledge-to-skill argument — not a system with no edges left.

{% hint style="success" %}
This is a review-and-build session, like 2.4, 3.3, 4.5, 5.3, and 6.5 before it — no new Copilot Studio mechanism is introduced. Its job is to wire everything already verified into one working, tested agent, and to check — not assume — whether anything about the system's known limits has changed.
{% endhint %}

## One agent, traced through eight groups

Northwind Outfitters has never been eight separate builds. It's been one growing agent, and every group added a real layer to it.

| Group                     | What it added to the running agent                                                                                                                               | Where it lives today                                                  |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| 1 — Foundations           | The orchestration model itself: generative orchestration deciding, turn by turn, which topic, tool, or knowledge source to reach for                             | The agent's core decision loop — everything below routes through it   |
| 2 — Core building blocks  | Topics, trigger phrases, entities/variables, generative answers & instructions                                                                                   | The "Track My Order" topic and the agent's base instructions          |
| 3 — Knowledge & grounding | FAQ and returns-policy knowledge sources, citation behavior, Azure AI Search                                                                                     | Agent-level knowledge grounding every generative answer               |
| 4 — Tools & actions       | The 4.3 order-status REST tool, the 4.2 return-approval agent flow, the 4.4 adaptive-card responses                                                              | Wired into the 4.5 return-and-refund build                            |
| 5 — Autonomous behavior   | The return-follow-up Dataverse event trigger, with three decision-boundary layers built as three different shapes                                                | Published and running independently of any conversation               |
| 6 — Multi-agent           | Five live connections: Billing, Product-Support (connected agents), Returns Risk Scoring (Foundry), Meridian Freight (A2A), Sales & Inventory Insights (Fabric)  | Orchestrated under one parent agent, tested together in 6.5           |
| 7 — Governance            | Authenticate manually (Generic OAuth2), DLP data policies, Moderate content filtering, a solution container with environment variables, Power Platform pipelines | Wraps the whole system, not any one piece of it                       |
| 8 — Testing               | Single-response and conversational test sets, covering FAQ grounding, the order-status tool, and the 6.2 handoff                                                 | Runs against the live agent, with one documented coverage gap (below) |

## What "capstone" actually means here: one test, three layers

Every prior closing session (2.4, 3.3, 4.5, 5.3, 6.5) consolidated one group's own mechanisms. This one is different — it's the first test case in the whole course built to cross group boundaries on purpose: a conversational exchange that triggers a tool, crosses the 6.2 handoff, and ends with the same event that 5.2's autonomous trigger watches for.

{% stepper %}
{% step %}

### Turn 1 — Product-Support, grounded

"My order #48213 arrived with a cracked case — can I get a refund?" Routes to the Product-Support connected agent (6.2), grounded against the returns-policy knowledge source (Group 3), citing the source per 3.2's grounding rules.
{% endstep %}

{% step %}

### Turn 2 — the tool fires mid-conversation

"Can you check if it actually shipped correctly first?" Calls the 4.3 order-status REST tool without losing the refund thread already open — the same tool-mid-conversation shape 8.2's own three-turn Northwind test case exercised.
{% endstep %}

{% step %}

### Turn 3 — the handoff, and the agent flow

"Okay, please process the refund." Crosses to Billing (6.2's connected-agent handoff, conversation history passed per that session's checkbox), which invokes the 4.2 Request information/Approval agent flow\[7] with Asynchronous response, closing with the 4.4 adaptive-card confirmation once approved.
{% endstep %}

{% step %}

### Turn 4 (async) — the trigger picks up where the conversation left off

Once the Dataverse row backing this return flips to **Status → Completed**, 5.1/5.2's return-follow-up event trigger\[6] fires independently of the conversation above — the same Dataverse condition, reached this time by a real refund the conversation just approved rather than a manual test.
{% endstep %}
{% endstepper %}

Nothing about this sequence needed a new mechanism. Every step reuses a piece already verified in an earlier session. What's new is running them end to end and asking, honestly, what actually happens at the seams.

## Evaluating it: what 8.1/8.2's methods can actually cover

The four-turn sequence above maps onto a conversational test set (8.2), scored with the three methods a cross-handoff exchange can actually use.\[4]

| Test method     | What it checks in this capstone case                                                                                  |
| --------------- | --------------------------------------------------------------------------------------------------------------------- |
| Tools use       | The order-status tool fires by turn 2, not skipped and not fired at the wrong turn.                                   |
| Keyword match   | "refund" and a policy-specific term appear somewhere across the exchange, regardless of which subagent said them.     |
| General quality | Catch-all for whether the whole four-turn exchange actually held together across the Product-Support→Billing handoff. |

{% hint style="warning" %}
**What it can't cover.** Turn 4 — the autonomous trigger firing off the same Dataverse row — happens outside the conversation the test set is scored against. Standard-harness evaluation, per every session-8 source, tests conversations and single responses. It has no documented method for asserting "and then this event trigger fired as a consequence." That's not a product failure to flag as a bug. It's a real seam between two systems (conversational evaluation and autonomous-trigger monitoring) that this course built separately in Groups 5 and 8, and has never had reason to test as one thing before this session — and still can't, fully, today.
{% endhint %}

## Three gaps this course left open — re-checked today, not assumed

A capstone is the natural place to ask whether earlier findings still hold. Three sources flagged as open, unresolved questions in Groups 5, 7, and 8 were re-fetched live for this session rather than carried forward from memory.

{% hint style="danger" %}
**Still open — Fabric data agent evaluation (flagged 8.1).** `analytics-agent-evaluation-intro`, re-fetched today: "Currently, agent evaluation doesn't support Fabric data agents." Page footer dated 2026-06-06 — updated since 8.1's own August fetch, and the sentence didn't change. Northwind's Sales & Inventory Insights connection (6.4) still has no path into either evaluation surface.\[1]
{% endhint %}

{% hint style="danger" %}
**Still open — multi-agent handoffs in the Activity page (flagged 6.5).** `authoring-review-activity`, re-fetched today: the page lists autonomous-trigger activity as one of four sources of historical activity, but still says nothing — positive or negative — about how a connected-agent, A2A, Foundry, or Fabric handoff renders in the transcript or map view. The same honest "we don't know" 6.5 landed on stands unchanged.\[2]
{% endhint %}

{% hint style="danger" %}
**Still open — DLP reach into external agent connections (flagged 7.1).** `admin-data-loss-prevention`, re-fetched today: the seven documented use cases (require authentication, block knowledge sources, block connectors, block HTTP requests, block skills, block channel publishing, block event triggers) are unchanged from 7.1's own count. None names gating a connected, Foundry, A2A, or Fabric agent connection. Whether a data policy can wall off Meridian Freight's A2A link — still the one connection carrying Northwind's conversation history outside its own walls — remains undocumented either way.\[3]
{% endhint %}

All three gaps are current as of today's fetch, not a stale finding copied forward. That distinction matters for the same reason 8.1 insisted on a live fetch for a feature maturing near this model's training cutoff: a system this course has watched evolve every few sessions (new preview features, a GA date landing mid-course, a documentation page updated in June) deserves a fresh check, not an assumption that August's finding is still September's.

## The full architecture, in one picture\[5]

```mermaid
flowchart TD
    User(["Customer message"]) --> Orchestrator["Northwind Outfitters agent<br/>(generative orchestration)"]
    Orchestrator -->|"routing"| PS["Product-Support<br/>(connected agent, 6.2)"]
    Orchestrator -->|"routing"| Bill["Billing<br/>(connected agent, 6.2)"]
    PS -->|"grounds on"| KB["FAQ / returns-policy<br/>knowledge sources (Group 3)"]
    PS -->|"calls"| Tool["Order-status REST tool (4.3)"]
    Bill -->|"invokes"| Flow["Return-approval agent flow<br/>Request info + Approval (4.2)"]
    Flow -->|"on completion"| Card["Adaptive card confirmation (4.4)"]
    Orchestrator -->|"connects"| Foundry["Returns Risk Scoring<br/>(Foundry agent, 6.3)"]
    Orchestrator -->|"connects"| A2A["Meridian Freight<br/>(A2A external agent, 6.4)"]
    Orchestrator -->|"connects"| Fabric["Sales & Inventory Insights<br/>(Fabric data agent, 6.4)"]
    DV[("Dataverse: return row<br/>Status field")] -->|"row updates to Completed"| Trigger["Return follow-up<br/>event trigger (5.1/5.2)"]
    Flow -.->|"approval writes the row"| DV
    Gov["Governance wrapper (Group 7):<br/>Authenticate manually · DLP · Moderate filter<br/>Solution + environment variables · Pipeline"] -.-> Orchestrator
    Eval["Evaluation (Group 8):<br/>single-response + conversational test sets"] -.->|"scores"| Orchestrator
    Eval -.->|"no documented path"| Fabric
```

## Check your retrieval

{% tabs %}
{% tab title="Question 1" %}
This session's four-turn capstone test case ends with the return-follow-up event trigger (5.1/5.2) firing once the Dataverse row updates to Completed. Can 8.1/8.2's evaluation methods score that trigger firing as part of the conversation test case?
{% endtab %}

{% tab title="Answer" %}
No — standard-harness evaluation scores conversations and single responses; it has no documented method for asserting a downstream event trigger fired. Conversational and single-response evaluation both score what happens inside the scored exchange itself. An autonomous trigger firing afterward, off a Dataverse change the conversation caused, sits outside any test method this course has verified — a real, currently-unaddressed seam between Group 5's autonomous mechanisms and Group 8's evaluation surface.
{% endtab %}
{% endtabs %}

{% tabs %}
{% tab title="Question 2" %}
Re-fetching `admin-data-loss-prevention` live for this session, what changed about the DLP use-case list 7.1 first documented?
{% endtab %}

{% tab title="Answer" %}
Nothing — the same seven use cases are documented, still with no mention of gating connected, Foundry, A2A, or Fabric agent connections. The re-fetch found the identical seven-item list (authentication, knowledge sources, connectors, HTTP requests, skills, channel publishing, event triggers) with no new item addressing external agent connections — 7.1's flagged gap is confirmed still open, not resolved by a documentation update.
{% endtab %}
{% endtabs %}

{% tabs %}
{% tab title="Question 3" %}
Why does this session insist on live-fetching the three previously-flagged gaps rather than simply repeating what 5.3/6.5, 7.1, and 8.1 already found?
{% endtab %}

{% tab title="Answer" %}
Because a system this course has watched change every few sessions (new GA dates, updated pages, shifting previews) deserves a current check rather than an assumption that an earlier finding is still true weeks later. The VERIFY stage exists precisely for claims that could have changed — and this course has directly observed features move from preview to GA mid-course (evaluation itself, the connector-vs-REST-API split). Re-checking rather than assuming is the same discipline 8.1 applied when it live-fetched a feature maturing near the model's training cutoff.
{% endtab %}
{% endtabs %}

{% tabs %}
{% tab title="Question 4" %}
In the full-architecture diagram, which connection has no documented path into either evaluation surface at all?
{% endtab %}

{% tab title="Answer" %}
Sales & Inventory Insights, the Fabric data agent. 8.1 first flagged that agent evaluation doesn't support Fabric data agents at all, and this session's live re-fetch confirms the same sentence still appears in the current documentation. Northwind's Sales & Inventory Insights connection (6.4) remains untestable by either evaluation surface this course has covered.
{% endtab %}
{% endtabs %}

{% hint style="success" %}
**Key takeaway.** The capstone isn't a bigger build — it's the same pieces from eight groups run together for the first time, with the honest result that some seams (autonomous triggers inside a scored conversation, Fabric evaluation, DLP on external connections) still don't have a documented answer, re-confirmed live rather than assumed unchanged.
{% endhint %}

## Reflection

<details>

<summary>The mission's own argument was that skill — not knowledge — is what real iteration produces, tested against whether something you built actually holds up. This capstone found three places where the system's documented behavior simply stops (autonomous-trigger visibility in Activity, Fabric evaluation, DLP on external connections). Does finding real, still-open gaps at the end of a capstone undercut that argument, or complete it?</summary>

**One reasonable answer:** It completes it. The mission never claimed the endpoint of skill is a system with no unknowns — it claimed skill comes from finding out whether something holds up, through real iteration, rather than assuming it does because the documentation exists. A capstone that quietly avoided re-checking these three gaps, or asserted they'd surely been fixed by now, would have reverted to "the library" the mission opened by rejecting — knowledge asserted, not tested. Finding that all three gaps are still open today, verified live rather than carried forward from memory, is the exact practiced competence the mission named: not a system that pretends to have no edges, but a builder who knows exactly where the edges are because they went and checked.

</details>

**Read next:** [Study guide for Exam AB-620](https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/ab-620)\[8] — the certification-skills outline this course has mapped its groups onto since session 1; useful now as a self-check against everything Northwind's agent covers, and the natural next step if a Group 9 (exam-readiness) extension gets built.

### Sources

1. [Evaluate an agent's performance](https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-intro) — re-fetched live this session; confirms the Fabric data agent evaluation gap is unchanged (page updated 2026-06-06).
2. [Review agent activity](https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-review-activity) — re-fetched live this session; confirms the Activity page still doesn't document multi-agent handoff visualization.
3. [Data loss prevention for agents](https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention) — re-fetched live this session; confirms the seven documented DLP use cases still don't name external agent connections.
4. [Create a conversational test set](https://learn.microsoft.com/en-us/microsoft-copilot-studio/analytics-agent-evaluation-multi-turn) — reused from 8.2, grounding this session's four-turn Northwind test case.
5. [Add other agents to an agent](https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-add-other-agents) — reused from 6.1–6.4, grounding the five-connection architecture diagram.
6. [Event trigger overview](https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about) — reused from 5.1/5.2, grounding the return-follow-up trigger in the capstone build.
7. [Request information in an agent flow](https://learn.microsoft.com/en-us/microsoft-copilot-studio/flows-request-for-information) — reused from 4.2, grounding the return-approval flow step.
8. [Study guide for Exam AB-620](https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/ab-620) — reused from sessions 1 and 8.1, closing the loop this course opened on its first day.

{% hint style="info" %}
This completes Group 8 and the full Copilot Studio learning plan (Groups 1–8). See the Mission page for the complete session map and what a Group 9 extension could look like.
{% endhint %}