Article 32/50 — Microsoft Foundry Agents and Copilot Studio

Understanding Agent Integration, Orchestration, Runtime Boundaries, and Enterprise Architecture Across Microsoft AI Platforms

Microsoft Copilot Studio & Enterprise AI Agents — A Technical Learning Journey

1. Introduction

Enterprise AI development is moving beyond isolated chatbots and simple question-answering experiences.

Organizations increasingly need AI systems that can retrieve corporate information, interpret complex requests, invoke business operations, interact with specialized services, and participate in larger workflows.

Microsoft provides multiple technologies for building these solutions, including Microsoft 365 Copilot, Microsoft Copilot Studio, Microsoft Foundry, Azure AI Search, Microsoft Graph, and the Power Platform.

Two particularly important platforms are Microsoft Copilot Studio and Microsoft Foundry.

Both can be used to build AI agents. Both support instructions, knowledge integration, tools, and enterprise security capabilities. However, they address different development requirements and offer different levels of control.

Copilot Studio emphasizes enterprise agent authoring, managed orchestration, business integrations, and conversational experiences.

Microsoft Foundry provides a broader AI engineering platform, including model selection, agent runtimes, code-based development, evaluation, observability, and deployment.

Understanding their differences is essential when designing enterprise AI architectures.

This article explores how these platforms relate, how their agents can interact, and when combining them provides architectural value.

2. What Is Microsoft Foundry?

Microsoft Foundry is Microsoft’s Azure platform for building and operating AI applications and agents.

It brings together capabilities for working with AI models, developing agents, connecting tools, evaluating behavior, and managing AI workloads.

Rather than treating an AI agent as a simple prompt attached to a language model, Foundry supports a broader engineering lifecycle.

This includes:

• Selecting and deploying supported AI models.
• Configuring or programming agent behavior.
• Connecting agents to external tools and data.
• Executing agents through managed runtimes.
• Evaluating answer quality and agent behavior.
• Monitoring execution and troubleshooting failures.
• Managing identities, permissions, and deployment configurations.

A useful architectural distinction is that Foundry is not itself a language model.

It is a platform through which developers can use models and build applications around them.

Similarly, Microsoft Foundry Agent Service is not synonymous with the entire Foundry platform. It is the managed agent development and runtime capability within that ecosystem.

3. Understanding Models, Applications, and Agents

Before comparing platforms, we need to separate three concepts.

AI Model

An AI model processes inputs and generates outputs.

For example, a language model can summarize a SharePoint policy document if the document content is supplied as context.

However, the model does not automatically know which SharePoint site to access or which documents a user is authorized to read.

AI Application

An AI application provides a software experience around one or more models.

It may manage authentication, user interfaces, conversation history, document retrieval, and API calls.

AI Agent

An AI agent combines model-based reasoning with instructions and potentially tools, knowledge retrieval, state management, and orchestration.

An agent may determine which available capability is appropriate for a request and use it to complete a task.

Consider an employee asking:

“Find our remote-work policy, summarize the approval requirements, and submit a request for my manager.”

A model can summarize text.

An application can provide the user interface.

An agent may coordinate the sequence of retrieving the policy, explaining its requirements, collecting information, and invoking an authorized submission operation.

These responsibilities are related, but they are not interchangeable.

4. What Is Microsoft Foundry Agent Service?

Microsoft Foundry Agent Service provides managed infrastructure for building, deploying, and operating AI agents.

It supports different development approaches, from configuration-driven agents to code-based implementations.

Its responsibilities can include managing agent execution, conversations, tool invocations, endpoints, identity, scaling, and observability.

The important architectural benefit is that developers do not necessarily need to implement every operational component of an agent platform themselves.

However, using a managed runtime does not eliminate responsibility for business logic, access control, data protection, evaluation, or governance.

Those remain essential application and architecture concerns.

5. Agent Development Approaches in Foundry

Microsoft Foundry supports several approaches to agent development.

Availability and capabilities can vary by region, model, deployment configuration, and release status.

Prompt Agents

A Prompt Agent is an excellent starting point for developers learning Foundry.

Its behavior is primarily defined through configuration rather than custom orchestration code.

For example, we could create an agent with these instructions:

You are a technical documentation assistant. Answer questions using the approved documentation available through your configured tools. Clearly distinguish documented information from recommendations. If the available evidence is insufficient, explain the limitation instead of inventing an answer.

