AI enablement
Define a bounded role for AI assistance in marketing and operational workflows.
On this page
Choose a specific operational task
Start with a task whose inputs, expected outputs and failure cost can be described. Examples include summarizing a campaign brief, classifying an enquiry or finding information in approved documentation. A general assistant is not a substitute for a scoped workflow.
Ground the answer in authorized context
Limit retrieval to sources the intended user may access. Preserve document versions and useful source references. Test how the system behaves when context is missing, contradictory or outdated.
Bound tool actions
Reading a CRM record and changing a customer lifecycle stage have different consequences. Define permissions at the tool and action level, require approval for consequential changes and validate tool arguments independently of model output.
Evaluate before expanding
Build representative examples including ambiguous requests, missing data, prompt injection and sensitive content. Measure task correctness, source support and escalation behavior. Human review should be assigned to a real role.
Treat deployment as an operating responsibility
Microsoft Foundry can provide a model and agent environment, but the surrounding architecture still needs identity, network access, logging, cost controls and change management. Available models, regions and tool capabilities must be confirmed for the selected deployment.
Separate model capability from business authority
An agent tool definition tells the model which operations exist. The application and tool implementation must still enforce who may use them and which records they may access. Microsoft Foundry MCP tools can be restricted with allowed_tools and configured to emit approval requests. Route those requests to a real reviewer and bind approval to the exact arguments. Keep the application authority policy distinct from provider configuration so the same record and action boundaries remain enforceable across tools.
{
"task": "prepare_campaign_review",
"read_scope": ["approved_campaign_brief", "approved_reporting_view"],
"permitted_outputs": ["draft_summary", "proposed_follow_up"],
"review_required": ["change_crm_owner", "publish_campaign"],
"on_missing_evidence": "explain_gap",
"on_rejected_action": "stop_action"
}Evaluate the action trace as well as the answer
An answer can sound correct while using an unauthorized record or an incorrect tool argument. Review retrieval, proposed actions, approval decisions and resulting tool outcomes. Include realistic failure cases and name the evidence required to pass each one. Reevaluate when the model, instructions, knowledge or tool definitions change.
| Scenario | Expected behavior | Evidence |
|---|---|---|
| Missing source information | Explain the gap without inventing a value. | Answer and retrieved sources |
| Restricted customer record | Deny access through the application policy. | Authorization result and tool trace |
| Consequential write | Wait for the required reviewer decision. | Proposed arguments and approval reference |
| Tool timeout | Report uncertainty and inspect prior effect before retry. | Tool outcome and destination state |
Version the operating context
A release record should identify the model deployment, instructions, knowledge versions, tool catalogue and evaluation set. This makes it possible to distinguish a model behavior change from a stale document or modified tool. Keep the operational owner, escalation path and appropriate trace retention with the release. Regional availability and supported agent capabilities must be confirmed for the actual Foundry deployment.
Standards and documentation
Explore the protocol specifications and platform guidance for this topic.
Bring the contract into your operating environment.
Discuss an implementation