Test and manage agents
Two containers carry this domain: one holds what you can prove, the other holds what you can move
An agent that answers perfectly in its maker's browser has proved nothing and gone nowhere. Closing those two gaps is what Microsoft weights at 20–25% of AB-620, and it runs on two artifacts: a test set, the named group of test cases an evaluation run — one execution of that set — works through, which is where you write down what counts as a correct answer, and a solution, the Microsoft Dataverse container that carries an agent and its components between Power Platform environments, which is the only route an agent has out of the environment it was built in. Neither container infers anything for you. A test case returns an Invalid result rather than a failure when it lacks the expected content its test method reads, and a solution transports exactly the components somebody added to it. Nearly every trap in this domain is an answer that expects the platform to close that gap by itself, such as generating test cases from a knowledge source in order to discover what the knowledge source is missing, or adding an agent to a solution and assuming the topics and flows built afterwards came along.
The domain unfolds in seven steps: three build the evidence, four build the release
Read the subtopics in order and the two containers assemble themselves. Create a test set settles the shape of the evidence, single response or conversation, and where its test cases come from. Choose an evaluation method settles the standard each case is graded against, which ranges from character-for-character matching to a language model's judgement of answer quality. Review test results turns one evaluation run's outcomes into a decision about whether to ship, and about whether a failure sits in the agent, in the test, or in the environment the run happened in. Create a solution sets up the container, together with the solution publisher whose publisher prefix is stamped into the unique name of every component created there. Add existing agents to a solution is where the container is really assembled, dependency by dependency. Create and use environment variables — Power Platform records for what differs between environments, not the agent's own conversation variables — is how one solution serves several environments, by naming the values that differ instead of hard-coding them. Implement and extend Microsoft Power Platform Pipelines turns that move into a governed deployment run, one execution of a pipeline that promotes the solution from development towards production.
When two answers both work, prefer the one that holds an artifact still
Both halves of this domain buy their credibility the same way, by keeping one thing fixed while exactly one thing changes. A test set is regression evidence only for as long as its test cases and its test methods stay the same across evaluation runs, because that is what makes a moved score attributable to the agent rather than to a reworded question. A deployment run rests on the same idea: pipelines export the solution as soon as the deployment request is submitted and then deploy that same managed artifact to each later stage in sequential order, which is what makes a signed-off test deployment mean something in production. So when two options both work, the exam usually rewards the one that preserves the reference: rerun the existing test set rather than rewriting it, keep the unmanaged solution in development as the source you edit and export, and let the per-environment value change while the environment variable's definition travels unchanged.
The two containers, step by step, and where each is covered
| Step | Container | What the platform will not fill in for you | Drill into |
|---|---|---|---|
| 1. Decide the evidence | Test set | The shape of the set, where its test cases come from, the expectation each case declares, and the identity the run executes as | Create a test set |
| 2. Decide the standard | Test set | What counts as a correct answer, and the expected content the chosen test method reads | Choose an evaluation method |
| 3. Read the evaluation run | Test set | Whether a failure belongs to the agent, to the test, or to the environment the run happened in | Review test results |
| 4. Create the container | Solution | A custom solution, and a solution publisher whose publisher prefix you fix before any components exist, because it is stamped into the unique name of every component created afterwards | Create a solution |
| 5. Fill the container | Solution | Every component the agent depends on, added explicitly as a required object before export | Add existing agents to a solution |
| 6. Name what differs | Solution | The settings that change per environment, held as a definition that travels and a value the target supplies | Create and use environment variables |
| 7. Repeat the move | Solution | The host, the ordered stages, and the approvals a governed deployment run has to pass through | Implement and extend Microsoft Power Platform Pipelines |