We could then attach supported retrieval tools.

Foundry manages the agent execution, while the developer remains responsible for selecting appropriate knowledge sources and testing the resulting behavior.

Hosted Agents

Hosted Agents provide greater control.

Developers can implement agent behavior using supported frameworks or custom code, package the application, and deploy it to the managed runtime.

This is particularly relevant when an organization requires custom orchestration, specialized dependencies, application-specific state handling, or integration protocols that are difficult to express through configuration alone.

For experienced C#, Python, and TypeScript developers, Hosted Agents represent an important extension of traditional application engineering into AI systems.

6. Microsoft Foundry vs. Microsoft Copilot Studio

The two platforms overlap, but their primary engineering experiences differ.

These differences should not be interpreted as absolute technical restrictions.

Copilot Studio can support sophisticated integrations, while Foundry can support relatively simple declarative agents.

The correct choice depends on the actual requirements rather than the perceived complexity of the technology.

7. Why Microsoft Offers Both Platforms

Enterprise AI development has multiple audiences.

A business application team may need an agent that answers questions about internal procedures and creates SharePoint list items.

A software engineering team may need a custom agent that executes specialized algorithms, coordinates external services, and operates within a bespoke application.

Both teams are building AI agents, but their engineering requirements differ.

Copilot Studio reduces the amount of custom infrastructure needed for common enterprise scenarios.

Foundry offers more direct access to AI engineering capabilities, model services, custom runtimes, and operational tooling.

An important architectural principle follows:

Greater control is valuable only when the solution requires it.

A simple SharePoint knowledge assistant should not automatically become a custom Azure application merely because Foundry is available.

8. The Enterprise Agent Architecture

Consider an organization building an internal technical support assistant.

Employees interact with the assistant through a corporate conversational experience.

The assistant must answer general questions about company policies, but it also needs to perform specialized technical analysis.

A possible architecture is:

Employee
   |
   v
Microsoft Copilot Studio Agent
   |
   +-- Enterprise Knowledge
   |      |
   |      +-- SharePoint Online
   |
   +-- Business Operations
   |      |
   |      +-- Power Automate
   |      +-- Approved Connectors
   |
   +-- Specialized AI Capability
          |
          v
     Microsoft Foundry Agent
          |
          +-- AI Model
          +-- Instructions
          +-- Retrieval Tools
          +-- Custom APIs
          +-- Evaluation and Tracing

In this design, Copilot Studio acts as the primary user-facing agent.

Foundry provides a specialized capability that can be invoked when appropriate.

This is an architectural example, not a mandatory Microsoft reference architecture.

9. Understanding the Orchestration Boundary

One of the most important considerations in a multi-platform architecture is deciding which component controls the workflow.

Suppose an employee asks:

“Analyze this technical incident and recommend the appropriate remediation.”

The Copilot Studio agent might recognize that the request requires specialized technical analysis.

It could invoke a connected Foundry agent.

The Foundry agent could then perform its own reasoning, retrieve relevant information through authorized tools, and return a result.

Copilot Studio would receive that result and incorporate it into the user-facing response.

The execution can be understood as:

1. The user submits a request to Copilot Studio.
2. Copilot Studio determines whether the specialized agent is appropriate.
3. The configured connection invokes the Foundry agent.
4. Foundry executes the delegated task using its configured runtime and capabilities.
5. The result returns to Copilot Studio.
6. Copilot Studio presents the response to the user.

The exact communication behavior depends on the supported integration mechanism.

This illustrates a key concept: the parent agent and the specialized agent can have separate orchestration responsibilities.

The parent does not necessarily control every internal decision made by the delegated agent.

10. Connected Agents and Cross-Platform Integration

Copilot Studio supports connecting external agents, including Microsoft Foundry agents, through documented integration experiences.

This allows an agent built in Foundry to become a reusable capability within a Copilot Studio solution.

Conceptually, the Foundry agent acts as a specialized service.

The Copilot Studio agent does not need to reproduce its internal implementation.

Instead, it needs sufficient information to understand what the connected agent does and when to invoke it.

For example:

Connected Agent Name: Technical Architecture Reviewer

Description:

Reviews proposed Microsoft 365 and Azure integration architectures, identifies technical dependencies, analyzes security implications, and returns structured recommendations. Use this agent when the user requests a technical architecture assessment rather than general product information.

