Integrate and extend agents in Copilot Studio

Integrate and extend agents in Copilot Studio Detailed Explanation

Connect agents to enterprise knowledge sources including Copilot connectors, Power Platform connectors, and Azure AI Search

Exam Radar

Core Priority: This is a retrieval-boundary topic. The exam may describe ServiceNow, SAP, Power Platform data, documents, or indexed engineering content and ask which knowledge connection gives the required freshness, schema, and permission behavior.

High Frequency: Expect comparison between Copilot connectors, Microsoft Power Platform connectors, Azure AI Search, RAG expectations, source-system permissions, searchable fields, filters, index freshness, and permission trimming.

Confusion Alert: A knowledge question may mention weak answers, but the cause can be stale indexer execution, non-retrievable fields, missing filters, or source permissions rather than prompt wording.

Scenario Logic: An agent must answer support-policy questions from ServiceNow articles, product documents, and indexed engineering content with permission-aware retrieval. The best first move is the one that preserves identity, data boundary, execution contract, or evidence collection before optimizing the conversation wording.

Version Delta: Enterprise knowledge scope includes Copilot connectors, Microsoft Power Platform connectors, and Azure AI Search, so the exam can test RAG-style retrieval, source freshness, and permission-aware access rather than file upload alone.

Failure Trigger: Failure appears as an indexer error, zero retrieved documents, missing searchable/retrievable fields, stale document count, or a permission-trimmed result that does not match the test user's access.

Operational Dependency: Knowledge integration is a retrieval and permission problem first; the correct source choice depends on where content lives, how it is indexed, and how access trimming is enforced.

How the Exam Asks It: A question may describe a business scenario, a failing Copilot Studio configuration, or a deployment constraint and ask for the best design, first troubleshooting step, or required component.

How Distractors Are Designed: Distractors often solve a visible symptom while ignoring the owning object. They may suggest prompt tuning for a permission problem, a connector for a retrieval problem, a channel change for a flow exception, or manual deployment for an ALM dependency.

Why the Correct Answer Works: The correct option works because retrieval quality and permission behavior are owned by the selected knowledge integration, not by a prompt-only workaround.

Practice Question: An agent must answer support-policy questions from ServiceNow articles, product documents, and indexed engineering content with permission-aware retrieval. Which knowledge integration approach should you choose?

A. Upload exported PDFs into every agent and ignore source-system permissions.
B. Use only a REST API action because every retrieval workload requires action execution.
C. Store all source text in topic instructions so the model can answer without retrieval.
D. Select the connector or Azure AI Search integration that matches the source system, indexing model, permission boundary, and freshness requirement.

Correct Answer: D

Explanation: A is wrong because exported PDFs break source freshness and can bypass source-system permission behavior. B is wrong because a REST API action performs calls, but the scenario asks for retrieval and permission-aware grounding. C is wrong because topic instructions are not a governed retrieval store and cannot maintain source freshness or access trimming. D is correct: Knowledge integration is a retrieval and permission problem first; the correct source choice depends on where content lives, how it is indexed, and how access trimming is enforced.

Troubleshooting Practice Question: Users report that the agent cannot answer from a document added to the source yesterday, but older documents still work. What should you inspect first?

A. Azure AI Search indexer execution history, document count, and retrievable fields.
B. The agent icon and welcome message.
C. A new REST API action for the same source.
D. A broader generative instruction in the topic.

Correct Answer: A

Explanation: New content missing while old content works is a freshness/indexing signal. Indexer history and schema evidence should be checked before changing prompts or creating action tools.

Exam Takeaway: For weak or missing grounded answers, verify the retrieval source, index freshness, retrievable fields, filters, and permission trimming before editing response wording.

Best Choice Rules: If the stem mentions source-system permissions, validate connector identity and permission-aware retrieval. If the stem mentions stale or irrelevant RAG answers, check indexer freshness, schema, retrievable fields, and filters before prompts. If the stem asks for business action execution, do not answer with a knowledge-only retrieval source.

Atomic Deconstruction - Operational Level

Enterprise knowledge integration is not the same as action execution. A knowledge source feeds retrieval and grounding; a tool or API performs an action. Copilot connectors are useful for supported enterprise sources, Power Platform connectors can expose platform data and operations, and Azure AI Search is relevant when the solution needs controlled indexing, field schema, filtering, or vector and hybrid retrieval.

