200+ AI Agents in Production: The Six-Step Playbook for Copilot Studio

Turning a Copilot Studio prototype into a production system is rarely a matter of model capability — it's about having a repeatable engineering method. After working on 20 generative AI use cases at SUEZ and delivering more than 200 AI agents as a freelance Data & AI Tech Lead in Paris, Zakaria Khchiche distilled six key actions to take before going live: define the scope, write testable instructions, maintain a clean knowledge base, make scanned documents readable, connect to real systems, and settle security and lifecycle management with IT.

Step 1: Define the agent's boundaries before rushing to connect tools

Zakaria's advice is to start by writing down three things clearly: what role this agent plays, which users it serves, and what it must refuse. Agents with unclear boundaries look fine during demos, but once they enter real business workflows they frequently overstep their authority or answer the wrong questions.

Next, you need to choose between two orchestration approaches. Generative orchestration lets you describe the agent in natural language, give it sources, tools, and memory — fast to build, but with lower behavioral predictability. Hand-designed topics are the opposite: fixed paths, strong controllability. His practical rule is: use generative orchestration for scenarios that need exploration and flexible responses, and keep hand-designed topics for critical paths that absolutely cannot go wrong — things like compliance disclosures or amount confirmations.

The difference between generative orchestration and manual topics: In Copilot Studio, generative orchestration relies on the reasoning capabilities of a large language model to dynamically decide which plugin to invoke and how to respond based on system instructions, knowledge sources, and available tools. This makes it more natural when facing open-ended questions, but the same user input can lead down different paths. Hand-designed topics are like flowcharts: the developer presets trigger phrases, branching conditions, and response templates, so the agent must follow a predetermined path and falls back to a fallback response when out of scope. A common hybrid strategy in practice is to hand consultation, retrieval, and explanation-type needs to generative orchestration, while solidifying high-risk steps like identity verification, amount confirmation, and compliance disclosures into manual topics or controlled flows — achieving a balance between experience and controllability.

Step 2: Treat instructions as a testable contract

Many teams write instructions as a prose passage, and after editing they can only judge quality by feel. Zakaria's approach is to break instructions into five blocks: who the agent is, what it does, what it refuses, how it responds, and what it does when it doesn't know.

The key is pairing each block with a set of test questions. This way, every change to the instructions can be verified rather than guessed at. It also sets the stage for the continuous monitoring in Step 6 — the same test set serves both for regression during development and for quality inspections after launch.

Step 3: Knowledge base problems are rarely model problems

Wrong answers blamed on "the model being bad" usually trace back to the documents themselves: outdated versions, duplicate content, conflicting files. Zakaria's judgment is blunt — before tuning any parameters, make sure every document in SharePoint or your file sources has only one up-to-date version.

This point is often underestimated in real projects. When the knowledge base is messy, retrieval pulls in both old and new versions, and the model can only "pick one" from contradictory information, so output stability becomes impossible. Governing the knowledge base like a database is more effective than swapping models.

Step 4: Make scanned documents readable by the model

To an agent, a PDF containing only images is a blank page — and contracts and technical specifications are often exactly that format. Zakaria's advice is to add OCR and controlled preprocessing before indexing.

This step isn't a huge engineering effort, but skipping it is costly: the agent either can't retrieve these documents at all, or gives misleading answers based on incomplete text — and the latter is harder to detect.

The relationship between indexing and OCR: Agent knowledge retrieval typically relies on vector indexes or keyword indexes, and the quality of the indexed text directly determines recall results. Scanned PDFs contain only page images with no extractable text layer; if they go straight into the index, the system only gets blank or garbled content. OCR (Optical Character Recognition) converts images into text, while controlled preprocessing includes deskewing, denoising, column detection, table reconstruction, and cleaning up page numbers and headers/footers. The key word is "controlled" — OCR results must be validated by a person or by rules, especially fields like amounts, dates, and clause numbers. Otherwise errors flow into the knowledge base as seemingly normal text, which is more dangerous than failing to retrieve anything at all.

Step 5: Upgrade from "explaining how to do it" to "doing it for you"

An agent that tells you how to issue an invoice is helpful; an agent that actually issues the invoice is what truly changes how people work. This step requires connectors, APIs, MCP servers, and agent flows.

Zakaria offers a clear division of labor: the model handles reasoning, the flow handles execution. Any action that must be guaranteed — writing to a system, submitting a request, triggering an approval — should be delegated to a flow, not left to the model to perform reliably every time.

The roles of MCP and agent flows: MCP (Model Context Protocol) is a protocol that lets models access external tools and data sources in a standardized way. It describes each tool's capabilities, parameters, and return structures clearly, and the model uses this to decide when to invoke them. Agent flows, on the other hand, are deterministic automation workflows in Copilot Studio, similar to orchestration logic with branching, loops, and error handling, capable of calling connectors and APIs to perform actual write operations. The two are often used together: MCP lets the agent "see" what capabilities are available, while agent flows handle actual execution and ensure idempotency, retries, and auditing. Any action involving funds, approvals, or data writes should be encapsulated in a flow, with permission checks and logging done at the flow layer, rather than letting the model directly assemble requests.

Step 6: Security and engineering must be settled with IT

The final step is reaching agreement with IT and security teams on four things: access permissions, traceability, environment separation, and ALM (development, testing, production). Going live isn't the finish line — every subsequent change to instructions or the knowledge base must be re-checked against the test set established in Step 2.

This method doesn't guarantee no mistakes — it guarantees mistakes are visible

Zakaria explicitly states that the six-step method won't make an agent mistake-free; its value lies in making failures visible and fixable. He also points out the tool boundary: when fine-grained model selection or large-scale cost control is needed, Azure AI Foundry is often more suitable than Copilot Studio, and in large enterprises the two frequently coexist.

This judgment is valuable for companies currently choosing their stack — Copilot Studio is suited for quickly pushing business agents into production, while as governance complexity and cost pressure rise, bringing in Foundry as underlying support is the more realistic path.

One-line Summary

A six-step engineering method for putting Copilot Studio agents into production: from boundaries, instructions, and knowledge bases to execution, security, and tool selection.

Paragraph Summary

Based on Zakaria Khchiche's experience delivering over 200 AI agents at SUEZ, the article summarizes six key actions for turning Copilot Studio prototypes into production systems: first define the agent's role, users, and refusal boundaries, and divide labor between generative orchestration and manual topics by scenario; break instructions into five testable blocks, each with test questions; knowledge base errors mostly stem from messy document versions and must be governed to database standards; scanned documents must go through OCR and controlled preprocessing to be retrievable; use connectors, APIs, MCP, and agent flows to let the agent truly execute actions, adhering to model reasoning and flow execution; finally, settle permissions, traceability, environment separation, and ALM with IT. The author emphasizes this method doesn't guarantee no mistakes — only that mistakes are visible and fixable — and notes that Copilot Studio suits rapid production deployment, while Azure AI Foundry is more appropriate for complex governance.