A clear description is important because agent selection may depend on capability metadata.

Poorly defined descriptions can cause incorrect routing or unnecessary delegation.

11. Integration Is Not the Same as Shared Runtime

Connecting two agents does not merge them into a single runtime.

A Copilot Studio agent and a Foundry agent may have different:

• Configuration and deployment lifecycles.
• Runtime execution environments.
• Authentication requirements.
• Tool connections.
• Logging and monitoring systems.
• Cost structures.
• Security boundaries.

This distinction matters when troubleshooting.

If a delegated request fails, the failure might originate from the parent agent, the connection, the target agent, an external tool, or the underlying data source.

A reliable enterprise architecture must make these boundaries observable.

12. Authentication and Identity

Identity must be designed explicitly.

A connection between Copilot Studio and Foundry does not automatically grant the Foundry agent unrestricted access to Microsoft 365 data.

There are several distinct security questions:

Who is the end user?

The employee interacting with the Copilot Studio agent.

Who authenticates the connection?

The identity or connection mechanism configured for invoking the Foundry agent.

Who executes downstream operations?

The identity used by the Foundry agent or its connected tool when calling a downstream service.

Whose permissions govern the data?

That depends on the supported authentication flow and the downstream service’s authorization model.

Possible patterns include delegated user authorization, managed identities, and service-to-service authentication.

These patterns have different security implications.

A service identity with broad access must not be assumed to enforce each end user’s SharePoint permissions automatically.

13. Microsoft Entra ID and Least Privilege

Microsoft Entra ID is central to securing enterprise integrations.

Architects should apply the principle of least privilege to every identity involved.

For example, if a specialized agent only needs to read documents from a particular SharePoint site, granting organization-wide administrative access would be inappropriate.

Where supported, use narrowly scoped permissions and explicit authorization checks.

Also distinguish between:

• Authentication: establishing the caller’s identity.
• Authorization: deciding what that identity may access.
• Delegation: performing an operation in the context of a user.
• Application permissions: performing an operation through an application identity.

These distinctions become especially important when an agent invokes tools that read confidential information or modify business records.

14. Knowledge, Retrieval, and Grounding

Knowledge integration is another area where the platforms must be evaluated carefully.

In an enterprise environment, the underlying information may live in SharePoint Online, Dataverse, SQL databases, Azure Storage, or external services.

An agent needs a mechanism for retrieving relevant information.

That mechanism may involve direct retrieval, indexed search, or other supported approaches.

The resulting content becomes context for the model.

This process is commonly described through three related concepts:

Knowledge Source: The repository or system containing relevant information.

Retrieval: The process of finding and obtaining relevant content.

Grounding: Using retrieved evidence to inform and constrain the generated response.

These concepts are not interchangeable.

A SharePoint site is a source of knowledge.

A search mechanism retrieves documents or passages.

The model uses those passages as grounding context.

A successful connection to a knowledge source does not guarantee accurate retrieval, appropriate permissions, or faithful answers.

Each concern must be tested separately.

15. SharePoint Online Integration

SharePoint Online is a particularly important enterprise knowledge platform.

Organizations often store policies, operating procedures, technical documentation, contracts, and training materials in SharePoint document libraries.

For a straightforward SharePoint knowledge assistant, native Copilot Studio capabilities may be the simplest approach.

However, Foundry becomes interesting when additional requirements arise.

Examples include:

• Combining SharePoint content with specialized external data.
• Applying custom retrieval or ranking logic.
• Building a reusable AI service consumed by multiple applications.
• Implementing specialized processing before generating a response.
• Developing custom evaluation pipelines.
• Integrating a code-based agent with enterprise applications.

The important decision is not whether Foundry can be used.

It is whether Foundry adds capabilities that justify the additional architectural and operational complexity.

16. Indexed Retrieval vs. Real-Time Retrieval

Not all knowledge access works the same way.

Indexed Retrieval

Documents are processed into a searchable representation.

A retrieval system identifies relevant content from the index.

This approach can support semantic and hybrid search, but index freshness and synchronization become architectural concerns.

Real-Time Retrieval

An agent or tool queries the source system during execution.

This can provide access to current information, but introduces dependencies on API availability, response time, authentication, and downstream throttling.

Neither approach is universally superior.

