When we rolled out Copilot for Dynamics 365 Sales and Customer Service to about 200 users, the business side got most of the attention, and rightly so. Client summaries came faster, email replies took less time, and follow-ups stopped slipping through the cracks.
The people supporting the platform had questions of their own, though. How should this flow be structured? Why is this plugin firing twice? What's the right way to move this solution between environments? So I built Power Platform Expert, a Copilot Studio agent for the people who build on the Power Platform.
Start with the questions
The temptation with a new tool is to open it and start clicking. I'd rather start with a list of the questions people actually ask. If you can't write down twenty real questions your agent should answer, you don't know what you're building yet. That list becomes your scope, your knowledge plan, and your test suite.
Keep the scope narrow
An agent that tries to answer everything ends up answering nothing well. Power Platform Expert has one audience and one job: help developers working on our platform. When a question falls outside that, a clear "that's not something I cover" beats a confident wrong answer.
Grounding beats clever prompts
The Copilot rollout taught me that the quality of the answers depends on the quality of the data behind them. Grounding Copilot on Dataverse made it useful to sellers because it was looking at their real accounts and history. A developer agent is the same. The knowledge you give it matters far more than how you word its instructions.
Test it like any other solution
Run the real questions against it before anyone else does. Write down what it got wrong and why. Then fix the knowledge, the topic, or the scope, and run the list again. It's the same loop as any other feature, just with fuzzier outputs.
An agent is another solution to design, test, version, and support. Treat it that way and it earns its place.
Where this is going
Agents are becoming a normal part of Power Platform work, sitting alongside model-driven apps, flows, and PCF controls. The skills that make a good architect still apply: understand the users, design for the real problem, and keep it maintainable.