What it does
Covers moving agents across the maker surfaces — starting one in Agent Builder and continuing in full Copilot Studio, or taking a Copilot Studio agent and publishing it into Microsoft 365 Copilot. The shared declarative-agent runtime is what makes this possible.
Key facts
- Agent Builder and Copilot Studio produce the same declarative-agent artefact, so a simple agent can graduate to Copilot Studio for more control.
- Copilot Studio agents can be published to Microsoft 365 Copilot as a channel.
- Copilot Studio uses Power Platform solutions for export/import between environments (dev to test to prod).
- Custom engine agents don't "copy" the same way — they carry their own model and code.
- Some settings, connections, and knowledge sources don't travel cleanly and need reconnecting after a move.
When to use / skip
Move up to Copilot Studio when a no-code agent hits its limits. Use solution export/import for proper ALM across environments. Don't treat portability as one-click parity — it's a migration, not a copy.
Configuration decisions
- Where the agent should live long-term (Agent Builder vs Copilot Studio) before you invest in it.
- Solution vs manual recreation for cross-environment moves.
- Which connections and knowledge sources need re-authing at the destination.
Gotchas
- Connections, environment variables, and secrets frequently break on import — expect to reconnect them.
- Graduating from Agent Builder can be one-way in practice; you won't cleanly drop back to the simple builder.
- "Published to M365 Copilot" still needs the usual admin approval to reach users.
Consultant notes
- Decide the target surface early — reworking an agent because it outgrew Agent Builder is avoidable rework.
- Use Power Platform solutions and proper ALM from the start if the agent matters; ad-hoc copying doesn't scale.
- Publishing/approval friction reappears at every environment boundary, so map the promotion path with the admins up front.
*Review if Microsoft ships a first-class agent export/portability f