The decision depends on freshness requirements, security behavior, data volume, latency, and the capabilities of the selected connector or retrieval system.

For SharePoint Online, architects must also verify whether the chosen integration preserves user-level access restrictions.

17. Azure AI Search and Foundry

Azure AI Search can be an important component in Foundry-based knowledge architectures.

It provides search and retrieval capabilities that can be used in retrieval-augmented generation solutions.

A simplified architecture is:

Corporate Documents
        |
        v
Document Processing
        |
        v
Azure AI Search Index
        |
        v
Retrieval
        |
        v
Foundry Agent
        |
        v
Grounded Response

This architecture gives developers greater control over indexing, retrieval strategies, and search configuration.

However, building a custom index also creates responsibilities.

These include content synchronization, document lifecycle management, access control, data retention, and operational monitoring.

An Azure AI Search index is not automatically equivalent to SharePoint’s native permission enforcement.

Security trimming must be explicitly designed and validated for the selected architecture.

18. Tools and Actions

Knowledge allows an agent to answer questions.

Tools allow an agent to interact with external capabilities.

For example, a knowledge assistant might answer:

“What is the process for requesting a new project workspace?”

An agent with an authorized tool might go further:

“Create a workspace request for the Finance department.”

The second request involves an operation.

A Foundry agent may use supported tools to call APIs, functions, MCP servers, or other services.

The tool implementation is responsible for executing the operation.

The language model does not independently acquire permission to modify enterprise systems.

This distinction is essential for secure agent design.

19. Model Context Protocol (MCP)

Model Context Protocol, commonly called MCP, provides a standardized approach for exposing tools and related capabilities to AI applications.

In a Foundry architecture, MCP can help make external services available to agents through a consistent integration interface.

For example, an organization could expose an approved internal service through an MCP server.

The service might provide operations such as:

get_project_status
get_technical_documentation
validate_workspace_request
submit_workspace_request

Each operation should have a clearly defined purpose, input contract, output contract, and authorization policy.

MCP standardizes aspects of tool interaction.

It does not eliminate the need to secure the underlying service.

20. When Custom Code Becomes Necessary

Not every agent needs custom code.

However, code-based development becomes valuable when the solution requires specialized behavior.

Examples include complex validation, deterministic calculations, custom orchestration, integration with legacy services, or application-specific business rules.

Suppose a technical agent must analyze a SharePoint migration plan.

It may need to:

1. Retrieve migration metadata.
2. Validate site and library structures.
3. Apply deterministic business rules.
4. Estimate technical risks.
5. Generate recommendations.

Some of these operations should be implemented as ordinary software functions rather than left to probabilistic model reasoning.

A good architecture combines deterministic code with AI where each is most appropriate.

21. The Role of Deterministic Software

Generative AI is useful for interpreting language, synthesizing information, and producing explanations.

Traditional software remains preferable for operations requiring exact and reproducible results.

For example, calculating a storage total, validating a permission identifier, or determining whether a SharePoint list item meets a fixed condition should generally use deterministic logic.

An agent can decide when to invoke such logic, but it should not replace reliable calculations with unsupported guesses.

This leads to a practical design rule:

Use AI for interpretation and reasoning; use deterministic software for operations that require exactness.

22. Designing a Specialized Foundry Agent

Consider a specialized agent called SharePoint Architecture Analyzer.

Its responsibility is to review proposed SharePoint Online solutions.

The agent receives structured information about a solution and produces an architectural assessment.

Its scope might include:

• Information architecture.
• Permissions and access patterns.
• List and library design.
• Integration dependencies.
• Automation requirements.
• Maintainability and governance.

It should not directly modify the SharePoint tenant.

Its initial responsibility is analysis only.

This is an example of an atomic agent: a narrowly defined capability with a clear purpose.

23. Example Instructions

A simplified instruction set could be:

You are SharePoint Architecture Analyzer.
Your purpose is to review proposed SharePoint Online
solution architectures.
Evaluate:
- Information architecture
- Security and permissions
- Integration dependencies
- Maintainability
- Governance
- Operational risks
Distinguish documented platform behavior from
architectural recommendations.
Do not claim to have inspected a tenant unless an
authorized tool has actually provided tenant data.
Do not execute modifications.
If important information is missing, identify
the missing information explicitly.
Return:
1. Architecture summary
2. Key findings
3. Risks
4. Recommendations
5. Required validations