Operationally, start with source ownership and access behavior. A connector-backed source must prove connection health and permission behavior; Azure AI Search must prove indexer freshness, searchable/retrievable fields, filters, and vector or hybrid schema where used. Prompt changes come after retrieval evidence, not before it.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Copilot connector	Source system connection	ServiceNow, SAP, supported enterprise sources	Disconnected	Connector configuration and permissions	Agent cannot retrieve governed enterprise content
Power Platform connector	Data/action bridge	Standard, premium, custom	Connection required	DLP and connection reference	Connector blocked or returns unauthorized data
Azure AI Search index	Schema and retrieval fields	Searchable, filterable, vector fields	No index attached	Indexer and identity	Relevant documents are not returned or cannot be filtered
Permission trimming	User access enforcement	Delegated or source-aware permissions where supported	Unverified	Identity mapping	Agent may over-share content or hide authorized content

Step-by-Step Execution Path

Classify the source as enterprise connector content, Power Platform connector data, or indexed search content. This avoids using an action tool when the requirement is knowledge retrieval.
For connector-backed sources, verify connection status and identity behavior in Copilot Studio or the connector admin surface. The retrieval path must respect the intended user permission model.
For Azure AI Search, inspect the index schema, searchable fields, vector fields, filters, and indexer status in the Azure portal. Retrieval quality usually fails at schema or indexing before it fails at prompt wording.
Test with a user who should and should not see a known item. Permission-aware evidence is stronger than a generic successful answer.

Evidence note: retrieval checks rely on connector status, source permissions, Azure AI Search index schema, indexer execution history, and grounded answer evidence where supported.

Technical Chain

A user question is routed to a knowledge retrieval path. The connector or search integration uses its configured identity, source connection, index, filters, and retrievable fields to return candidate content. The agent then grounds the response in those retrieved passages or records. If the wrong integration type is chosen, the result may be stale, over-permissive, missing filters, or treated as an action call instead of retrieval evidence.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Inspect connector status	Copilot Studio > Knowledge or Tools > selected connector configuration	Connection is active and scoped to the intended source system
Check Azure AI Search index schema	Azure portal > AI Search > Indexes > selected index	Searchable, retrievable, filterable, and vector fields match the retrieval design
Validate indexer freshness	Azure portal > AI Search > Indexers > execution history	Latest run succeeded or exposes a specific source/indexing failure
Test permission-aware retrieval	Copilot Studio test pane with representative user access	Authorized content is returned and restricted content is not exposed

Add tools to agents with computer use, MCP tools, custom connectors, and REST APIs

Exam Radar

Core Priority: This is an action-surface topic. The question normally gives a target system and asks which tool mechanism matches the available interface: UI automation, MCP server tools, governed connector operations, or direct HTTP API calls.

High Frequency: Expect scenarios about computer use, MCP tools, existing custom connectors, REST APIs, authentication, operation schemas, response mapping, and monitoring of tool execution.

Confusion Alert: A tool question may name several integration options; the trap is choosing the most familiar option instead of matching UI automation, MCP schema, custom connector governance, or REST payload requirements to the target system.

Scenario Logic: A Copilot Studio agent must update a legacy system that has no modern API, call an internal API, and expose a governed reusable action. The best first move is the one that preserves identity, data boundary, execution contract, or evidence collection before optimizing the conversation wording.

Version Delta: Tool scope includes computer use, MCP tools, existing custom connectors, and REST APIs; the candidate must match the integration type to the external system surface.

Failure Trigger: Failure appears as an MCP tool not listed, rejected tool arguments, custom connector authentication error, REST 401/403/422 response, or computer use run stopping at the first unexpected screen state.

Operational Dependency: Tools are action surfaces with different contracts; selecting the tool type by integration boundary prevents unsupported automation and ambiguous execution.

Why the Correct Answer Works: The correct option works because it matches the tool mechanism to the real action surface, then validates schema, authentication, and runtime evidence.

Practice Question: A Copilot Studio agent must update a legacy system that has no modern API, call an internal API, and expose a governed reusable action. Which tool type should you select?

A. Use generative answers for every operation because knowledge nodes can modify external systems.
B. Choose the tool type by action surface: computer use for UI automation, MCP for exposed tool servers, custom connectors for governed APIs, and REST API actions for direct HTTP integration.
C. Create only one topic per external system and describe the action in natural language.
D. Use Azure AI Search because search indexes can submit updates to operational systems.

Correct Answer: B

