Add post: Copilot Studio + Foundry in the Same Solution

[OwnOptic]

What

New post on the technical wiring pattern for hybrid Copilot Studio + Azure AI Foundry solutions. Covers:

• MCP bridge pattern with a working TypeScript Azure Function MCP server
• Foundry Agent Service Threads + Runs invocation (GA 2025-05-01)
• What does NOT cross the MCP boundary (and what to pass explicitly)
• Gotchas table, MCP vs Custom Connector vs A2A comparison
• 25 inline references to MS Learn / Microsoft GitHub samples

Companion to

A strategic decision-framework post on the Partner News blog (which tool to pick); this post is the technical complement (how to wire when the answer is "both").

Notes for reviewer

• I'm an external Microsoft Partner (Witivio), happy to coordinate via Adi if that's the preferred onboarding path
• Adds emargot entry to _data/authors.yml
• No header image included - happy to add one before merge if needed
• Two inline SVG diagrams (no PNG assets to commit)

[GiorgioUghini]

Hey, thanks for contributing here. I am making a few updates to the post to reflect the style of the blog.

Additionally, I wanted to ask you if you can add a header image and as well remove those embedded base64 images (in the embedded svg) and use either a PNG image in the asset folder, or even a SVG, but still in the asset folder, which you can reference in the markdown file.

Still, I have a big concern. Why don't we mention at all the multi-agent connection mechanism that you can find in "Agents", but are instead creating additional infra via an Azure Function App? https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-agent-foundry-agent

In the "other architectures" you are also comparing this with a custom connector and again with building a custom A2A relay, but never informing about the activity protocol native way of integrating the two agents. I just wonder if there is a reason (like you've seen this pattern being more stable, or you found other problems in the other approaches) that we need to know.

[OwnOptic]

Thanks for the thorough review @GiorgioUghini - good catches on all fronts. Just pushed 71048e6.

Images: Both inline SVG diagrams moved to assets/posts/copilot-studio-foundry-same-solution/. The base64-encoded product icons inside the SVGs are now sourced from Cloudinary so the SVG files stay small. A header.svg has also been added.

Native Foundry connection: You're right that this was a real gap. Addressed in three places:

1. A paragraph before "When You Are Here" now surfaces the native path (Agents > Add an agent > Microsoft Foundry) as the right starting point for anyone who just wants Foundry as a sub-agent without writing code, with links to the existing CAT post (Connect a Microsoft Foundry agent in Copilot Studio) and the official docs.
2. The "Other Patterns" comparison table now has a fourth row for "Connected agent - native Foundry (preview)" covering the trade-offs and the 404 caveat for agents created in the previous Foundry portal.
3. Added it to the Resources section and to Related CAT blog posts.

The reason this post still focuses on MCP rather than the native connector is the behavioral difference: with the native path Foundry runs its own chain-of-thought and receives the full conversation contextId (opaque sub-agent), whereas MCP gives Copilot Studio full control over what context crosses the boundary and what the orchestrator does with the result (stateless tool call). Both patterns are valid but they solve different problems - the post now makes that distinction explicit upfront so readers can self-select.