Building MySerene on the Microsoft Agent Framework: A Preview Experience

Ian Rathbone

13 Jul 2026 • 6 min read

Warning: This post will contain multiple Matrix references. I don't know how I'd make it to the end of it without any.

As cohort 2 of the FCA AI Supercharged Sandbox kicks off, I thought it a good time to actually write the piece I promised to over a month ago. This follows my previous post on Infrastructure, Iteration and Microsoft Aspire.

So! This is all about how and why we used the Microsoft Agent Framework during our time in cohort 1.

First I want to start with a bit of context, because it helps shape everything that follows.

Before the Microsoft Agent Framework existed, Microsoft had two separate projects pulling in different directions. Semantic Kernel was the enterprise-grade SDK for building LLM-powered applications: stable, structured, plugin-based, the kind of thing you'd feel comfortable deploying to a regulated environment. AutoGen came from Microsoft Research and took a different approach entirely: multi-agent systems where agents could reason, collaborate, and iterate autonomously. Experimental by design.

Developers kept asking which one to use. The honest answer was "it depends", which satisfied nobody.

I had prior experience with Semantic Kernel when I was at Talk Think Do, leading our hackathon with the YMCA to create FundingImpact.AI.

I liked it. But when Microsoft announced the Agent Framework in preview last October, the pitch was compelling: a single unified framework that took the enterprise stability of Semantic Kernel and combined it with AutoGen's multi-agent orchestration capabilities. Microsoft's own description was "Semantic Kernel v2.0, built by the same team."

That was enough to make us take a look.

As we were building MySerene inside the FCA AI Supercharged Sandbox, the timing was interesting, and much appreciated!

Three-panel meme from The Matrix showing a figure in sunglasses and suit. Top panel: figure with head replaced by blue-to-pink gradient blob labeled "AG". Middle panel: figure with head replaced by a black spherical shape. Bottom panel: figure with head replaced by a purple geometric abstract symbol. — When two become one! Look, I'll level with you. My meme game isn't strong but I wanted to shoehorn a Matrix Agents reference in here again and this is almost perfect. (almost)

What we were trying to build

MySerene needed multiple agents with distinct roles, running in a defined order, grounded in FCA policy, with safety guardrails and a clean audit trail. Something that could plausibly run in a regulated financial services environment, with advisors making real decisions based on what it surfaced.

The Agent Framework's architecture suited that requirement well.

It distinguishes between two modes of orchestration: deterministic workflows for repeatable, business-logic-driven processes (the Semantic Kernel heritage), and dynamic agent reasoning for open-ended problems (the AutoGen contribution).

For MySerene, we needed both. The sequential execution of our compliance and coaching agents is a deterministic workflow. The reasoning each agent does within its turn is dynamic. Having both in one framework, with one set of abstractions, was genuinely useful.

Building on a preview framework in a regulated programme

As usual, you can count on me to be honest about what this was like.

We were building on something that wasn't finished. The framework was in active development, the team was shipping frequently, and occasionally something would break. Not dramatically. But you'd upgrade the package, run a build, and the compiler would tell you something had changed. An API had moved, an abstraction had been renamed, a pattern had evolved.

The way we found out was usually: upgrade, compile, fix. That's the nature of building on a preview. You accept the trade-off: you get the newest capabilities and you take on some instability in return.

What made it manageable was the pace of the community around the framework.

We weren't raising issues ourselves, but the feedback loop between the community and the Microsoft team was visibly fast. Changes that other developers had flagged were landing in releases. You could watch the changelog and see real problems getting resolved quickly. For a preview framework, that responsiveness matters a lot. It's the difference between feeling like you're building on something that's heading somewhere and feeling like you're on your own.

By the time the Sandbox programme ended, the framework had matured noticeably from where it was when we started.

Bring your own model, and why it matters in regulated financial services

It's also important to note as this point that .NET is well supported across many operating systems including macOS and Linux, it's been a long time since it was just for Windows!