Explanation: A is wrong because generative answers are retrieval and response behavior; they cannot modify external systems by themselves. B is correct: Tools are action surfaces with different contracts; selecting the tool type by integration boundary prevents unsupported automation and ambiguous execution. C is wrong because a topic can orchestrate an action, but natural language alone does not create an executable tool contract. D is wrong because Azure AI Search is a retrieval service and does not submit updates to operational systems.

Troubleshooting Practice Question: An MCP tool appears in documentation but does not appear in the agent's available tools list. What should you verify first?

A. Azure AI Search field names.
B. MCP server availability, authentication, tool discovery metadata, and schema exposure.
C. The adaptive card schema.
D. The final answer wording.

Correct Answer: B

Explanation: The missing tool list entry is an MCP discovery and auth problem. Retrieval fields, cards, and response wording do not expose server-side tools.

Exam Takeaway: For action scenarios, match the tool to the execution surface: computer use for UI, MCP for exposed tool schemas, custom connector for governed reusable APIs, REST action for direct HTTP contracts.

Best Choice Rules: If the target has no API and must be operated through a UI, choose computer use with screen checkpoints. If a server exposes callable tool schemas, choose MCP and validate tool discovery and arguments. If the API should be governed and reused in Power Platform, prefer a custom connector over ad hoc HTTP calls.

Atomic Deconstruction - Operational Level

A tool extends the agent from answering into doing. Computer use is a UI automation path, MCP exposes tool functions from a server, custom connectors package governed API operations, and REST API actions call an endpoint directly. The right choice depends on the external system surface, not on which option sounds most advanced.

Operationally, identify the external action surface first. UI-only targets need computer use checkpoints; MCP targets need tool discovery and argument schema; governed APIs need custom connector operations and connection references; direct HTTP targets need method, header, body, status, and response mapping checks.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Computer use	Automation target	UI-driven application or website	Not configured	Credentials, session, UI stability	Action fails when screen state changes or authentication expires
MCP tool	Server-exposed function	Tool name, schema, transport, auth	No server attached	MCP server availability and schema	Tool not listed or arguments rejected
Custom connector	API operation definition	OpenAPI, auth, policy, connection reference	Unpublished connector	Power Platform DLP and connection	Operation blocked or called with wrong auth
REST API action	HTTP request contract	Method, URL, headers, body, response schema	No action	Endpoint auth and network reachability	HTTP 4xx/5xx or unusable response mapping

Step-by-Step Execution Path

Identify whether the task is UI automation, tool-server invocation, governed API reuse, or one-off HTTP integration. This first split determines which runtime owns execution and authentication.
For MCP, inspect the tool schema and argument names before adding it to the agent. The agent can only call what the server exposes in its tool contract.
For custom connectors, validate the OpenAPI definition, authentication type, test operation, and DLP classification before using it in a topic.
For REST APIs, create a small request with explicit method, headers, body, and response handling. Test expected 2xx and known 4xx responses so the agent can distinguish user-fixable errors from system failures.
For computer use, record the UI path and define checkpoints after each screen transition. UI automation needs observable screen state, not only a desired business result.

Evidence note: tool checks rely on MCP tool discovery, custom connector test results, REST action response mapping, computer-use run state, and runtime transcript evidence.

Technical Chain

The agent selects a tool because the topic or orchestration layer has enough values to call it. The selected tool validates its schema, identity, endpoint, and runtime state. MCP rejects arguments that do not match its tool schema; custom connectors depend on OpenAPI operation definitions and connection references; REST APIs depend on method, headers, body, and status mapping; computer use depends on screen state and credentials. The observed failure tells which contract broke.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Verify MCP tool exposure	MCP server tool list or Copilot Studio MCP tool configuration	Expected tool name, schema, and authentication state are visible
Inspect custom connector operation	Power Apps > Custom connectors > Test operation	Operation returns expected status and schema with the configured connection
Validate REST response mapping	Copilot Studio action test or API test console	Response status, body fields, and error payload map to agent variables
Check computer-use checkpoint	Copilot Studio computer use test run	Run reaches the expected UI state and records failure at the first broken screen transition

Configure multi-agent collaboration with Foundry agents, Copilot Studio agents, Fabric data agents, and A2A protocol

Exam Radar

Core Priority: This is a delegation-architecture topic. The exam can ask when Copilot Studio should hand off to another Copilot Studio agent, a Microsoft Foundry agent, a Fabric data agent, or an A2A-compatible remote agent.

