The Copilot Studio experiences with UntypedObjects is a bit painful at the moment.
This article helps to show an approach that I took to be able to work with them in Copilot Studio when building Copilot Agents.
Firstly, let’s explain what an UntypedObject is. It is effectively a dynamic object which Copilot Studio does not know what the structure of it is. The object gains a dynamicProperty property which should allow you to read properties but within Copilot Studio currently that seems to go wrong.
The Problem
If you are working with data that Copilot Studio cannot resolve the type of, then you will be working with an UnTypedObject.
An example that I had was with Dataverse where I using a Environment variable to state which environment to connect to. This meant that the data that was being retrieved could not be resolved at design time and so it returned back a record of UntypedObject as shown in the screenshot below.
I tried all sorts of different approaches to see if I could make use of the object but ultimately it was the dynamicProperties property that was causing problems as Copilot Studio seemed to want to use that to convert the data and of course my real object did not have that as a property.
In the end, I stumbled on a solution using the Parse JSON activity.
A Solution
I am hoping that there are nicer solutions coming from the Copilot Studio team but this is how I turned the UntypedObject into a Typed Object.
I tried a few different approaches, including using PowerFX Types to see if I could manage the conversion of Type. However, these ended up not working or hitting syntax error issues.
As I said previously, I then stumbled on the ParseJson activity.
Using the ParseJson Copilot Studio activity, along with a copy of the JSON string object, helped me get over the issues.
Here is what I did. First of all I outputted the whole table to a message using a Send Message activity, as shown below.
Then, I copied an example of the Json and used that with the ParseJson activity.
Here is the schema for the Parse JSON activity.
The output of the ParseJson gave me a variable with a known shape.
Now that I have a variable with a known type, we are golden and everything is working as you would expect.
The data can be used as normal with other activities, such as Power Automate.
Problem solved!
Conclusion
As we spend more time working on Copilot Studio solutions, I am sure these experiences will improve. Anyway, I hope you stumble on this and it helps you out.
I spent a few hours trying different things and ultimately found this solution.
Last week, Microsoft Build 2025 announced the introduction of Multi-Agent Copilots within Copilot Studio and the ability to configure one Copilot Agent to make use of other Copilot Agent’s and their tools.
I have been pondering on this for a while, but whilst watching the demos, this got me thinking about how these Agents will be delivered.
It’s clear that there will be a lot of thought required to deliver a solid multi-Agent architecture, which will need to be designed and engineered! There is also no doubt that Generative AI is enabling people to do and achieve more. I am using it daily to help support all my tasks and I especially love how it helps me with coding, through GitHub Copilot.
However, there is a lot of rhetoric out there which talks about the end of developers and how there will be no need for them in the future. Whilst I am sure AI will help developers code better, the thinking and design that Agents will need in the future will require developer principals to get the best from their exciting capability. They will need to be built in a well thought out way to deliver powerful AI Agentic experiences in organisations.
Principals such as the Single Responsibility Principal and Do Not Repeat yourself come immediately to mind. I believe that there will be some low hanging fruit, simple use cases that are relatively easy to implement, as well as more complex scenarios, such as multi-Agents that will require much more thought, architecture and design before they are built. The latter will require traditional solution architecture, developer and enterprise architecture skills. Maybe we will start seeing jobs with job titles such as AI Agent Architect.
I am not going to try and claim that I have established best practices for multi-Agent architecture just yet, but it’s definitely something I’m actively thinking about.
Anyway, let share my thoughts and my current thinking.
Proposed Internal Company Architecture
This is a proposed architecture design example for an internal Company agent structure used by Employees within the business.
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
I can imagine that Agents will also follow a similar structure. There will be a company Agent which is broken down into department agents. In the same way that we like to structure SharePoint and Teams workspaces, where each department has a public site available to the rest of the business and an internal workspace(s) for their department team. Therefore, there might a public facing department Agent, used by other parts of the business and also by customers. There could also be an internal team Agent(s) that are used by the people within the team.
The department Agent will call into the internal department Agents to start processes and get help and support from the team within the department. Some of that support could also come from the digital Agent or the human Agent.
Microsoft’s thinking is well underway with Agent-to-Agent communication. An example of this is with the announcements of Agents having a first-class identity within Microsoft Entra ID. This means that Agents can be directly identified by Entra.
Also announced were several other features ,such as using Microsoft Entra ID for managing security boundaries for Agents. Here, security groups can be used to control which Agents can talk to one another and presumably who can talk to those Agents also.
All these features are needed to be able to control and architect your multi-Agent landscape within your business.
If you think about all the Agent related protocols that have been announced over the past few months, the landscape is expanding quickly.
For example, we have Model Context Protocol (MCP) and Agent 2 Agent (A2A), which widens the landscape and the need for design and architecture, making it become ever more important.
There are several protocols which are also enabling this Agentic world. A recent announcement ofthe Agentic Network Protocol (ANP), which explores how Agents can discover one another on an open network. Finally, Agent Communication Protocol (ACP) has emerged as a potential competitor to A2A for Agent-to-Agent communication.
Ultimately, we need to start building Agents and working out which Ones are working well for a business and which ones are not.
I’d be concerned if an organisation tried to design and architect everything up front, as I am sure this will lead to incorrect decisions being made as well as unnecessary designs. Additionally, it is early in the multi-agent communication and protocol space, and this landscape is still emerging and will continue to evolve.
I do, however, suspect that there will be deployment of Agents at the department/team level, and these will be refactoring to expose the tools or capabilities of those Agents outside of the department/team and ultimately outside of the business to customers and suppliers.
We will need to be careful with these Agents as we need to ensure that there are human-in-the-loop principles in place. This will ensure that humans are checking and reviewing outputs just as you would review the work of a team member or validate outputs from any process.
However, to help reduce the amount of rework and technical debt, we should look at building the Agent tools in a way that allows them to be exposed individually to other Agents.
In the short term, I would advise continuing to experiment and gathering feedback. Have a medium-term goal in mind, connecting the most successful experiments into multi-agent solutions.
It is going to be an interesting few years ahead, and I am really looking forward to the transformation journeys within our businesses and excited about what’s to come.
Finally, if you found this useful and are looking to implement Agents into your business, we’d love to have a chat about your plans, share our thoughts, and show you what we’re doing at iThink 365 and with our customers.
Doy's Microsoft 365 and Azure Dev Blog 