In the world of quantum computing, generating true randomness is one of the most fundamental applications. But how do we know that a sequence of numbers is truly random and generated by a quantum process, rather than by a classical simulation or a pre-determined list?

In this post, we will explore a protocol to generate high-quality random numbers using a quantum computer, based on the recent paper Certified randomness amplification by dynamically probing remote random quantum states (Liu et al, arXiv:2511.03686, 2025). We will implement the core of this protocol using Q# for the quantum kernel and Python for the orchestration and verification, and then run it on a Q# simulator.

If you visited this blog before, chances are you are familiar with Q# Bridge, a library that I have been working on for quite a while, that allows you to run Q# quantum simulations and access a number of Q# compiler/QDK features from multiple popular high-level languages such as C#, Swift, Python and Kotlin.

Today, I would like to shortly talk about a brand new feature in the library - the ability to generate Quantikz LaTeX circuits from Q# source code.

I’ve recently been working on setting up a bunch of Agent Framework samples, which would showcase the cooperation between cloud agents (backed by LLMs in the cloud) and local agents (running on your own machine). Since I primarily work on a Mac, the natural choice for me was to use MLX as the local model runner, which required a bit of bootstrapping - and felt quite tedious. So, the natural next step was to create a library that would make it easy to integrate MLX models into Agent Framework applications, since there wasn’t one available yet.

Today, I’m excited to announce the release of the MLX Integration Library for Agent Framework! This library simplifies the process of integrating MLX models into your Agent Framework applications, allowing you to leverage local Mac AI capabilities seamlessly alongside cloud-based agents.

When building AI workflows, we often face a choice: do we use a massive, expensive cloud model for everything (to ensure best reasoning capabilities), or do we cut costs with a smaller local model (and risk hallucinations)? In this post, we’ll explore a “best of both worlds” architecture, as described in the recent survey “Small Language Models for Agentic Systems” Sharma & Mehta, 2025.

We call this the “SLM-default, LLM-fallback” pattern. The premise is simple: route all queries to a fast, private, on-device Small Language Model (SLM) first. Only if that model cannot confidently answer the query, do we escalate the request to a paid cloud model (LLM).

Last week, we released version 2.0 of dotnet-script. The latest release introduces support for .NET 10.0 and C# 14 and is available, as usually, through Github releases and on Nuget. You will need to have at least the .NET SDK 10.0.100 installed.

It is the first major release of dotnet-script since version 1.0, which was released back in 2020. At the same time, the breaking changes are minimal, and the revision is mostly driven by the careful application of semantic versioning principles.

In this post, we’ll explore a novel approach to optimizing AI workflows by strategically combining large language models (LLMs) with small language models (SLMs) using the “Minions pattern.” This technique, described in the research paper “Minions: Cost-efficient Collaboration Between On-device and Cloud Language Models” by Narayan et al., addresses one of the most pressing challenges in AI application development - the cost of processing large amounts of data with expensive, cloud-based language models. If you’ve ever built an AI system that needs to analyze extensive documents or datasets, you’ve probably felt the frustration of watching your API costs skyrocket as you process more and more content.

Over recent years I have been involved in the post-quantum cryptography community, especially from the .NET angle - trying to streamline integration of PQC into .NET space and raise the awareness of developers via various projects, samples and articles.

In this spirit, I would like to announce today a library called (Maybe) LibOQS.NET, which is a thin wrapper around liboqs, a C library providing implementations for all post-quantum cryptography algorithms. This includes both the standardized ones, like ML-KEM, ML-DSA and SLH-DSA, as well as the ones currently undergoing standarization and under active research and development.

Following up on my recent posts about ML-KEM and ML-DSA post-quantum cryptography in .NET using BouncyCastle.NET, I wanted to share an interesting development on the Windows side. Microsoft has recently announced post-quantum cryptography support in Windows through their Cryptography API: Next Generation (CNG) libraries.

This development provides an alternative to third-party libraries for quantum-resistant cryptography on Windows systems. The implementation offers direct OS integration and follows standard .NET patterns for cryptographic operations.

In this post we will explore a novel approach to Retrieval-Augmented Generation (RAG) called HyPE (Hypothetical Prompt Embeddings), which I came across in a preprint paper recently. This technique tries to address one of the fundamental challenges in RAG systems: the semantic mismatch between user queries and document content. If you’ve ever built a RAG system, you’ve probably felt the frustration when your carefully crafted vector search returns seemingly irrelevant results. At least for me, it was always tremendously annoying when a simple question like “What is quantum entanglement?” wouldn’t reliably match a document section that clearly explains quantum entanglement.

In the previous part of this series, we explored how to attach OpenAPI-based tools to a Semantic Kernel AI agent. In this part, we will look at another SDK for building AI Agents, Azure AI Foundry SDK, to create an agent that can also interact with OpenAPI-based tools.