High Frequency: Expect questions about responsibility boundaries, handoff conditions, Foundry agent integration, existing Copilot Studio agents, Fabric data agents, A2A protocol, agent discovery metadata, and input/output contracts.

Confusion Alert: A multi-agent question may sound like a prompt-routing issue, but the failure is often an undefined handoff condition, missing specialist permissions, invalid A2A metadata, or a response schema the orchestrator cannot consume.

Scenario Logic: A customer support agent must delegate statistical data questions to a Fabric data agent, complex reasoning to a Foundry agent, and service workflow actions to another Copilot Studio agent. The best first move is the one that preserves identity, data boundary, execution contract, or evidence collection before optimizing the conversation wording.

Version Delta: Multi-agent scope includes Microsoft Foundry agents, existing Copilot Studio agents, Fabric data agents, and A2A protocol, so delegation contracts matter as much as single-agent topic design.

Failure Trigger: Failure appears as the local agent answering outside its boundary, delegation loops, Fabric workspace access denied, Foundry agent unavailable, invalid A2A agent card, or task response shape mismatch.

Operational Dependency: Multi-agent design succeeds when delegation has explicit responsibility boundaries, contracts, identity, and routing conditions; otherwise agents duplicate work or call the wrong specialist.

Why the Correct Answer Works: The correct option works because delegation becomes reliable only when each specialist agent has a defined responsibility, handoff condition, identity boundary, and response contract.

Practice Question: A customer support agent must delegate statistical data questions to a Fabric data agent, complex reasoning to a Foundry agent, and service workflow actions to another Copilot Studio agent. How should you design the delegation model?

A. Design a delegation model that defines each agent's responsibility, input/output contract, identity boundary, and handoff condition.
B. Merge all agent instructions into a single prompt so delegation never occurs.
C. Use A2A protocol for every integration even when both agents already support a native Copilot Studio integration.
D. Let the end user manually choose which agent should answer each step.

Correct Answer: A

Explanation: A is correct: Multi-agent design succeeds when delegation has explicit responsibility boundaries, contracts, identity, and routing conditions; otherwise agents duplicate work or call the wrong specialist. B is wrong because merging all specialist instructions removes the delegation boundary and makes data, reasoning, and action ownership ambiguous. C is wrong because A2A is valuable for compatible remote-agent exchange, but native integration may be simpler and more appropriate when supported. D is wrong because manual user choice is not a robust orchestration strategy for production multi-agent routing.

Troubleshooting Practice Question: A Copilot Studio orchestrator keeps answering sales analytics questions locally instead of delegating them to a Fabric data agent. What should you check first?

A. Whether the orchestrator has a delegation condition, Fabric data agent connection, workspace permission, and expected response contract.
B. Whether the welcome message names Fabric.
C. Whether Azure AI Search has a vector field.
D. Whether the card has an action button.

Correct Answer: A

Explanation: The failure is routing and delegation ownership. The orchestrator must have a handoff condition and a reachable Fabric data agent with permissions and a usable response contract.

Exam Takeaway: For delegation scenarios, choose the answer that defines specialist ownership, handoff condition, identity boundary, and response schema before merging prompts.

Best Choice Rules: If the stem mentions analytics over Fabric data, inspect Fabric workspace permissions and the Fabric data agent boundary. If the stem mentions remote-agent interoperability, inspect A2A metadata, endpoint trust, authentication, and task schema. If the stem mentions wrong specialist responses, fix delegation conditions and contracts before merging prompts.

Atomic Deconstruction - Operational Level

Multi-agent collaboration works only when each agent has a narrow responsibility and a clear contract. The orchestrating agent should know which requests it keeps, which requests it delegates, which values must be passed, and what response shape is expected. Fabric data agents are suited to data questions, Foundry agents to configured model-backed capabilities, and A2A to interoperable remote-agent task exchange when native integration is not the correct boundary.

Operationally, write the handoff contract before connecting agents. The orchestrator needs a clear trigger for delegation, a payload schema, an identity path, a retry or failure response, and a rule for resuming the conversation after the specialist returns a result.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Orchestrating agent	Routing responsibility	Intent, condition, skill boundary	Single-agent behavior	Delegate agent availability	Wrong agent handles request or loop occurs
Foundry agent	Reasoning or model-backed task	Connected Foundry agent	Not integrated	Foundry project, identity, model deployment	Delegation fails or returns untrusted output
Fabric data agent	Data question boundary	Semantic model or data source scope	Not connected	Fabric workspace permissions	Analytical answers are unavailable or unauthorized
A2A integration	Agent communication contract	Agent card, endpoint, auth, task exchange	No protocol configuration	Remote agent endpoint and trust	Remote agent cannot be discovered or invoked

