We're launching LogicGrid — a .NET-native framework for building multi-agent AI systems. It's been ten months in the making, and today the beta is on NuGet.
This post is the "why we built this" version. If you'd rather just see code, jump straight to the Quickstart — five minutes from zero to a running agent.
If you've spent any time building with LLMs, you've probably hit the wall: a single prompt only gets you so far. Stuff too much into one prompt and the model loses the plot. Try to do too many things at once and you get inconsistent output.
The answer most teams converge on is multi-agent architectures — multiple specialized agents, each with a focused role, coordinated by an orchestrator. This post covers when and why to reach for multi-agent in .NET, what patterns work, and how to build them without losing your mind.
If you're building AI agents in 2026 and you're not sure which framework to bet on, you're probably looking at three names: LangChain (Python, with a community .NET port), Microsoft Semantic Kernel (.NET, official), and LogicGrid (.NET-native, what you're reading about now).
This post compares the three honestly. None of them is the right answer for everyone. The goal here is to give you concrete criteria for choosing.
Retrieval-Augmented Generation (RAG) is how you make an LLM answer questions about your data without paying to fine-tune it. You take a question, find the most relevant chunks of your documents, and stuff them into the prompt as context.
This post walks through building a production-grade RAG pipeline in C# — from a flat file on disk to a working Ask my docs system with hybrid retrieval that beats simple semantic search on real-world queries.
If you want to run an LLM from a C# application without sending data to OpenAI or Anthropic, Ollama is the easiest path. It runs llama3, mistral, qwen, deepseek, and dozens of other models on your laptop or server, and exposes a simple HTTP API.
This guide walks through using Ollama from C# end-to-end — installation, basic chat, streaming, embeddings, tool calling, and the production gotchas you only learn after you ship.
If you're building an AI feature in .NET in 2026, the first framework you hear about is Microsoft Semantic Kernel. It's well-funded, actively maintained, and integrates deeply with Azure. For most projects, that's a fine starting point.
But "fine for most" is not "right for all." Over the last few months we've talked to teams who started with Semantic Kernel and ended up looking for something else. The reasons cluster around three themes: local LLM support, observability, and dependency footprint.
This post is an honest comparison — not a hit piece. Semantic Kernel is a real piece of engineering. We just think it's worth understanding what trade-offs it makes, and what an alternative shaped around different priorities looks like.