Microsoft AB-620: Topics, Actions, and Tools

AB-620 tests whether you can choose the right mechanism for an agent to understand intent, gather information, and perform work. Topics structure conversations, actions execute business operations, tools extend the agent’s capabilities, flows coordinate multi-step automation, and prompts can provide generative transformation. The exam is less interested in the labels than in whether you understand when each mechanism is appropriate.

A useful way to evaluate an agent is to trace one request from user intent to confirmed outcome. Identify where inputs are interpreted, where required data is collected, which connector or tool performs the action, how failures are retried or escalated, and what evidence shows that the result was actually committed. This method exposes gaps that are easy to miss in a happy-path demonstration, especially when an external system may accept a request without completing it immediately.

Use topics for repeatable conversational paths

A topic is a good fit when the business wants a recognizable intent to trigger a defined sequence. The sequence can ask questions, store variables, call an action, display an adaptive card, or produce a formatted response. Topics give builders more control over the shape of an interaction than relying on a fully generative path.

The control is valuable when a process has mandatory inputs or compliance steps. For example, an agent that starts a service request may need the user to provide a system name, urgency, and business impact before the workflow can continue. A topic can enforce that collection consistently.

Topic triggers should be distinct enough that similar intents do not compete unpredictably. If “reset password” and “unlock account” require different workflows, the design should collect enough context to route the request correctly. Overlapping topics create user frustration even when each individual topic is well built.

Use agent flows for multi-step operational work

Agent flows coordinate actions and connectors around inputs and outputs. They are appropriate when the solution needs deterministic sequencing, error handling, branching, or human-in-the-loop review. A flow can turn a conversational request into a controlled transaction instead of asking the model to improvise the process each time.

Think of a flow as an operational contract. The agent can collect intent and context, but the flow defines what must happen before the business task is complete. This division reduces ambiguity and makes testing easier because the team can validate each step independently.

A human-in-the-loop design step is particularly useful when the workflow reaches a policy boundary. The agent can prepare a complete request, gather evidence, and reduce administrative effort, while the authorized reviewer makes the consequential decision. That pattern preserves automation value without pretending every judgment should be delegated to AI.

Add tools when the agent needs capabilities beyond conversation

Tools let the agent retrieve information or perform actions outside its native conversational context. Microsoft’s current AB-620 blueprint includes MCP tools, custom connectors, REST APIs, computer use, and other integrations. The tool should be selected according to the system being reached and the level of control required.

Do not add a tool simply because it is available. Every tool expands the agent’s capability and therefore its risk surface. The design should justify what data the tool can read, what actions it can perform, which identity is used, and how failures are reported.

Tool descriptions matter because the orchestrator needs to understand when a capability is appropriate. Names and descriptions should make the operation and expected inputs clear. Ambiguous tool definitions can cause the agent to choose the wrong action even when the underlying integration is technically perfect.

Use custom connectors for reusable API access

A custom connector can wrap an external or internal API in a form that Power Platform and Copilot Studio can use more consistently. This is useful when an organization has a business service that is not already represented by a standard connector or when it wants a reusable abstraction over a REST interface.

Connector design should expose only the operations the agent actually needs. A broad administrative API may support dozens of endpoints, but the agent might require only two safe operations. Limiting the connector surface makes permissions, testing, and governance easier.

Call REST APIs when direct integration is appropriate

The blueprint explicitly includes adding REST APIs to an agent and using HTTP requests in advanced topics. Direct API integration can be efficient when the endpoint is well defined, authentication is understood, and the required operation does not justify a larger connector abstraction.

Builders should still treat the API as a software dependency. Handle an API as a dependency with validation, status checks, protected credentials, and timeouts. API data example uses the same request-and-response principles as AB-620 integrations even if the underlying implementation is not Python.

Use MCP when tools need a standardized model-facing interface

Model Context Protocol gives AI systems a structured way to discover and invoke tools or contextual resources exposed by a compatible server. In AB-620, the important point is architectural: MCP can reduce one-off model integration patterns and make capabilities available through a more standardized interface.

Standardization does not eliminate governance. The server still exposes operations that may have sensitive effects. Builders must understand the identity model, available tools, data returned, and boundaries around use. An MCP tool should be evaluated with the same least-privilege mindset as any other integration.

MCP can also create a cleaner separation between the agent platform and the system that owns the capability. The server can evolve its implementation while preserving a stable exposed tool contract. That separation is useful, but only if versioning and compatibility are managed deliberately.

Use computer use only when interface automation is justified

Computer use can allow an agent to interact with a graphical interface when a system lacks a suitable API or connector. That flexibility can unlock legacy workflows, but it also introduces brittleness because screen layouts, timing, and UI states can change. It should not automatically replace a stable programmatic integration.

For exam scenarios, compare the available integration paths. If a supported API exists, it is usually easier to validate and govern than simulated UI interaction. Computer use is most defensible when the business requirement depends on a system that exposes no practical machine interface.

Format responses for the next decision

The result of a tool call should be presented in a way that helps the user or the next workflow step. A raw JSON payload may be technically complete but operationally poor. Topics can format responses, adaptive cards can present structured choices, and custom prompts can transform information into a clear explanation.

Response design also affects safety. If an action is destructive or financially significant, present enough context for confirmation rather than hiding the consequence behind a friendly sentence. The interface should make the business state visible before and after the action.

Troubleshoot by isolating the failing layer

When a tool-enabled agent fails, determine whether the issue lies in topic routing, variable collection, flow logic, authentication, connector configuration, the API itself, or response formatting. Changing prompts will not repair an expired credential, and rebuilding a connector will not fix an incorrectly triggered topic.

This layered troubleshooting is central to advanced builder work across the wider Microsoft certification ecosystem. It also connects AB-620 to broader API and automation principles: isolate the interface boundary, verify inputs and outputs, and use observable evidence rather than guessing across the entire stack.

Capture a known-good example whenever possible. Comparing the failing execution with a successful one can reveal whether the difference is an input value, user identity, connector connection, topic branch, or downstream response. This evidence-driven method scales better than changing multiple configuration areas at once.

Tool selection should also account for transaction semantics. A read operation can usually be retried more safely than an update, because repeating a write may create duplicate records or repeat a business action. If an external system supports an idempotency key or unique request identifier, the integration can use it to reduce duplicate effects. Even when the exam does not ask for low-level API design, understanding that reads and writes have different failure consequences helps you choose safer automation patterns.

Topics and tools also need clear ownership. The team that maintains conversational logic may not own the downstream ERP, CRM, or service-management API. When an integration fails, the agent should expose enough operational detail for the correct support team to act without revealing technical secrets to the end user. This is another reason to separate a friendly user response from structured telemetry: each audience needs different information from the same failure.

For scenario practice, start with the required outcome and remove mechanisms that cannot accomplish it. If the agent only needs a reusable action over an existing API, a custom connector may be sufficient. If it needs model-facing standardized tools, MCP can fit. If it must coordinate a fixed approval sequence, an agent flow is stronger. If it needs to interact with a legacy screen lacking an API, computer use may be justified. The answer should follow the system constraint, not a preference for one Copilot Studio feature.

The same restraint applies to generative prompts inside a topic. Use a custom prompt when flexible language transformation adds value, but do not ask a model to calculate or validate information that a deterministic service can handle more reliably. The strongest agents combine predictable software behavior with generative reasoning only where ambiguity, language, or synthesis actually benefits from it.