Step-by-Step Execution Path

Write a responsibility map before configuration: which agent owns retrieval, analytics, reasoning, or action execution. This prevents duplicated tools and cyclic handoffs.
In Copilot Studio, add the existing Copilot Studio agent, Foundry agent, or Fabric data agent using the supported integration path for that agent type. Native integration should be preferred when it satisfies the contract.
For A2A scenarios, validate agent discovery metadata, endpoint trust, authentication, and task input/output schema. A2A adds inter-agent protocol behavior and should be treated as a contract, not a generic connector.
Run handoff tests with boundary questions: one that should stay local, one that should delegate, and one that should be rejected or clarified. The transcript should show the decision point.

Evidence note: collaboration checks rely on integration settings, agent availability, A2A metadata, workspace permissions, handoff transcript, and returned task schema.

Technical Chain

A user request first reaches the orchestrating agent. The orchestrator evaluates intent, confidence, required data, and specialist ownership. When a handoff condition matches, it builds a task payload and invokes the specialist agent through the supported integration or A2A contract. The specialist returns a structured result or failure state, and the orchestrator resumes the conversation. If responsibility boundaries are vague, agents can duplicate answers, route in loops, or expose data through the wrong identity path.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate agent routing	Copilot Studio test transcript for representative prompts	Expected agent receives the delegated task and local agent does not answer outside its boundary
Inspect Foundry integration	Copilot Studio > Tools or agent integration settings; Microsoft Foundry project status	Connected Foundry agent is available and authorized for the environment
Check Fabric data agent access	Fabric workspace and Copilot Studio integration settings	Workspace permissions and data agent selection match intended users
Verify A2A contract	A2A endpoint metadata and task response test	Agent card, endpoint, authentication, and task response schema are valid

Integrate agents with Azure AI Search, Foundry model catalog prompts, and Application Insights monitoring

Exam Radar

Core Priority: This topic combines Azure-backed grounding, prompt/model configuration, and telemetry evidence. The scenario often describes weak answers after release and expects the candidate to separate retrieval quality, prompt/model behavior, and runtime monitoring.

High Frequency: Expect Azure AI Search with Microsoft Foundry for generative answers, custom prompts using the Foundry model catalog, and Application Insights monitoring through traces, requests, dependencies, and exceptions where available.

Confusion Alert: An Azure integration question may blame the model, but poor answers can originate from Azure AI Search freshness, Foundry prompt variables, or missing Application Insights correlation.

Scenario Logic: An enterprise agent uses indexed engineering content, a custom prompt backed by a selected model, and telemetry to diagnose poor answer quality after release. The best first move is the one that preserves identity, data boundary, execution contract, or evidence collection before optimizing the conversation wording.

Version Delta: Azure integration scope names Azure AI Search with Microsoft Foundry, Foundry model catalog prompts, and Application Insights monitoring, which makes retrieval, model choice, and telemetry separate exam dimensions.

Failure Trigger: Failure appears as stale Azure AI Search indexer status, non-retrievable grounding fields, missing Foundry prompt variable values, unsupported model selection, or no Application Insights dependency/exception correlation.

Operational Dependency: Azure integration has three observable planes: retrieval index health, model/prompt configuration, and telemetry. Diagnosing answer quality requires evidence across all three.

Why the Correct Answer Works: The correct option works because it separates three failure planes: Azure AI Search retrieval state, Microsoft Foundry prompt/model configuration, and Application Insights telemetry.

Practice Question: An enterprise agent uses indexed engineering content, a custom prompt backed by a selected model, and telemetry to diagnose poor answer quality after release. What should you validate first?

A. Tune only the global agent description because Azure integrations are not visible after publishing.
B. Replace Azure AI Search with static FAQ text to reduce telemetry noise.
C. Validate the search index and prompt/model configuration, then monitor agent behavior through Application Insights telemetry.
D. Disable monitoring until users report exact reproduction steps.

Correct Answer: C

Explanation: A is wrong because the global agent description is only one layer and cannot prove index freshness, prompt variables, model selection, or telemetry. B is wrong because static FAQ text removes the indexed retrieval path instead of diagnosing it. C is correct: Azure integration has three observable planes: retrieval index health, model/prompt configuration, and telemetry. Diagnosing answer quality requires evidence across all three. D is wrong because waiting for user reports delays observability and loses the correlation evidence needed for production diagnosis.

