Lessons from Copilot Studio and Beyond
Over the past several months, some colleagues and I have been exploring how to build a scalable, multi-agent AI system that could support real organizational workflows, such as work logging, expert discovery, scheduling, and long-term knowledge capture.
What began as an experiment in Microsoft Copilot Studio evolved into a full Azure AI Foundry–based system. This post explains why that shift happened, what we learned along the way, and how Foundry ultimately enabled the flexibility we were missing.
The Problem We Were Trying to Solve
Our goal was to create an AI-powered system that could:
- Route user intent dynamically
- Coordinate multiple specialized agents
- Persist conversation history and organizational knowledge
- Continuously learn from interactions
- Integrate naturally into tools like Microsoft Teams
In other words, this wasn’t a single copilot or chatbot- it was an orchestrated AI system with memory, specialization, and extensibility.
Our First Attempt: Copilot Studio and the Power Platform
We initially built a prototype using:
- Microsoft Copilot Studio
- Power Apps
- Power Automate
- Dataverse
This stack was appealing for a few reasons:
- Fast iteration
- Native Microsoft 365 integration
- Minimal infrastructure overhead
We attempted to recreate the system as a series of Copilot topics, flows, and connected actions. Conceptually, it worked- at least on paper…
Where Copilot Studio Fell Short
As the system grew more complex, we ran into limitations that were difficult to work around:
- Tightly coupled configurations made agent-to-agent coordination hard to reason about
- Limited control over conversation state and memory
- Difficulty implementing true multi-agent orchestration
- Complex logic quickly became fragmented across flows and topics
Copilot Studio excels at guided interactions, but it struggled to support a deeply composable, evolving AI system.
At a certain point, we weren’t designing agents- we were designing around platform constraints.
Trying n8n as a Middle Layer
Next, we experimented with a hybrid approach:
Copilot Studio → n8n → Azure AI Foundry
n8n gave us more flexibility:
- Better flow control
- Easier branching logic
- More visibility into execution paths
This brought us closer to what we wanted, but it still introduced friction. The system was now split across tools with different mental models, making debugging and evolution harder over time.
Enter Azure AI Foundry
Azure AI Foundry gave us something the other approaches couldn’t: a first-class foundation for agent orchestration.
With Foundry, we could:
- Define specialized agents with clear responsibilities
- Control handoffs explicitly
- Manage context and memory intentionally
- Treat agents as composable system components, not isolated bots
This shift fundamentally changed how we thought about architecture.
How Foundry Fits into Our Current Architecture
Today, our system lives in a single monorepo we call RBAC Foundry, consisting of:
- A unified Next.js application for chat and UI
- A C# ASP.NET Core API for orchestration and handoffs
- Azure AI Foundry agents for intent classification, work logging, expert search, scheduling, and organizational intelligence
- A Cosmos DB MCP server for structured memory, vector search, and knowledge operations
- Native Microsoft Teams integration
Each agent is purpose-built, while Foundry handles coordination and execution. The result is a system that feels cohesive instead of stitched together.
What This Enabled That We Couldn’t Do Before
Moving fully into Foundry unlocked capabilities that simply weren’t practical before:
- Dynamic skill extraction and proficiency tracking
- A perpetually learning organizational knowledge base
- Natural-language expert discovery across teams
- Clear separation between UI, orchestration, and intelligence
- Long-term maintainability as agents evolve independently
Most importantly, it allowed us to design the system around how we think, not how a platform forces us to think.
Final Thoughts
Copilot Studio is powerful, but it’s opinionated. For guided copilots, that’s a strength. For deeply orchestrated, multi-agent AI systems, it can become a constraint.
Azure AI Foundry gave us the control, composability, and clarity we needed to build something that could grow with us.
If your AI ambitions extend beyond a single conversational assistant, Foundry may be worth a serious look.
About the Author
Ethan Ellerstein
Intern at RBA
Ethan Ellerstein is an AI Intern at RBA with a focus on building practical, real-world solutions using the Microsoft ecosystem. He works with tools like Power Apps, Power Automate, Copilot Studio, and Azure AI Foundry to create intelligent systems that improve how teams capture knowledge and work more efficiently. He is passionate about making AI accessible, responsible, and useful for everyday business problems.