These instructions define the agent’s behavior, but they do not themselves provide access to tenant information.

Actual access requires appropriately configured tools and identities.

24. Reusing the Foundry Agent in Copilot Studio

After building and testing the specialized Foundry agent, an organization may expose it to a Copilot Studio agent through a supported connected-agent integration.

The Copilot Studio agent could handle general user interaction and delegate architecture reviews to the specialized service.

For example:

User: “Review this proposed SharePoint migration architecture.”

Copilot Studio Agent: Identifies the specialized review capability.

Foundry Agent: Evaluates the supplied architecture and available evidence.

Copilot Studio Agent: Returns the review in the conversational experience.

The benefit is separation of responsibilities.

The specialized agent can evolve independently, subject to the compatibility and governance requirements of the integration.

25. Integration Prerequisites and Version Compatibility

Cross-platform integration requires careful attention to documentation.

Microsoft’s integration capabilities evolve, and different Copilot Studio experiences may have different configuration steps or supported protocols.

Depending on the documented integration path, configuration may involve:

• A supported Foundry project and agent.
• The Foundry project endpoint.
• The target agent identifier.
• An authenticated connection.
• Appropriate agent-sharing and invocation permissions.
• Supported communication protocols and endpoint configuration.

Some integration paths are documented as preview features.

For example, Microsoft’s standard-harness preview documentation describes an Activity protocol endpoint prerequisite that may require programmatic enablement.

This requirement should not be generalized to every Copilot Studio integration experience.

Architects must verify the documentation for the exact experience being deployed.

26. Agent-to-Agent Communication

Agent-to-agent communication introduces new design questions.

How does the calling agent describe the delegated task?

What context is passed to the receiving agent?

What format should the response use?

How are failures communicated?

What happens if the receiving agent cannot complete the request?

These questions should be answered before implementation.

A robust integration contract should define the delegated capability, required inputs, expected outputs, failure behavior, and authorization requirements.

Even when a platform manages the communication protocol, the business contract remains an architectural responsibility.

27. Structured Outputs

For specialized enterprise agents, structured outputs can improve reliability.

Consider a Foundry agent returning an architecture review.

A conceptual response contract might look like:

{
  "architecture": "SharePoint migration",
  "riskLevel": "Medium",
  "findings": [
    {
      "category": "Security",
      "severity": "High",
      "description": "Permission model requires review"
    }
  ],
  "recommendations": [
    "Validate site-level access boundaries",
    "Document application permissions"
  ],
  "requiresHumanReview": true
}

This example illustrates a desired application contract, not a guarantee that every connected-agent integration returns this exact JSON structure.

Where machine-readable outputs are required, architects should use supported structured-output mechanisms or explicit validation at the integration boundary.

28. Observability and Troubleshooting

Observability becomes more important as an architecture includes additional agents.

A simple interaction may involve:

User Request
    |
    v
Copilot Studio
    |
    v
Connected Agent Invocation
    |
    v
Foundry Agent
    |
    v
External Tool
    |
    v
Enterprise Data Source

A failure can occur at any stage.

Useful operational information includes:

• Request and correlation identifiers.
• Agent invocation timestamps.
• Selected tools.
• Execution duration.
• Tool failures.
• Authentication and authorization errors.
• Model and token usage where available.
• Evaluation results.

Sensitive prompts, retrieved content, and tool outputs should not be logged indiscriminately.

Logging policies must account for confidentiality, retention, and regulatory requirements.

29. Evaluation and Quality Assurance

An agent that responds successfully is not necessarily an agent that responds correctly.

Enterprise AI systems require systematic evaluation.

Relevant dimensions include:

Foundry provides evaluation and tracing capabilities that can support this process.

However, technical evaluation should be combined with business-specific acceptance criteria.

For a SharePoint architecture review agent, the test set should include valid designs, incomplete designs, security risks, and requests that fall outside the agent’s scope.

30. Human Oversight

Some agent operations should require human approval.

For example, an agent may recommend changing a SharePoint permission model.

That recommendation should not automatically result in production permission changes.

A safer workflow is:

Agent Analysis
      |
      v
Recommendation
      |
      v
Human Review
      |
      v
Approved Operation
      |
      v
Execution
      |
      v
Audit Record

This pattern is especially important for security-sensitive and irreversible operations.

Approval should be enforced by the workflow or application architecture, not merely requested through conversational instructions.

