From “It Ran” to “Here’s What Happened” in Copilot Studio

As Copilot Studio agents become more capable, a simple chat transcript is rarely enough to debug them. An agent may invoke skills, tools, connectors, MCP servers, knowledge sources, workflows, and file-processing steps before returning an answer. When something goes wrong, developers need answers to practical questions:

A lightweight Conversation Run Log, created per conversation or run, gives developers a clear, shareable execution record. It does not replace platform telemetry—but it makes troubleshooting, handover, and quality reviews far more repeatable.

This article compares two useful logging patterns: a detailed execution trace and a concise capability-centred audit summary.

Method 1: Prompt-led plan and on-demand run log: This is the quickest approach for development and testing. At the start of a conversation, ask the agent to create a plan and log the work as it goes.

For this conversation, please create a Plan markdown file and log all the steps so that I can test and export. Enter fullscreen mode Exit fullscreen mode The agent creates a plan that describes the intended workflow—such as receiving a file, invoking a skill, checking outputs, creating a report, and returning artifacts. At the end of testing, prompt the agent: Conversation Run Log or: Create a Conversation Run Log markdown file for this conversation. The agent then creates a Markdown summary based on the conversation context and any execution details available during that session.

Limitation This method is session-dependent. The agent can only reconstruct the run from context and telemetry it can still access in the current conversation. If the generated file was temporary and is no longer present in the runtime storage location, it may need to be regenerated before you leave the session.

_Practical tip: Download the Plan and Conversation Run Log while the session is still active. Do not assume a generated file will remain available after the runtime session ends or resets. _

Method 2: Instruction-led audit logging: This approach adds run-log expectations directly to the agent instructions. Instead of relying on the developer to remember the starter prompt each time, the agent is guided to capture a consistent audit record whenever it runs a relevant task.

### Run Log Requirements Capture the following, where available: - Conversation ID, session ID, run/trace/correlation ID - Agent name, environment, and UTC start/end timestamps - User request and relevant follow-up instructions - Capabilities invoked: tools, MCP servers, skills, knowledge sources, actions, connectors, workflows, and files - A concise record of each material step, including status and output summary - Generated artifacts and their filenames - Warnings, errors, limitations, and recovery guidance - Final status: `Completed`, `Completed with warnings`, `Partial`, or `Failed` Do not invent IDs, timestamps, telemetry, capability activity, or execution results. Use: `Not available in current session` for information not exposed by the platform. Never include secrets, credentials, tokens, connection strings, or sensitive user data in the log.

If processing is incomplete or fails, return the log showing completed steps, the failure point, and what is needed to continue. Only confirm successful completion when the required capability execution and requested deliverables have actually completed. Enter fullscreen mode Exit fullscreen mode Why it is useful

Limitation An instruction can guide the agent to produce a log, but it cannot guarantee that the platform exposes every internal execution detail. For example, conversation IDs, run IDs, tool telemetry, or precise timestamps may not be available to the agent at runtime.

It also does not automatically solve file persistence: if the Markdown file is generated in temporary runtime storage, it must be downloaded or exported while available.

Take away: Use a plan to test intent, use a run log to prove execution, and export both before the runtime session ends.