Troubleshooting Practice Question: After release, answer quality drops only for questions using indexed engineering content, and Application Insights shows no dependency records for search calls. What should you inspect?

A. Only the agent greeting.
B. Search integration configuration and telemetry correlation for retrieval dependencies.
C. Power Platform Pipelines approval notes.
D. A2A agent card metadata.

Correct Answer: B

Explanation: The signal combines retrieval-specific quality drop with missing dependency telemetry. The search integration and telemetry correlation should be validated before changing unrelated deployment or multi-agent settings.

Exam Takeaway: For Azure-backed agents, separate retrieval, Foundry prompt/model configuration, and Application Insights telemetry; do not treat every production symptom as a model-tuning issue.

Best Choice Rules: If the stem mentions updated content not appearing, inspect Azure AI Search indexer history before prompt text. If the stem mentions custom prompt behavior, inspect required variables and Microsoft Foundry model selection. If the stem mentions production diagnosis, choose Application Insights evidence over anecdotal transcript review alone.

Atomic Deconstruction - Operational Level

Azure integration gives the agent external evidence and observability. Azure AI Search contributes indexed retrieval, Microsoft Foundry model catalog prompts provide model-backed prompt execution, and Application Insights gives runtime evidence. The learner must avoid treating all quality problems as prompt problems.

Operationally, troubleshoot answer quality by separating evidence layers. First inspect search index state, then prompt variables and Foundry model selection, then telemetry correlation in Application Insights. Changing prompts before checking index and telemetry evidence can hide the real failure.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Azure AI Search index	Retrieval schema	Keyword/vector/hybrid fields where configured	Index unattached	Indexer and data source	Agent grounds on stale or irrelevant content
Foundry model catalog prompt	Model and prompt configuration	Supported model deployments/catalog selections	Default model behavior	Foundry access and prompt variables	Prompt cannot run or produces unsupported response shape
Application Insights	Telemetry sink	Traces, requests, dependencies, exceptions where available	Not connected	Instrumentation configuration	Failures cannot be correlated to tool or retrieval behavior
Correlation evidence	Conversation-to-operation trace	Session, operation, timestamp, dependency call	Fragmented	Telemetry fields and timestamps	Root cause cannot be distinguished from user phrasing

Step-by-Step Execution Path

Inspect the Azure AI Search data source, index, and indexer status before changing prompts. If the index is stale or fields are not retrievable, prompt edits cannot recover missing evidence.
Review the custom prompt configuration and model selection in the Foundry-related workflow. Confirm required variables are supplied and the selected model supports the expected task.
Enable or inspect Application Insights monitoring for the agent path. Telemetry must capture enough request, dependency, trace, or exception evidence to correlate poor answers with retrieval or tool failures.
Replay one failing user question and compare retrieval evidence, prompt variables, model response, and telemetry timestamps. This sequence isolates whether the fault is data, prompt, model, or runtime dependency.

Evidence note: Azure checks rely on Azure portal index state, Microsoft Foundry prompt/model configuration, and Application Insights traces, requests, dependencies, or exceptions where available.

Technical Chain

A grounded answer begins when the agent sends the user query into the configured retrieval path. Azure AI Search returns documents according to index freshness, schema, filters, and retrievable fields. A custom prompt may then use a selected Microsoft Foundry model with variables supplied by the agent. Application Insights records runtime signals that can correlate the conversation with retrieval, dependencies, exceptions, or prompt/tool behavior. If telemetry is absent, the team cannot distinguish stale index content from prompt failure or dependency outage.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Check index freshness	Azure portal > AI Search > Indexers > execution history	Recent indexer run succeeded and document count reflects expected source updates
Inspect retrievable fields	Azure portal > AI Search > Indexes > fields	Fields needed for answer grounding are searchable/retrievable and vector fields match embedding dimensions where used
Validate prompt variables	Copilot Studio custom prompt configuration with Foundry model selection	Required inputs are populated and model selection is supported in the environment
Query telemetry evidence	Application Insights > Logs > traces, requests, dependencies, exceptions	Timestamped records correlate the conversation with retrieval, tool, or exception behavior

Shopping cart

Subtotal:

AB-620 Integrate and extend agents in Copilot Studio

Detailed list of AB-620 knowledge points