Multi-model agents: govern routing before delegating actions
Switching models without rebuilding an agent may ease operations. For a Belgian or French company, the decision still needs boundaries: what data does each model receive, what happens during fallback, and who authorises a business action?
1. What Microsoft announced on October 28
Microsoft announced that the Copilot harness is being made available through Microsoft Foundry. This orchestration layer supplies agents with instructions, context, an execution environment and controls. The vendor describes support for multiple model families, MCP and agent skills, alongside a downloadable SDK and cloud execution managed by Foundry. In the latter option, Microsoft says it operates the agent loop and sandbox; the customer supplies instructions, tools and model choices.
2. What changes for Belgian and French companies
The practical opportunity is to compare managed orchestration with maintaining an in-house loop. An SME should start with a bounded process, such as drafting a reply from an approved corpus, and measure the supervision workload. Mid-market companies, large enterprises and public administrations should request access conditions, regions, costs and support responsibilities for the selected service before a pilot. The announcement alone does not establish that a deployment is sovereign.
3. Underside analysis: routing becomes a governance decision
Our recommendation is to define approved models for each data class and tool. Test what happens when the intended model becomes unavailable: fallback should respect the same processing boundary or halt execution. For RAG, enforce document permissions before sending context and examine the data held in logs too. Model choice should be demonstrated on the actual workflow, including its confidentiality constraints.
4. Connecting Odoo while retaining business rules
For an Odoo Enterprise pilot in Belgium or France, separate retrieval, drafting and writes. One suggested acceptance scenario: the agent reads an order using a dedicated account, prepares a change, then waits for approval before calling the write operation. Test a cross-company access refusal, a session expiry and recovery after interruption. Check that recovery does not create two orders. This scenario is an Underside integration recommendation, rather than an Odoo feature announced by Microsoft.
5. Acceptance testing for quality and control
Build a set of representative French and English cases, with expected answers and prohibited actions. Compare models on accuracy, cost per case, latency, tool calls and required approvals. Retain configuration versions and routing decisions to reproduce incidents. Before opening access to users, require a revocation test and a procedure to stop actions while preserving useful evidence.
Operational recommendation: approve a matrix of data class, model, tool and permitted action. A fallback test, recovery without duplicates and an access refusal must pass before any business write.
Scope a governed AI project