As the AI Dev Days Hackathon comes to an end, I want to share my submission.

Today, I want to walk through something I have been building over the last wee while - a project called NimbusIQ. It is my submission for the AI Dev Days Hackathon, and it sits across the Best Multi-Agent System and Best Enterprise Solution categories - NimbusIQ.

At its core, NimbusIQ is built on Microsoft Agent Framework - Microsoft's orchestration layer for composing multi-agent pipelines in .NET. It gives you a WorkflowBuilder pattern for wiring agents together with explicit edges, lifecycle management via InProcessExecution, and the structure needed to run ten specialised agents in a coordinated sequence without the whole thing becoming a tangle of custom plumbing.

Today, we are going to look at change-driven architecture on Azure using Drasi, and why it matters from a Well-Architected perspective.

If you have ever built a system that polls a database every few seconds, asking, "Has anything changed?" - this one is for you.

I recently built an Emergency Alert System and Santa Digital Workshop and Automate Azure Bastion with Drasi Realtime RBAC Monitoring proof of concepts on Azure that use Drasi for reactive data processing. One of the most interesting things I discovered was that change-driven architecture fundamentally shifts how you think about reliability, cost, and operational efficiency.

Every time I see a production container running as root, I wince.

It is one of those things that is easy to fix but gets overlooked because the app "works fine" without it. But container security is not just about non-root users. It is about the full stack: image build, runtime configuration, network policy, input validation, and rate limiting.

In this post, I will walk through a checklist I used to harden a .NET project running on Azure Container Apps.

Today, we are going to look at ingress and edge design decisions for Azure API Management (APIM).

This post captures the tradeoffs between three patterns:

1. Azure Front Door (AFD) + WAF -> Azure API Management (APIM)
2. Azure Front Door (AFD) + WAF -> Application Gateway (AppGw) -> Azure API Management (APIM) (internal)
3. Application Gateway (AppGw) -> Azure API Management (APIM)

The goal here is not architectural purity. It is to pick a pattern that survives real operations: DNS behavior, health probes, private-link approval flow, certificate lifecycle, and failure domains.

Today, we are going to look at building an Emergency Alert System on Azure using Drasi for reactive data processing. This proof of concept explores how change-driven architecture can power real-time alert workflows - from operator creation through approval to delivery.

The United Kingdom (UK) government has an open-code policy, where a lot of code is published publicly. It's a great resource to discover how solutions are built and what's possible with automation. It's definitely been a resource I have leveraged previously as a reference point, even for non-government services I have worked on.

I came across an Emergency Alert System repository, and indications seemed to point to the fact this system ran on (or had some dependencies with) AWS. So I thought to myself - what could this look like if it ran on Azure? I built a proof of concept to find out.