31. Security Boundaries Between Platforms

A multi-agent system introduces multiple trust boundaries.

The parent agent may receive confidential user information.

The connected agent may process part of that information.

A tool may then transmit data to another system.

Each boundary requires a clear data-handling policy.

Architects should determine:

• Which data is transferred between agents.
• Whether the receiving service is authorized to process it.
• Which identities are used.
• Whether user permissions are preserved.
• Where information is stored or logged.
• Whether external tools introduce additional data processors.
• How retention and deletion requirements are satisfied.

A secure architecture cannot rely exclusively on prompt instructions.

Security must also be enforced through identities, permissions, network controls, service configuration, and application logic.

32. Prompt Injection and Untrusted Content

Knowledge sources and tool responses may contain untrusted text.

For example, a document retrieved from SharePoint could contain instructions that attempt to redirect the agent’s behavior.

The agent must treat retrieved content as evidence or task data, not as a higher-priority authority.

Architectural mitigations include minimizing tool privileges, validating tool inputs, constraining sensitive operations, evaluating adversarial scenarios, and requiring human approval for high-impact actions.

No single prompt can guarantee immunity to prompt injection.

Defense in depth is necessary.

33. Performance and Latency

Delegating requests between agents adds processing steps.

A user request may require multiple model calls, network requests, and tool executions.

This can increase latency.

Architects should consider whether delegation is actually necessary.

For example, a simple policy question should not require a complex specialized Foundry agent if the Copilot Studio agent can answer it directly from an authorized knowledge source.

Performance optimization begins with simplifying the architecture.

Only introduce additional agent layers when they deliver meaningful functional value.

34. Cost Considerations

A combined Copilot Studio and Foundry architecture may involve multiple billing components.

Depending on the implementation, these can include:

• Copilot Studio consumption or applicable licensing.
• Foundry model inference.
• Agent tool usage.
• Hosted Agent compute.
• Azure AI Search.
• Azure Functions or other integration services.
• Monitoring and data storage.

Costs depend on the exact services, regions, models, configurations, and usage patterns.

A multi-agent architecture may consume more resources than a single-agent solution.

Therefore, cost estimation should consider complete end-to-end execution rather than only the price of an individual model request.

Current pricing and licensing must be validated against official Microsoft documentation before production decisions.

35. Governance and Lifecycle Management

Enterprise agents require lifecycle management.

A useful governance model includes:

Development: Build and configure the agent.

Testing: Validate instructions, retrieval, tools, security, and expected behavior.

Approval: Review the solution before publication.

Deployment: Promote approved configurations to the intended environment.

Monitoring: Track quality, reliability, cost, and security events.

Maintenance: Update models, tools, knowledge integrations, and dependencies.

Retirement: Disable unused capabilities and remove unnecessary permissions.

When Copilot Studio and Foundry are combined, these activities must account for both platforms.

Independent deployments can create compatibility risks if one agent changes its interface without coordinating with its consumers.

36. Architecture Decision Guide

When should an organization use Copilot Studio, Foundry, or both?

These are architectural recommendations, not mandatory platform restrictions.

The best solution is the simplest one that satisfies the requirements for functionality, security, reliability, maintainability, and cost.

37. When Not to Use Foundry

Foundry should not be introduced simply because a solution involves generative AI.

It may be unnecessary when:

• Native Copilot Studio knowledge capabilities meet the requirements.
• A standard connector already provides the necessary operation.
• Power Automate can implement the workflow deterministically.
• A SharePoint feature already solves the business problem.
• The organization does not need custom model selection or orchestration.
• Additional Azure infrastructure would create unjustified operational overhead.

Choosing not to use Foundry can be the correct architectural decision.

38. When Not to Use Copilot Studio

Copilot Studio is not always the appropriate application layer.

A custom application may be preferable when:

• The user experience is not conversational.
• The application requires specialized interaction patterns.
• The organization needs complete control over application behavior.
• The AI capability is embedded in an existing software product.
• The solution requires a custom runtime or protocol.
• The application already has a well-defined backend architecture.

For example, a custom SPFx application may call an appropriately secured backend AI service without requiring Copilot Studio as an intermediary.

The decision should follow application requirements.

39. A Practical Enterprise Example

Imagine a company with thousands of SharePoint sites.

Its IT department wants an assistant that can help architects evaluate proposed site structures.