One of the most important things the Agent Framework gave us was genuine model portability.

The framework is model-agnostic by design: the same agent code runs against Azure AI Foundry or against Ollama on a local GPU. For the Sandbox NVIDIA's container toolkit in AWS and forward on to any provider that implements the right interface. Switching is configuration, not code.

We'd already built this into our Aspire AppHost layer, which I wrote about in the previous post. The Agent Framework's abstractions reinforced it at the agent level. The agents themselves have no opinion about which model is underneath. They don't need to.

This came up directly during our mentor sessions in the Sandbox.

A couple of the regulated firms we spoke with made it clear that model choice isn't purely a technical decision for them. Internal governance, data residency requirements, procurement processes, risk frameworks: all of these create constraints on which models a regulated bank can actually use. Some firms have specific approved model lists. Others have requirements about where inference happens. The idea that you could build an agentic system and simply point it at whatever model governance approves, without rewriting anything, resonated strongly.

We went into the Sandbox with bring-your-own-model as a technical preference. We came out of it understanding it as a genuine product requirement for the firms we're building for. The Agent Framework supported that from the start. We'd obviously recommend certain models for specific use cases, but the architecture doesn't force that choice on anyone and it keeps us well supported for future models that we can test against.

Screenshot of C# source code showing ToneGuidanceAgent class definition with private fields, public properties, and method signatures with XML documentation comments. — A peek behind the curtain of an early version of our Tone Guidance Agent

What the framework gave us in practice

A few specific things that reduced friction:

The AIAgent abstraction gave us a clean unit of composition. Each agent has a name, a set of tools, and a system prompt. The per-turn instantiation pattern we adopted, building fresh agent instances with task-specific instructions for each conversation turn, worked naturally with this model. The framework didn't fight us on it.

Tool registration was straightforward. Our FcaLookupTool, RagTool, and EscalationTool plugged in cleanly. The agent's reasoning about when and how to invoke tools felt coherent, which isn't a given with preview frameworks.

The event and messaging model gave us a foundation to build our own streaming event system on top of. The typed event stream that powers the MySerene UI, with TokenEvent, CitationsEvent, EscalationEvent, and the rest, was built with the grain of the framework rather than against it.

Observability was considered from the start. In a regulated environment, being able to trace what happened in any given agent turn isn't optional. The framework's approach to this aligned with what we needed.

The honest verdict

I really liked it!! More than I expected to, given that we were building on a preview that was evolving out of two other tools.

The combination of Semantic Kernel's enterprise patterns and AutoGen's multi-agent capabilities is the right idea. For the kind of problem we were solving, regulated AI with multiple agents, deterministic workflows, safety constraints, and a need for auditability, it felt like a framework designed with those requirements in mind rather than retrofitted to them.

The breaking changes were real but manageable. The community and team responsiveness made the tradeoff worthwhile. And now that it's hit 1.0+ and shipped as production-ready, the case for using it is stronger still. The instability we absorbed during the preview is gone.

What remains is a genuinely well-designed framework that is doing it's best to stay stable and well supported in a constantly changing landscape.

I'd recommend it to anyone building agentic AI in .NET or Python. Particularly if you're building in a regulated context where model portability, auditability, and deterministic workflow control actually matter.

If you used Semantic Kernel before, the migration path is clear. Think of it as the natural next step, not a rewrite.

Figure wearing Superman shirt standing with arms spread in dramatic lighting with glowing effects — Guilty. Of being a promising framework to develop agentic AI!

What's coming next

Now I've started, I can't stop!

I'd like to go into some more detail the agent architecture itself. Sequential vs parallel execution, why the order matters for compliance grounding, and what per-turn agent instantiation looks like in practice.

Thanks for reading, let me know what you think on LinkedIn or Bluesky.

I'm CTO at Serene, where we are building ML and AI-powered tools for financial services advisors. MySerene is our multi-agent platform for real-time, compliant customer support guidance. We were part of Cohort 1 of the FCA AI Supercharged Sandbox.