5.1 Monitor Agent Flows

5.1 Monitor Agent Flows

Quick Answer: Monitor agent flows at three layers: (1) the flow designer—publish status, Flow checker, version history, and per-action test runs; (2) the agent Activity page and real-time activity map—session status, step duration, tool inputs/outputs, and rationale; (3) capacity and admin analytics—agent flow actions consumed and enforcement when prepaid capacity is exhausted. Failed runs need both the chat error code and the flow run history.

Agent flows exist so multi-step work is deterministic, monitorable, and separate from free-form generative chat. Microsoft’s product guidance emphasizes end-to-end process visibility: design the flow, watch performance, and act on insights from one Copilot Studio experience. AB-620 tests whether you know where to look when a flow “worked yesterday” and fails in a channel today—not only how to drag actions onto the canvas.

Why monitoring is an exam skill

Building a flow that creates a ServiceNow incident is incomplete if you cannot:

• Prove the flow published and is the version the agent calls
• See whether a user session called the flow
• Read inputs and outputs for that call
• Separate flow action failures from schema mismatch at the agent boundary
• Notice capacity blocking new runs while in-flight runs finish

Exam stems often describe a symptom (“Teams users see FlowActionBadRequest,” “Activity shows Failed,” “no run appears”) and ask which surface you open first or which signal matters most.

Monitoring surfaces you must know

Designer monitoring (flow-centric)

Open Flows, select the agent flow, then the Designer tab. Operational habits:

1. Flow checker — Lists all design errors. Fix every error before Publish. Red-highlighted actions are not “warnings you can ignore.”
2. Parameters panel — Select a trigger or action card to review required parameters and dynamic expressions.
3. Test after publish — Run Manually or Automatically, then open each action’s outputs. Designer tests help prove the flow works in isolation.
4. Version history — Save drafts as you build; history is only useful if you actually save. Compare a known-good published version when production behavior changes after a publish.

Important capacity note from Microsoft: testing an agent flow in the designer (or from the agent’s test chat) does not consume Copilot Studio capacity, while production execution of agent flow actions does. That means a green designer test does not prove you have remaining prepaid capacity for production volume.

Agent Activity monitoring (conversation-centric)

When generative orchestration is enabled, Copilot Studio builds an activity map for each activity. An activity starts when a conversation begins or an external event triggers the agent. The map shows the sequence of inputs, decisions, and outputs as nodes.

Real-time (test chat)

• Optionally turn on Show activity map when testing so the map appears as you talk.
• Nodes highlight errors such as missing or invalid input/output parameters for actions.
• Duration per step exposes slow connectors that will blow the 100-second agent-facing response budget.
• You can inspect variables (global, environment, system, custom) used during the test.
• For supported reasoning models, Chain of Thought and on-demand Rationale help explain why a tool (including a flow tool) was selected—use as troubleshooting hints, not as legal truth, because rationale is AI-generated.

Historical Activity page

Each activity is recorded (including tests). Review to:

• Inspect interactions and decisions
• Find behavior that does not match goals
• Measure how long activities take
• Read error details

Historical activity is available for test chat; agents published to Microsoft Teams and Microsoft 365 Copilot; SharePoint channel; and activities started by autonomous triggers. Microsoft documents that historical activity data is powered by Microsoft 365 services (Exchange mailbox location) and can be controlled by admin settings—know that makers may not see other users’ transcripts unless sharing of activity transcripts is enabled by an admin.

Activity list columns and status

Agent / session status values (know these for diagnosis language):

Filter pills such as Failed, Blocked, In progress, Waiting for user, and Completed speed triage. Pin important failed sessions for later comparison after you fix the flow.

Diagnosing failed runs: a practical playbook

Use this ordered approach on the exam and in production:

1. Capture the user-facing error code from chat or test pane (for example FlowActionTimedOut, FlowActionBadRequest, FlowActionException, BindingKeyNotFoundError).
2. Open the Activity map for that session. Identify which node is the flow tool; inspect inputs the agent sent and outputs received (or missing).
3. Open the agent flow run history (flow-centric run record). Confirm whether the flow started, which action failed, and the connector error body.
4. Classify the failure:
   • Flow never started → tool description, authentication, generative selection, or connection consent
   • Flow started but failed mid-action → connector permissions, API errors, bad parameters, DLP
   • Flow succeeded but agent failed → output schema mismatch, missing Respond-to-agent outputs, stale bindings after parameter rename
   • Flow took too long → optimize queries; move non-critical work after Respond to the agent (agent waits up to about 100 seconds for the response action; background work can continue longer, up to multi-day flow limits)
5. Check capacity if many new runs stop while tests still work—prepaid agent flow capacity exhaustion blocks new production runs; runs already executing complete; Microsoft 365 Copilot licensed users and designer/test-chat flow tests are not treated the same as ordinary capacity consumption.
6. Fix, publish flow, refresh agent tool bindings if schema changed, republish agent, retest on the failing channel (not only Test pane).

Scenario — Contoso ticket agent

Contoso’s IT agent creates ServiceNow incidents via an agent flow tool. In Teams, users report “something went wrong” after describing a laptop issue. The maker opens Activity, filters Failed, and sees the last step is the Create Incident flow tool. The map shows an invalid input type for urgency. The flow run history confirms the Create Item action never ran. Root cause: the topic bound a text label (“High”) where the flow input expects a number. Fixing the binding and refreshing the tool inputs restores success. The exam lesson: Activity map + typed inputs beat guessing from the Teams error alone.

Scenario — Capacity cliff

After a marketing campaign, Contoso’s environment exhausts prepaid Copilot Studio capacity. Production agent flow runs stop starting; makers still pass designer tests. Correct monitoring response: check Power Platform admin center → Licensing → Copilot Studio for Agent flow actions, plan prepaid top-up or pay-as-you-go, and communicate that enforcement blocks new runs until capacity returns.

Analytics and continuous improvement

Beyond single-run debug:

• Track slow actions (duration on map nodes) and push heavy work after respond or into batch middle layers.
• Compare success vs failed rates after each publish using Activity filters.
• Use Rationale on completed knowledge/connector steps to see why orchestration chose a flow versus another tool—mis-selection often means weak tool Name/Description, not a broken connector.
• Align flow monitoring with later Application Insights monitoring of agents when the blueprint asks for Azure integration observability.

Monitoring checklist before go-live

1. Flow checker clean; flow Published.
2. Designer test green with realistic inputs; review each action output.
3. Agent tool bound; test chat activity map shows expected call path.
4. At least one end-to-end test on each production channel (Teams, web, etc.).
5. Capacity headroom reviewed with the admin.
6. Named owner knows how to open Activity + flow run history for incidents.
7. Version history baseline saved so regressions are bisectable.

Monitoring is not optional polish. On AB-620, resilient agent solutions are the ones you can observe, diagnose, and correct under production pressure using Copilot Studio’s flow and Activity tooling.