The requirements are:

1. Employees should interact through a familiar conversational interface.
2. The system should answer general governance questions.
3. Complex architecture reviews should use specialized evaluation logic.
4. No production changes should occur automatically.
5. Reviews should be traceable.
6. Access to confidential documentation must be controlled.

A possible solution uses Copilot Studio for general interaction and a specialized Foundry agent for architecture assessment.

The Foundry agent could invoke deterministic validation services and retrieve approved reference material.

The parent agent would present the resulting recommendations.

This architecture separates general interaction from specialized analysis without giving the analysis component unnecessary modification privileges.

40. Example Execution Walkthrough

A user asks:

“Our Finance department wants to replace a single SharePoint site with 40 departmental sites. Evaluate the architectural implications.”

The Copilot Studio agent identifies the request as an architecture assessment.

It delegates the relevant task to the specialized Foundry agent.

The Foundry agent evaluates the supplied proposal against available reference information and configured rules.

It may identify considerations involving navigation, governance, permissions, lifecycle management, search, ownership, and operational overhead.

The response returns to Copilot Studio.

The user receives an architectural assessment with findings, assumptions, and recommendations.

Importantly, the agent should not claim that the proposed structure is wrong without sufficient supporting context.

The appropriate architecture depends on business ownership, information boundaries, access requirements, and organizational governance.

41. Suggested First Laboratory

A practical learning journey should begin with a narrowly scoped agent.

Laboratory: Foundry Technical Documentation Reviewer

Objective: Create a Prompt Agent that reviews a short technical architecture description.

Initial scope:

• No SharePoint connection.
• No external API.
• No modification tools.
• No production data.
• No cross-platform integration.

The agent receives a proposed architecture and identifies assumptions, missing information, risks, and recommendations.

This establishes the fundamentals of Foundry without introducing unnecessary dependencies.

42. Laboratory Configuration

A minimal configuration requires:

Model: A supported model available in the selected Foundry project.

Instructions: Define the reviewer’s responsibilities and boundaries.

Tools: None initially.

Input: A short architecture proposal supplied manually.

Expected Output: A structured technical review.

Example test input:

We plan to store 200,000 business records in a SharePoint list and expose them through a custom SPFx application. Users will have different permissions based on their department. Evaluate the design.

The expected response should discuss list scale, query and indexing strategy, authorization design, operational requirements, and missing information.

It should not automatically reject the solution solely because the list contains 200,000 items.

The assessment must distinguish total list capacity from query, view, and access-pattern considerations.

43. Testing the First Agent

The first tests should focus on behavior rather than integration.

Test A — Valid Architecture Request

Does the agent produce a useful structured review?

Test B — Missing Information

Does it identify missing requirements rather than inventing details?

Test C — Unsupported Claim

Does it avoid claiming to have inspected a real SharePoint tenant?

Test D — Unauthorized Operation

If asked to change permissions, does it remain within its analysis-only scope?

After these tests succeed, knowledge retrieval can be introduced as a separate enhancement.

44. Evolving the Laboratory

The agent can evolve incrementally.

Stage 1: Prompt Agent with Instructions only.

Stage 2: Add an approved knowledge source or retrieval tool.

Stage 3: Evaluate grounded responses.

Stage 4: Add a read-only technical validation tool.

Stage 5: Test identity and authorization behavior.

Stage 6: Integrate the Foundry agent with Copilot Studio through a supported mechanism.

Stage 7: Add monitoring, evaluations, and deployment controls.

Each stage introduces one new architectural concern.

This approach makes failures easier to diagnose and helps establish a clear understanding of each platform capability.

45. Production Readiness Checklist

Before deploying a combined Copilot Studio and Foundry solution, confirm:

• The business requirement justifies the architecture.
• Agent responsibilities are clearly separated.
• The integration mechanism is supported for the target environment.
• Authentication and authorization are documented.
• Data transferred between agents is appropriately controlled.
• Tool permissions follow least privilege.
• Sensitive operations require suitable approval controls.
• Retrieval respects the intended access model.
• Failure handling and timeouts are defined.
• Tracing and monitoring are configured.
• Evaluation scenarios cover normal and adversarial requests.
• Costs and capacity are understood.
• Deployment and rollback procedures exist.
• Ownership and support responsibilities are assigned.

A technically successful demonstration is only the beginning of production readiness.

