Begin with a bounded responsibility
A useful first assistant has a specific job. It might prepare a campaign brief from approved inputs, summarize a defined performance report or answer questions using maintained internal guidance. Write down who uses it, the information it may access and the decision it is expected to support.
Also define its limits. An assistant that prepares a draft does not automatically need permission to publish a campaign. A reporting assistant does not automatically need permission to change CRM records. Keeping the task and its authority explicit makes evaluation more meaningful and operational ownership clearer.
Prepare knowledge as an operating asset
Retrieval is useful only when the source material is appropriate and current. Identify approved documents, their owners, access rules and review dates. If two sources disagree, decide which one is authoritative or design the assistant to surface the conflict rather than silently choose a convenient answer.
The response should make its evidence inspectable when the task requires factual guidance. Source references help a user verify a recommendation, but they are not a substitute for evaluating whether the cited material actually supports it. Include incomplete and conflicting information in the evaluation set.
Treat tools as permissions to act
A tool connection gives an assistant access to a system operation. Define the narrowest useful set of operations and the data each may receive. Separate reading a contact from modifying one, and distinguish preparing a communication from sending it. Consequential actions may require a human decision before execution.
Microsoft Foundry supports tool connections such as functions, OpenAPI specifications and remote MCP servers. Its agent environment also provides identity and observability capabilities. Those features support a governed design, but the application still needs an appropriate permission model, tested tool behavior and an accountable owner.
Evaluate the difficult cases
Create representative tasks with acceptance criteria before deciding the assistant is ready. For a reporting assistant, this can include correct interpretation of the reporting period, recognition of missing data and refusal to invent a causal explanation. For a knowledge assistant, assess answer accuracy and the relevance of its evidence.
Test requests outside scope, unauthorized data requests, misleading source content and unavailable tools. Inspect the tool calls as well as the final response. A fluent answer can hide an incorrect lookup or an action that should not have been attempted. Record the failure patterns that require a change to instructions, data or permissions.
Keep approval attached to the exact proposed action
Microsoft Foundry MCP tools support an allowed_tools configuration and approval behavior. When a configured call requires approval, the response can contain an mcp_approval_request with the proposed tool and arguments. The application must preserve that response context, present the intended action to an authorized reviewer and resume using the appropriate approval response. A rejected action should remain rejected even if the assistant can reach the same operation through another tool.
The approval flow is not a replacement for authorization inside the tool. The implementation still checks the caller, record scope and permitted field changes. Bind a decision to the exact target and arguments, and require another review if those inputs change. Evaluation should cover a rejected write, unauthorized retrieval, stale source information and a timeout after a tool may already have acted. Inspecting those traces provides stronger evidence than judging only the fluency of the final answer.
Release with a review and change process
Introduce the assistant to a defined group with clear guidance about its purpose and the review expected from users. Monitor the measures relevant to the task, including response quality, tool outcomes, latency and unresolved requests. Provide a route for users to report an incorrect answer with enough context to investigate it.
Reevaluate when the model, instructions, knowledge or tools change. Keep an appropriate record of the version in use and the evidence behind a release decision. The result is an assistant that participates in an operating process with clear boundaries, rather than an unattended layer of uncertain authority.