Bryan van der Laan
Writing4 min read#foundry#ai#agents

Who Owns Your Agent’s Harness?

Some projects don't end with "just" an agent#

When I build AI tooling, the same requirements keep coming back: custom tools, custom behavior, and determinism. Copilot Studio and the Power Platform give you a lot of connectors and data sources, but for these projects it's often not enough.

Until now I hosted my own agent code on Azure Container Apps or virtual machines. To use a recent term: I basically built my own harness from scratch for every project. It's a lot of work, and it means I also have to manage everything around the code: identity, isolation, scaling, governance... Governance in particular is where it gets difficult.

When Microsoft announced Hosted Agents at Ignite 2025, I got excited. I'm usually quite sceptical of managed platforms because I want to keep control, but the version Microsoft released in April 2026 changed my mind. Every session gets its own isolated sandbox, every agent gets its own identity in Microsoft Entra, and publishing to Teams and Microsoft 365 Copilot is built in, just like it is for regular Foundry agents. When it became generally available, I got to work right away.

What I mean by a harness#

"Harness" is a term you see more and more, but the idea has been around for a while. A harness is everything around the language model that turns it into an agent: the loop, the tools, the context and the rules it follows.

If you've used Claude Code, you've used a harness. Claude Code launched in February 2025 as a research preview, and it quickly blew up. Underneath it is a loop that reads files, runs commands, manages context and decides what to do next. Anthropic later made that layer available to developers as the Claude Agent SDK. Microsoft did the same with the harness behind Copilot Studio and GitHub Copilot, which is now in preview in Foundry Agent Service as the Copilot harness.

These ready-made harnesses work well for most use cases, but sometimes you just need your own. That's what I use Hosted Agents for.

Copilot Studio is where most businesses start#

A lot of businesses build their first agents in Copilot Studio, and that's a completely valid start. Anyone with a bit of technical know-how can use it, and you get results quickly.

In Copilot Studio you use Microsoft's harness. You configure all you need in the UI and Microsoft runs the loop beneath it. People in the business can build an agent which connects directly to Microsoft 365 data and Teams, all without needing a development team.

In reality I often see that businesses don't really understand what it can and can't do. I also find Copilot Studio agents slow to respond, especially once you add several knowledge sources or Power Automate flows. On top of that, the behavior can be a bit unpredictable and I suspect it's the harness, because Microsoft's harness decides which tools, topics and knowledge sources to use. For the projects where I need determinism, it isn't a strong fit.

But that's where the real value is: once businesses run into the limits they know exactly what their own harness needs to do.

What Hosted Agents give me#

I can use whatever framework fits the project: Microsoft Agent Framework, the Claude Agent SDK, the OpenAI Agents SDK, with support for Python and .NET. I package the agent as a container, or deploy it straight from source code (that option is still in preview, yet it's the one I use), and Foundry runs it.

What I no longer build myself:

  • Isolation: every session runs in its own sandbox with its own files, Foundry manages the conversation history. I don't have to build session and file management myself.
  • Identity: every agent gets its own Entra identity. I no longer create and manage service principals.
  • Versioning: every deployment is a new version with a stable endpoint.
  • Observability: tracing to Application Insights is built in.

Because I do so much front-end work to serve these agents, this matters a lot. I don't have to build and secure my own API layer for every application. I can just focus on the harness itself and deliver what I need to deliver much faster.

What I still build myself#

Hosted Agents don't remove all the work however:

  • The front end and user sign-in. My application still signs the user in with Entra and gets a token to call the agent endpoint.
  • Data permissions. Foundry can pass the user's identity on to tools, but deciding what a user is allowed to see is still my design. (I love the Databricks Genie connector for this! It queries Databricks as the signed-in user, so Unity Catalog decides what they can see.)
  • The harness itself: the logic and the tests that show it behaves the way it should.
  • Cost management. Hosted agents are billed for CPU and memory on top of tokens. Idle sessions cost nothing, but every active session runs in its own sandbox, so I have to think carefully about the use case and the number of users.

So who should own the harness?#

The question is not about choosing the better tool, but who should have ownership over the harness.

  • Copilot Studio: Microsoft owns the harness and you configure it. A good fit when the business builds the agent and the process is standard.
  • Hosted Agents: you own the harness, Microsoft runs the infrastructure. A great fit when the logic around the agent is bigger than the agent itself.

This doesn't mean you always have to choose, because Copilot Studio can call Foundry agents. A business can keep its Copilot Studio agent and hand specific work to an agent that runs in code. It's always interesting to see what non-developers come up with, because they think differently than we do.

But for my projects, I'll keep using Hosted Agents.