46. Common Architectural Mistakes

Several mistakes frequently appear in enterprise AI designs.

Mistake 1: Assuming all agents share the same security context.

Different runtimes and tool connections can use different identities.

Mistake 2: Treating a connected agent as an ordinary function.

A specialized agent may perform its own reasoning and tool selection.

Mistake 3: Introducing multiple agents without a clear need.

Additional agents increase complexity, latency, and troubleshooting requirements.

Mistake 4: Confusing Knowledge with Actions.

Retrieving information and modifying enterprise systems require different controls.

Mistake 5: Assuming instructions enforce security.

Prompts guide behavior but do not replace authorization.

Mistake 6: Ignoring operational boundaries.

Every platform and integration component needs monitoring, ownership, and lifecycle management.

47. Key Architectural Principles

The following principles provide a practical foundation for enterprise Foundry adoption.

First, start with a clear business capability rather than a platform feature.

Second, use the simplest development approach that satisfies the requirements.

Third, keep specialized agents narrowly scoped.

Fourth, treat cross-agent communication as an explicit integration contract.

Fifth, design identity and authorization before connecting enterprise data.

Sixth, separate probabilistic reasoning from deterministic business operations.

Seventh, test retrieval quality, tool behavior, and security independently.

Finally, treat observability, evaluation, and governance as core architecture requirements rather than optional production enhancements.

48. Technical Summary

49. Learning Journey — Where We Are and What’s Next

This article is part of the Microsoft Copilot Studio & Enterprise AI Agents — 50 Technical Articles series.

Our recent articles explored the architecture of increasingly sophisticated agent systems:

Article 27 — Child Agents: Decomposing Complex Agents

Understanding how complex responsibilities can be separated into smaller capabilities.

Article 28 — Connected Agents: Reusing Independent Agent Capabilities

Exploring reusable agents and the boundaries between independently developed capabilities.

Article 29 — Child Agent vs. Connected Agent: Architecture Decision Guide

Selecting appropriate composition patterns.

Article 30 — Multi-Agent Architecture in Microsoft Copilot Studio

Designing systems that coordinate multiple specialized agents.

Article 31 — Generative Orchestration: How Agents Select Capabilities

Understanding how agents choose tools and other available capabilities.

Article 32 — Microsoft Foundry Agents and Copilot Studio

Extending our architectural perspective beyond Copilot Studio into Microsoft’s broader AI engineering platform.

Next: Article 33 — Microsoft Fabric Data Agents and Copilot Studio

We will explore how specialized data agents can participate in enterprise conversational architectures and how this differs from general document-based knowledge retrieval.

50. Conclusion

Microsoft Foundry and Microsoft Copilot Studio represent complementary approaches to enterprise AI development.

Copilot Studio provides a powerful environment for building enterprise-facing agents and integrating business capabilities.

Foundry provides a broader engineering foundation for working with models, developing specialized agents, implementing custom execution logic, and operating AI solutions.

Combining these platforms can create valuable enterprise architectures, particularly when a conversational agent needs access to specialized AI capabilities developed and managed independently.

However, integration should not become an objective in itself.

The strongest architecture is not necessarily the one with the most agents, models, or services.

It is the architecture that meets business requirements while maintaining clear responsibilities, appropriate security boundaries, reliable behavior, manageable costs, and operational transparency.

For enterprise architects, the central question is therefore not simply:

“Should we use Copilot Studio or Microsoft Foundry?”

A better question is:

“Which responsibilities belong to each platform, and what is the simplest secure architecture that delivers the required business capability?”

Official Microsoft Documentation and References

1. Microsoft Foundry Agent Service — Overview
2. Prompt Agents in Microsoft Foundry
3. Hosted Agents in Microsoft Foundry
4. Connect to a Microsoft Foundry Agent in Copilot Studio — Preview
5. Add a Foundry Agent as a Connected Agent
6. Microsoft Copilot Studio Documentation
7. Microsoft Foundry Documentation
8. Azure AI Search Documentation
9. Microsoft Entra Documentation
10. Microsoft Graph Documentation
11. SharePoint Developer Documentation
12. Power Automate Documentation

Technical note: Microsoft Foundry and Copilot Studio evolve rapidly. Features, preview status, portal experiences, authentication requirements, supported regions, and pricing should be validated against the current Microsoft documentation before implementation.