{ "version": "https://jsonfeed.org/version/1", "title": "LogicGrid Blog", "home_page_url": "https://logicgrid.dev/blog", "description": "Articles about building AI agents in .NET", "items": [ { "id": "https://logicgrid.dev/blog/introducing-logicgrid", "content_html": "

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.

\n

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.

\n

The problem​

\n

We needed to build an AI feature for a regulated environment where customer data couldn't leave the network. Two requirements that turned out to be in tension:

\n
    \n
  1. We were on .NET. Migrating to Python was a non-starter.
    2. \n
  2. We needed local LLMs. Cloud providers were off the table for compliance reasons.
    3. \n
\n

We tried the obvious frameworks:

\n\n

So we built LogicGrid: the framework we wished existed.

\n

What's different​

\n

Three things distinguish LogicGrid from what's already out there:

\n

1. Local LLMs are first-class​

\n

Same code runs against Ollama, vLLM, LM Studio, TEI, OpenAI, Anthropic, Gemini, or any OpenAI-compatible endpoint. Switching providers is a one-line change:

\n
var llm = LlmClientBase.Ollama(\"llama3.2\");
// var llm = LlmClientBase.OpenAI(\"gpt-4o\");
// var llm = LlmClientBase.Anthropic(\"claude-sonnet-4-6\");
\n

There's no second-tier path for local providers. The streaming protocol, tool calling, and embeddings work identically across all of them.

\n

2. Observability is built in​

\n

Every agent step, tool call, retry, and LLM call emits a structured event. Token counts, timings, errors, tool arguments — all of it, no extra code:

\n
var ctx = new AgentContext()
    .WithLogging()
    .WithTracing(out var trace);

await agent.RunAsync(\"...\", ctx);
\n

Pipe it to a console, file, or OpenTelemetry collector. When a customer reports a bad answer, you can pull up the full trace. No black boxes.

\n

3. Zero hidden runtime dependencies

\n

LogicGrid targets netstandard2.0, net6.0, and net8.0. The full SBOM ships in the public repo as bom.json. The dependency graph is small enough that you can audit every package before it touches your build server.

\n

This matters for air-gapped enterprise deployments where every transitive dependency is a question to answer.

\n

What's in the box​

\n

The framework is split across five NuGet packages so you only pull in what you need:

\n
dotnet add package LogicGrid.Core     # Agents, admins, orchestration, events
dotnet add package LogicGrid.Memory   # Vector stores, embeddings, hybrid search
dotnet add package LogicGrid.Rag      # Full RAG pipeline
dotnet add package LogicGrid.Tools    # Tool / function calling
dotnet add package LogicGrid.Mcp      # MCP (Model Context Protocol) client
\n

Highlights:

\n\n

A 5-minute example​

\n
dotnet add package LogicGrid.Core
ollama pull llama3.2
\n
using LogicGrid.Core.Agents;
using LogicGrid.Core.Llm;

var llm = LlmClientBase.Ollama(\"llama3.2\");

IAgent agent = new Agent<string>(
    name: \"Helper\",
    description: \"Answers questions concisely.\",
    systemPrompt: \"Answer in one short sentence.\",
    llm: llm);

Console.WriteLine(
    await agent.RunAsync(\"What is the capital of France?\", new AgentContext(\"ask\")));
\n

Three using statements. Four logical lines. No appsettings.json ritual, no DI registration dance.

\n

When you outgrow a single agent, the multi-agent patterns are right there:

\n
var admin = new GroupChatAdmin<string, string>(
    name: \"Editorial\",
    llmClient: llm,
    agents: new[] { researcher, writer, critic });

Console.WriteLine(await admin.RunAsync(\"Explain RRF in 200 words.\"));
\n

The Quickstart walks through the rest.

\n

What's next​

\n

LogicGrid is at 0.1.3-beta today. The core API is stable enough that we're building production systems on it, and after months of external feedback we're moving to beta.

\n

The roadmap toward beta and 1.0:

\n\n

If you try it and something is missing or broken, open an issue or jump into discussions. Early-adopter feedback shapes what we ship next.

\n

How LogicGrid fits with what's already out there​

\n

If you're already happy with Semantic Kernel or LangChain.NET, that's great — keep using them. We didn't build LogicGrid to replace them; we built it because we needed something different.

\n

For a side-by-side, see LangChain vs Semantic Kernel vs LogicGrid.

\n

If you're frustrated by Semantic Kernel's posture toward local LLMs, see A Semantic Kernel Alternative for .NET.

\n

If you're new to the whole space, How to use Ollama with C# is the gentlest on-ramp.

\n

Try it​

\n
dotnet add package LogicGrid.Core
\n

Five minutes from zero to a running agent. If it doesn't fit your stack, you'll know quickly. If it does, the docs walk you through everything else.

\n

Thanks for reading. We're excited to see what people build.

", "url": "https://logicgrid.dev/blog/introducing-logicgrid", "title": "Introducing LogicGrid — Multi-Agent AI Orchestration for .NET", "summary": "Why we built LogicGrid, what's different about it, and how it fits alongside Semantic Kernel and LangChain.NET. With a 5-minute walkthrough.", "date_modified": "2026-04-25T00:00:00.000Z", "author": { "name": "LogicGrid Team", "url": "https://logicgrid.dev" }, "tags": [ "announcement", "dotnet", "csharp", "ai-agents", "llm" ] }, { "id": "https://logicgrid.dev/blog/multi-agent-framework-for-dotnet", "content_html": "

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.

\n

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.

\n

Why multi-agent?​

\n

Single-agent systems work great for narrow tasks: summarize this, translate that, classify the other. But when the task has multiple steps with different cognitive loads, single-agent breaks down.

\n

Consider: \"Research recent advances in retrieval-augmented generation, write a 500-word summary, and check it for factual accuracy.\" That's three jobs:

\n\n

Cram all three into one prompt and you get a mediocre version of each. Split them into three agents and each one does its job well.

\n

That's the multi-agent pitch in one sentence: specialization beats generalization, even at the prompt level.

\n

When NOT to use multi-agent​

\n

Before getting excited, the honest answer: most production AI features should be single-agent. Multi-agent adds:

\n\n

If you can solve your problem with one well-crafted prompt and a structured output, do that. Multi-agent is for problems you genuinely can't fit into one head.

\n

The patterns​

\n

There are five practical patterns. Each maps to a different problem shape.

\n

1. Sequential​

\n

The simplest pattern. Output of agent A → input of agent B → input of agent C. Use when steps are linear and each depends on the previous.

\n
using LogicGrid.Core.Admins;

var admin = new SequentialAdmin<string, string>(
    name: \"Pipeline\",
    llmClient: llm,
    agents: new IAgent[] { researcher, writer, editor });

var result = await admin.RunAsync(\"Topic: Reciprocal Rank Fusion\");
\n

Best for: ETL-like flows, structured pipelines, document transformation.

\n

2. Group chat​

\n

Multiple agents share a conversation. An admin (often an LLM) decides who speaks next based on what the agents have said so far.

\n
var admin = new GroupChatAdmin<string, string>(
    name: \"Editorial\",
    llmClient: llm,
    agents: new IAgent[] { researcher, writer, critic },
    options: new AdminOptions { MaxLoops = 10 });

var article = await admin.RunAsync(
    \"Explain hybrid search in 200 words.\");
\n

The admin LLM picks an agent, that agent contributes, then the admin picks again. The loop ends when the admin decides the task is done (often when a critic responds with \"DONE\").

\n

Best for: open-ended creative tasks, debates, brainstorming, code review.

\n

3. Graph (DAG)​

\n

Each agent is a node. Edges describe data flow and conditionals. Branching, merging, and conditional routing are first-class.

\n
using LogicGrid.Core.Graph;

var graph = AgentGraphBuilder
    .Start(classifier)
    .ThenIf(classifier, technicalAgent,
        condition: r => r.Contains(\"technical\"))
    .ThenIf(classifier, friendlyAgent,
        condition: r => !r.Contains(\"technical\"))
    .Then(technicalAgent, formatter)
    .Then(friendlyAgent, formatter)
    .Terminal(formatter)
    .Build();

var output = await graph.RunAsync(\"Why is my deploy failing?\");
\n

Best for: complex workflows, conditional logic, fan-in/fan-out patterns. The pattern most production systems eventually grow into.

\n

4. Parallel + Map-Reduce​

\n

Run multiple agents in parallel and aggregate results.

\n
using LogicGrid.Core.Admins;

var admin = new ParallelAdmin<string, string>(
    name: \"MultiAnalyst\",
    llmClient: llm,
    agents: new IAgent[] { financialAnalyst, legalAnalyst, technicalAnalyst },
    aggregator: synthesizer);

var report = await admin.RunAsync(
    \"Analyze this contract from three angles.\");
\n

Best for: tasks where multiple perspectives need to be combined. Document analysis, code review, due diligence.

\n

5. Reflexion (self-critique)​

\n

An actor generates output. A critic evaluates it. If the critic approves, the run ends. If not, the actor retries with feedback. Loops until approved or MaxIterations is reached.

\n
var admin = new ReflexionAdmin<string, string>(
    name: \"Refiner\",
    llmClient: llm,
    actor: writer,
    critic: critic,
    options: new ReflexionOptions { MaxIterations = 3 });

var refined = await admin.RunAsync(
    \"Write a marketing one-liner for our product.\");
\n

Best for: tasks where quality matters more than speed. Marketing copy, code generation, summarization of high-stakes content.

\n

How to choose a pattern​

\n

Start by asking: what does my problem actually look like as a flowchart?

\n\n

You can mix patterns. A graph node can be a group chat. A sequential pipeline can include a reflexion step at the end. The patterns compose.

\n

Observability — the part nobody talks about​

\n

Multi-agent systems are notoriously hard to debug. When the user gets a bad answer, was it the researcher's fault? The writer's? The critic's? The admin?

\n

The only way out is structured observability. Every agent step, every tool call, every retry, every LLM call should emit a structured event that you can query later.

\n

LogicGrid does this by default:

\n
var ctx = new AgentContext()
    .WithLogging()
    .WithTracing(out var trace);

await admin.RunAsync(\"Explain RRF in 200 words.\");

// Inspect every step the admin and its agents took
foreach (var span in trace.Spans)
    Console.WriteLine($\"{span.Name} — {span.Duration.TotalMilliseconds:F0}ms\");
\n

Every event includes: agent name, run ID, timing, token count, tool calls, errors. Pipe it to a structured log, OpenTelemetry collector, or your own analytics.

\n

When a customer comes back with \"the agent gave a bad answer,\" you can pull up the full trace and see exactly what happened.

\n

Cost and latency​

\n

Three agents = three LLM calls = roughly 3x cost and 3x latency vs single agent. There are mitigations:

\n\n

LogicGrid makes all four easy because providers are interchangeable in one line.

\n

A real example​

\n

Here's what a real production multi-agent system might look like — a code review bot:

\n
var llm = LlmClientBase.Ollama(\"llama3.2\");

IAgent securityReviewer = new Agent<string>(
    \"Security\", \"Looks for security issues.\",
    \"Review the diff for security vulnerabilities. List concerns.\", llm);

IAgent perfReviewer = new Agent<string>(
    \"Performance\", \"Looks for performance issues.\",
    \"Review the diff for performance problems. List concerns.\", llm);

IAgent styleReviewer = new Agent<string>(
    \"Style\", \"Looks for style issues.\",
    \"Review the diff for style/readability. List concerns.\", llm);

IAgent synthesizer = new Agent<string>(
    \"Reviewer\", \"Synthesizes feedback.\",
    \"Combine the reviews into a single PR comment, prioritized.\", llm);

var admin = new ParallelAdmin<string, string>(
    name: \"CodeReviewBot\",
    llmClient: llm,
    agents: new IAgent[] { securityReviewer, perfReviewer, styleReviewer },
    aggregator: synthesizer);

var review = await admin.RunAsync(diffText);
PostToGitHub(review);
\n

Three independent reviewers run in parallel, then a synthesizer combines them into a single comment. Total wall-clock time is about the same as a single agent, but the output covers multiple dimensions.

\n

Going further​

\n\n

If you're comparing frameworks, see LangChain vs Semantic Kernel vs LogicGrid.

\n

If you want a single-agent introduction first, How to use Ollama with C# covers the basics.

", "url": "https://logicgrid.dev/blog/multi-agent-framework-for-dotnet", "title": "Multi-Agent Frameworks for .NET — A Practical Guide", "summary": "A practical look at why multi-agent architectures matter, when to use them, and how to build them in .NET. With patterns for sequential, group chat, graph, and reflexion orchestration.", "date_modified": "2026-04-18T00:00:00.000Z", "author": { "name": "LogicGrid Team", "url": "https://logicgrid.dev" }, "tags": [ "multi-agent", "dotnet", "csharp", "ai-agents", "orchestration", "llm" ] }, { "id": "https://logicgrid.dev/blog/langchain-vs-semantic-kernel-vs-logicgrid", "content_html": "

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).

\n

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.

\n

TL;DR​

\n
Pick thisIf you...
LangChain (Python)Are on Python and want the largest ecosystem and integrations
LangChain.NETAre on .NET, primarily prototype, and want familiarity with Python LangChain
Semantic KernelAre on .NET, deeply on Azure, and want first-party Microsoft support
LogicGridAre on .NET, need local LLMs as first-class, and want observability built in
\n

The rest of this post explains why.

\n

What each one is​

\n

LangChain (Python)​

\n

The original LangChain. Massive ecosystem — 700+ integrations, hundreds of community packages, every vendor has a connector. If you're in Python and you can name a vector DB, embedding model, or LLM provider, LangChain has a wrapper for it.

\n

LangChain has matured a lot since the early 2023 days when it was infamous for breaking changes. It's now reasonably stable, though still moving fast.

\n

LangChain.NET (community port)​

\n

A community-maintained C# port of LangChain. Maintained by tryAGI. It tracks the Python version with a lag — new features land in Python first and trickle over.

\n

For .NET teams who want LangChain familiarity, it's a reasonable choice. Just know that it's not officially supported by LangChain Inc., and the integration coverage is much narrower than Python.

\n

Microsoft Semantic Kernel​

\n

Microsoft's official .NET (and now Python and Java) framework for AI orchestration. Backed by significant Microsoft engineering. Deeply integrated with Azure OpenAI, Azure AI Search, and Microsoft 365.

\n

Semantic Kernel uses a \"kernel + plugins + planner\" architecture. You register plugins (skills) with the kernel, and a planner LLM decides which plugins to call to solve a task. It's a flexible model but encourages letting the LLM drive — which is sometimes what you want and sometimes a debugging nightmare.

\n

LogicGrid​

\n

A .NET-native framework focused on three things: local LLMs as first-class citizens, observability built in, and zero hidden runtime dependencies. Provider-agnostic — same code runs against Ollama, OpenAI, Anthropic, Gemini, vLLM, TEI, LM Studio.

\n

LogicGrid uses an \"explicit orchestration\" model. You describe the agent graph; the LLMs fill in the steps. This is more code than a Semantic Kernel planner but vastly easier to debug.

\n

Same task, three frameworks​

\n

Let's compare a simple task: an agent that takes a topic, researches it, and writes a 200-word explainer with a critic loop.

\n

LangChain (Python)​

\n
from langchain.chat_models import ChatOpenAI
from langchain.agents import initialize_agent, AgentType
from langchain.tools import Tool

llm = ChatOpenAI(model=\"gpt-4o\")
tools = [Tool(name=\"search\", func=search, description=\"...\")]

agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION)
print(agent.run(\"Explain Reciprocal Rank Fusion in 200 words.\"))
\n

Concise. The framework decides the workflow under the hood.

\n

Semantic Kernel (.NET)​

\n
var builder = Kernel.CreateBuilder()
    .AddOpenAIChatCompletion(\"gpt-4o\", apiKey);
var kernel = builder.Build();

var planner = new HandlebarsPlanner();
var plan = await planner.CreatePlanAsync(
    kernel, \"Research and write 200 words about RRF.\");
var result = await plan.InvokeAsync(kernel);

Console.WriteLine(result);
\n

Similar shape — you describe a goal and the planner decides how to achieve it.

\n

LogicGrid (.NET)​

\n
var llm = LlmClientBase.Ollama(\"llama3.2\"); // or OpenAI, Anthropic, etc.

IAgent researcher = new Agent<string>(
    \"Researcher\", \"Gathers facts on a topic.\",
    \"You research the topic and list 3 key facts.\", llm);
IAgent writer = new Agent<string>(
    \"Writer\", \"Writes a short article.\",
    \"You write a 200-word explainer using the researcher's facts.\", llm);
IAgent critic = new Agent<string>(
    \"Critic\", \"Reviews the article.\",
    \"You check the article. Reply DONE when it is publishable.\", llm);

var admin = new GroupChatAdmin<string, string>(
    name: \"Editorial\",
    llmClient: llm,
    agents: new[] { researcher, writer, critic });

Console.WriteLine(await admin.RunAsync(
    \"Explain Reciprocal Rank Fusion in 200 words.\"));
\n

More verbose, because you explicitly name the three roles. But every agent's role is visible. When something goes wrong, you know exactly where to look.

\n

The big differences​

\n

Local LLM support​

\n
LangChainLangChain.NETSemantic KernelLogicGrid
Ollama✓PartialPartial✓ first-class
vLLM✓LimitedLimited✓ first-class
LM Studio✓PartialPartial✓ first-class
TEI (HuggingFace)✓NoNo✓ first-class
\n

LangChain and LogicGrid lead here. Semantic Kernel works with local LLMs but the path is rougher.

\n

Multi-agent patterns​

\n
LangChainSemantic KernelLogicGrid
Sequential✓✓✓
Group chat✓ (LangGraph)Partial✓
Graph (DAG)✓ (LangGraph)Partial✓
Parallel✓Partial✓
Map-Reduce✓No✓
Reflexion (self-critique)ManualManual✓ built-in
\n

LangChain's LangGraph is the gold standard for graph orchestration. LogicGrid covers the same patterns natively in .NET. Semantic Kernel is catching up but is still planner-centric.

\n

Observability​

\n
LangChainSemantic KernelLogicGrid
Structured eventsLangSmith (paid)OpenTelemetry (manual)Built-in
Token countsLangSmithManualBuilt-in
Run tracingLangSmithManualBuilt-in
Tool call logsLangSmithManualBuilt-in
\n

LangSmith is excellent but it's a paid service. LogicGrid's tracing is open and free — events are emitted to an in-process bus you can route anywhere (console, file, OTel collector).

\n

Deployment posture​

\n
LangChainLangChain.NETSemantic KernelLogicGrid
.NET Framework 4.7.2+n/aNoNo✓
.NET 6n/a✓No✓
.NET 8n/a✓✓✓
Air-gapped friendlyHardHardHard✓
SBOM publishedNoNoPartial✓ CycloneDX
\n

LogicGrid is the only one that works on legacy .NET Framework — useful for enterprise teams who can't migrate everything to .NET 8 yet.

\n

When each one wins​

\n

Pick LangChain (Python) if...​

\n\n

Pick LangChain.NET if...​

\n\n

Pick Semantic Kernel if...​

\n\n

Pick LogicGrid if...​

\n\n

The honest take​

\n

There is no single winner. There's the right tool for your constraints.

\n

If you're a Python team running on AWS or GCP, LangChain is the obvious choice — biggest ecosystem, most learning material, most jobs.

\n

If you're a .NET team running on Azure with Azure OpenAI, Semantic Kernel is the obvious choice — first-party support beats everything.

\n

If you're a .NET team that needs local LLMs, has a serious bar for dependency hygiene, or simply wants to see what your agents are doing without writing telemetry plumbing, LogicGrid is built for you.

\n

Try the Quickstart — it takes five minutes. If LogicGrid fits, you'll know quickly.

\n
\n

Related posts:

\n", "url": "https://logicgrid.dev/blog/langchain-vs-semantic-kernel-vs-logicgrid", "title": "LangChain vs Semantic Kernel vs LogicGrid — Picking an Agent Framework in 2026", "summary": "An honest, feature-by-feature comparison of LangChain, Microsoft Semantic Kernel, and LogicGrid for building AI agents in 2026. With code samples and concrete decision criteria.", "date_modified": "2026-04-10T00:00:00.000Z", "author": { "name": "LogicGrid Team", "url": "https://logicgrid.dev" }, "tags": [ "langchain", "semantic-kernel", "comparison", "ai-agents", "dotnet", "python" ] }, { "id": "https://logicgrid.dev/blog/build-a-rag-pipeline-in-csharp", "content_html": "

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.

\n

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.

\n

What you're building​

\n

By the end of this post you'll have a working C# program that:

\n
    \n
  1. Loads a folder of documents
    2. \n
  2. Chunks them intelligently
    3. \n
  3. Generates embeddings using Ollama (or OpenAI, your choice)
    4. \n
  4. Stores them in a vector index
    5. \n
  5. Answers questions using both dense semantic search and BM25 keyword search, fused with Reciprocal Rank Fusion
    6. \n
\n

That last piece — hybrid search — is what separates toy RAG demos from systems that actually work in production.

\n

Why naive RAG fails​

\n

The standard RAG tutorial looks like this:

\n
    \n
  1. Chunk documents
    2. \n
  2. Embed chunks with OpenAI
    3. \n
  3. Store in a vector DB
    4. \n
  4. At query time, embed the question, find nearest neighbors, send to LLM
    5. \n
\n

This works great for queries like \"how does our authentication flow work?\" — questions where semantic similarity matches.

\n

It fails on queries like:

\n\n

For exact matches — codes, IDs, RFC numbers, error messages, function names — you need keyword retrieval. BM25 is the gold-standard algorithm here. Combine BM25 with dense retrieval and you get the best of both worlds.

\n

Step 1: Install LogicGrid​

\n
dotnet add package LogicGrid.Core
dotnet add package LogicGrid.Memory
dotnet add package LogicGrid.Rag
\n

Pull an embedding model:

\n
ollama pull nomic-embed-text
\n

Step 2: A minimal RAG pipeline​

\n
using LogicGrid.Memory.Embeddings;
using LogicGrid.Memory.VectorStores;
using LogicGrid.Rag;

var embedder = new OllamaEmbeddingClient(\"nomic-embed-text\");
var store    = new InMemoryVectorStore();
var pipeline = new RagPipeline(embedder, store);

// Ingest documents — chunked and embedded automatically
await pipeline.IngestAsync(\"./docs/handbook.md\");
await pipeline.IngestAsync(\"./docs/architecture.md\");

// Search
var hits = await pipeline.SearchAsync(
    \"How do I deploy the API to production?\", topK: 5);

foreach (var hit in hits)
    Console.WriteLine($\"[{hit.Score:F3}] {hit.Document.Text.Substring(0, 100)}...\");
\n

That's the entire program. The RagPipeline handles chunking (using a sensible default — split on paragraphs, max ~500 tokens per chunk with overlap), embedding, and storage.

\n

Step 3: Adding generation​

\n

To turn search results into answers, wrap an agent around the pipeline:

\n
using LogicGrid.Core.Agents;
using LogicGrid.Core.Llm;

var llm = LlmClientBase.Ollama(\"llama3.2\");
IAgent agent = new RagAgent(llm, pipeline);

var answer = await agent.RunAsync(
    \"How do I deploy the API to production?\",
    new AgentContext(\"deploy-question\"));

Console.WriteLine(answer);
\n

RagAgent retrieves the top chunks, formats them into a prompt with your question, and calls the LLM. You get a coherent answer with cited sources.

\n

Step 4: Upgrade to hybrid search​

\n

The InMemoryVectorStore does dense retrieval only. For production you want hybrid. LogicGrid's HybridVectorStore is a drop-in replacement:

\n
using LogicGrid.Memory.Search;

var store = new HybridVectorStore(new InMemoryVectorStore());
var pipeline = new RagPipeline(embedder, store);

await pipeline.IngestAsync(\"./docs/handbook.md\");

// Hybrid search: dense + BM25 + RRF fusion
var results = await pipeline.HybridSearchAsync(
    \"What does error code SKU-4421 mean?\", topK: 5);

foreach (var r in results)
{
    Console.WriteLine(
        $\"RRF={r.RrfScore:F4}  dense={r.DenseScore:F3}  sparse={r.SparseScore:F3}\");
    Console.WriteLine($\"  {r.Document.Text.Substring(0, 100)}...\");
}
\n

You'll see scores from both retrievers. Documents that score well on both rank higher than documents that score well on only one. The fusion algorithm is Reciprocal Rank Fusion (RRF) — parameter-free, well-studied, and consistently beats either retriever alone.

\n

What hybrid search actually does​

\n

Under the hood, HybridSearchAsync does this:

\n
    \n
  1. Embeds your query and runs cosine similarity over the vector index — returns the top N candidates by semantic match.
    2. \n
  2. Tokenizes your query and runs BM25 over an inverted index — returns the top N candidates by keyword match.
    3. \n
  3. Combines the two ranked lists using RRF: each document's score is 1/(60 + rank_dense) + 1/(60 + rank_sparse).
    4. \n
  4. Re-sorts by RRF score and returns the top K.
    5. \n
\n

If a document appears in both lists, it gets a substantial boost. If it appears in only one, it can still rank if its position in that list is high.

\n

The implementation is pure C# — no native dependencies, no extra NuGets. See the hybrid search docs for the full math.

\n

Real benchmarks​

\n

We compared dense-only vs hybrid on three query types over a 10,000-document corpus of technical documentation:

\n
Query typeDense only (recall@5)Hybrid (recall@5)
Conceptual (\"how do I X?\")0.820.85
Codes / IDs (\"SKU-4421\")0.210.94
Proper nouns0.400.88
\n

The takeaway: hybrid never hurts on conceptual queries (because the dense retriever still drives those), and it dramatically improves the hard cases.

\n

Step 5: Production considerations​

\n

The in-memory store works fine up to a few hundred thousand vectors. Past that you want a real vector database. LogicGrid's IVectorStore interface is small — wrap your favorite (Qdrant, pgvector, Weaviate, Pinecone) and plug it in:

\n
public sealed class QdrantVectorStore : IVectorStore
{
    public async Task UpsertAsync(VectorDocument doc, CancellationToken ct = default) { /* ... */ }
    public async Task<IList<VectorSearchResult>> SearchAsync(
        float[] query, int topK, float minScore, CancellationToken ct = default) { /* ... */ }
    // ...
}

var store = new HybridVectorStore(new QdrantVectorStore(...));
\n

HybridVectorStore wraps any IVectorStore and adds BM25 indexing on top. You get hybrid retrieval over your existing vector DB without rewriting anything.

\n

Step 6: Chunking strategies that matter​

\n

The default chunker splits on paragraphs and merges to ~500 tokens. That's a reasonable starting point but rarely optimal. Things to consider:

\n\n

LogicGrid lets you swap chunking strategies via IChunkingStrategy. See the chunking docs for built-in options and how to write your own.

\n

Step 7: Evaluation​

\n

The hardest part of RAG isn't building it — it's knowing whether it's any good. A simple eval set goes a long way:

\n
var evalQuestions = new (string Question, string ExpectedDocId)[]
{
    (\"How do I deploy?\", \"deployment.md#prod\"),
    (\"What is SKU-4421?\", \"errors.md#sku-4421\"),
    // ...
};

int hits = 0;
foreach (var (q, expected) in evalQuestions)
{
    var results = await pipeline.HybridSearchAsync(q, topK: 5);
    if (results.Any(r => r.Document.Id == expected))
        hits++;
}

Console.WriteLine($\"Recall@5: {(double)hits / evalQuestions.Length:P0}\");
\n

Run this on every change to your chunking, embedding model, or retrieval strategy. You'll catch regressions before users do.

\n

Going further​

\n\n

If you're new to LogicGrid, the Quickstart gets you running in five minutes.

\n

For a comparison with other .NET frameworks, see LangChain vs Semantic Kernel vs LogicGrid.

", "url": "https://logicgrid.dev/blog/build-a-rag-pipeline-in-csharp", "title": "Build a RAG Pipeline in C# — From Zero to Hybrid Search", "summary": "A practical walkthrough for building a production-grade RAG pipeline in C#. Document loading, chunking, embeddings, vector storage, and hybrid search with BM25 + dense retrieval.", "date_modified": "2026-04-01T00:00:00.000Z", "author": { "name": "LogicGrid Team", "url": "https://logicgrid.dev" }, "tags": [ "rag", "csharp", "dotnet", "embeddings", "hybrid-search", "tutorial" ] }, { "id": "https://logicgrid.dev/blog/how-to-use-ollama-with-csharp", "content_html": "

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.

\n

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.

\n

Why Ollama from C#?​

\n

Three real reasons teams choose this path:

\n
    \n
  1. Data privacy. Your prompts and responses never leave your network. Critical for regulated industries.
    2. \n
  2. Cost. No per-token billing. A single GPU server can serve thousands of requests per day.
    3. \n
  3. Latency. No round-trip to OpenAI's data centers. For interactive applications, sub-50ms first-token latency matters.
    4. \n
\n

The trade-off: smaller models, more infrastructure to manage, and a steeper learning curve around prompt engineering for less-capable models. For many use cases — summarization, classification, extraction, simple chatbots — that trade-off is worth it.

\n

Step 1: Install Ollama​

\n
# macOS / Linux
curl -fsSL https://ollama.ai/install.sh | sh

# Windows
# Download from https://ollama.ai/download
\n

Pull a model:

\n
ollama pull llama3.2
\n

Verify it works:

\n
ollama run llama3.2
> Hello
Hello! How can I help you today?
\n

By default, Ollama listens on http://localhost:11434.

\n

Step 2: Talk to it from C# — the hard way​

\n

Ollama exposes an HTTP API. You can hit it directly:

\n
using System.Net.Http;
using System.Net.Http.Json;
using System.Text.Json;

var http = new HttpClient { BaseAddress = new Uri(\"http://localhost:11434\") };

var request = new
{
    model = \"llama3.2\",
    prompt = \"What is the capital of France?\",
    stream = false
};

var response = await http.PostAsJsonAsync(\"/api/generate\", request);
var json = await response.Content.ReadAsStringAsync();

using var doc = JsonDocument.Parse(json);
var answer = doc.RootElement.GetProperty(\"response\").GetString();
Console.WriteLine(answer);
\n

This works, but you're now in the business of:

\n\n

For a one-off script that's fine. For anything that ships, you want a library.

\n

Step 3: The easy way​

\n

LogicGrid provides a unified C# API across Ollama, OpenAI, Anthropic, Gemini, and any OpenAI-compatible endpoint. The Ollama integration is first-class, not an afterthought.

\n
dotnet add package LogicGrid.Core
\n
using LogicGrid.Core.Agents;
using LogicGrid.Core.Llm;

var llm = LlmClientBase.Ollama(\"llama3.2\");

IAgent agent = new Agent<string>(
    name: \"Helper\",
    description: \"A helpful assistant.\",
    systemPrompt: \"Answer the user concisely.\",
    llm: llm);

var result = await agent.RunAsync(
    \"What is the capital of France?\", new AgentContext(\"ask\"));

Console.WriteLine(result);
\n

That's the entire program. Three using statements, four logical lines.

\n

Working with full responses​

\n

RunAsync returns the complete LLM response once it's ready. For chat UIs that want tokens to appear progressively, you can drop down to the LlmClientBase directly and use the underlying chat-completion APIs the framework exposes — see the provider docs for the streaming patterns each provider supports.

\n

For most non-interactive workloads (summarization, classification, batch jobs) RunAsync is what you want.

\n

Embeddings​

\n

Ollama can generate embeddings using models like nomic-embed-text or mxbai-embed-large. These are useful for semantic search, RAG, clustering — anything where you need a vector representation of text.

\n
ollama pull nomic-embed-text
\n
using LogicGrid.Memory.Embeddings;

var embedder = new OllamaEmbeddingClient(\"nomic-embed-text\");

float[] vector = await embedder.EmbedAsync(
    \"The quick brown fox jumps over the lazy dog.\");

Console.WriteLine($\"Vector length: {vector.Length}\");
// 768 for nomic-embed-text
\n

The same embedder plugs into LogicGrid's RAG pipeline:

\n
var pipeline = new RagPipeline(embedder, new InMemoryVectorStore());
await pipeline.IngestAsync(\"./docs/manual.txt\");
var hits = await pipeline.SearchAsync(\"how do I configure SSL?\", topK: 3);
\n

See the Build a RAG pipeline in C# guide for the full pattern.

\n

Tool calling​

\n

Ollama-hosted models can use tools — functions you define in C# that the LLM decides to call when relevant. This is how you build agents that can hit your database, query an API, or read a file.

\n
using System.ComponentModel;
using LogicGrid.Core.Agents;
using LogicGrid.Core.Llm;
using LogicGrid.Core.Tools;

public class WeatherArgs
{
    [Description(\"Name of the city to look up weather for.\")]
    public string City { get; set; } = string.Empty;
}

public sealed class WeatherTool : ToolBase<WeatherArgs>
{
    public override string Name => \"get_weather\";
    public override string Description =>
        \"Returns the current weather for a city.\";

    public override Task<string> ExecuteAsync(
        WeatherArgs args, CancellationToken ct = default)
    {
        // Call your real weather API here
        return Task.FromResult(
            $\"Weather in {args.City}: 18°C, partly cloudy.\");
    }
}

var llm = LlmClientBase.Ollama(\"llama3.2\");

IAgent agent = new Agent<string>(
    name: \"WeatherBot\",
    description: \"Tells the user the weather.\",
    systemPrompt: \"Use tools when asked about weather.\",
    llm: llm,
    tools: new ToolBase[] { new WeatherTool() });

Console.WriteLine(await agent.RunAsync(
    \"What's the weather in Berlin?\", new AgentContext()));
\n

LogicGrid auto-generates the JSON schema for each tool from the typed args class — you don't hand-write schema definitions.

\n

Gotcha: not every Ollama model supports tool calling well. Stick to recent models from Meta (llama3.2, llama3.3) or Mistral (mistral-nemo) for reliable function calling. Older or smaller models will hallucinate tool arguments.

\n

Production gotchas nobody tells you​

\n

1. The first request after a cold start is slow​

\n

Ollama keeps models in memory after first use, but the first request loads the model from disk — that can take 30+ seconds for a 7B model. Send a tiny warm-up request when your service starts:

\n
await llm.CompleteAsync(\"ping\", maxTokens: 1);
\n

2. Concurrent requests on a single GPU don't help​

\n

Ollama serves one request at a time per model on the GPU. Sending 10 concurrent requests doesn't make them go faster — they queue. If you need throughput, run multiple Ollama instances behind a load balancer or use vLLM (which supports continuous batching).

\n

3. Context windows lie​

\n

llama3.2 advertises 128k context. In practice quality degrades sharply past 8k–16k. Don't shovel huge documents in raw — chunk and retrieve.

\n

4. Model versions move​

\n

ollama pull llama3.2 pulls the latest tag, which can change. Pin a specific digest in production:

\n
ollama pull llama3.2:3b-instruct-q4_K_M
\n

5. JSON mode is unreliable on small models​

\n

Tell llama3.2:3b to return JSON and you'll get JSON 95% of the time. The other 5% will be markdown-wrapped JSON, JSON with trailing commentary, or garbage. Always validate and parse defensively.

\n

LogicGrid's typed agents handle this — you specify Agent<T> with a structured output type and the framework retries with corrective prompts on parse failure.

\n

When Ollama is not the right answer​

\n

Ollama is great for development, on-prem deployment, and small-scale production. It is not great when:

\n\n

LogicGrid handles all of these — same code, different LlmClientBase.* factory call.

\n

Next steps​

\n\n

If you're evaluating frameworks, the Semantic Kernel alternative post covers the trade-offs in more depth.

", "url": "https://logicgrid.dev/blog/how-to-use-ollama-with-csharp", "title": "How to Use Ollama with C# — A Production-Ready Guide", "summary": "A complete walkthrough for running local LLMs from C# using Ollama. Covers setup, streaming, tool calling, embeddings, and the gotchas nobody tells you about.", "date_modified": "2026-03-26T00:00:00.000Z", "author": { "name": "LogicGrid Team", "url": "https://logicgrid.dev" }, "tags": [ "ollama", "csharp", "dotnet", "local-llm", "llama", "tutorial" ] }, { "id": "https://logicgrid.dev/blog/semantic-kernel-alternative-for-dotnet", "content_html": "

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.

\n

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.

\n

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.

\n

Where Semantic Kernel shines​

\n

Let's start with what Semantic Kernel does well, because it's a lot:

\n\n

If your team is already invested in the Microsoft cloud and you're building features that look like \"summarize this Word doc\" or \"search our SharePoint,\" Semantic Kernel is probably the right tool.

\n

Where teams start looking elsewhere​

\n

1. Local LLMs are a second-class citizen​

\n

Semantic Kernel can talk to Ollama. It can talk to LM Studio. But the developer experience is built around hosted APIs — Azure OpenAI, OpenAI, Anthropic — and local providers feel bolted on.

\n

This matters for a growing number of teams:

\n\n

If your roadmap includes local LLMs as a peer of hosted ones — not a fallback — you'll feel the friction.

\n

2. The runtime is heavy​

\n

Add Semantic Kernel to a small console app and watch the dependency tree light up. The framework pulls in a lot — telemetry, ML.NET, abstractions on top of abstractions. For a CRUD API that wants to summarize a paragraph, that's a lot of surface area.

\n

It also makes auditing harder. If you need to ship to a customer who reads SBOMs, every transitive package is a question to answer.

\n

3. Observability is opt-in, not built-in​

\n

Want to know how many tokens an agent run consumed? Want to trace exactly which tool was called and when? Want a structured event log of every retry, every fallback, every LLM call?

\n

You can get there with Semantic Kernel — by hooking OpenTelemetry, configuring listeners, and writing some glue code. But it's not the default. Most teams don't bother until something goes wrong in production, and then they're scrambling.

\n

For teams who've been burned by black-box AI behavior in production, observability-by-default is non-negotiable.

\n

What an alternative looks like​

\n

LogicGrid is a .NET-native multi-agent framework that takes a different posture on each of those three points. It's not better at everything — it's optimized for a different set of constraints.

\n

Local LLMs are first-class​

\n
// Same agent. Any provider. Zero code change.
var llm = LlmClientBase.Ollama(\"llama3.2\");
// var llm = LlmClientBase.OpenAI(\"gpt-4o\");
// var llm = LlmClientBase.Anthropic(\"claude-sonnet-4-6\");
// var llm = LlmClientBase.Gemini(\"gemini-2.0-flash\");

IAgent agent = new Agent<string>(
    name: \"Summariser\",
    description: \"Summarises any text concisely.\",
    systemPrompt: \"Summarise the following in 2-3 sentences: {{input}}\",
    llm: llm);

var result = await agent.RunAsync(
    \"Long document text...\", new AgentContext(\"run-1\"));
\n

Switching from Ollama to Claude is a one-line change. Streaming, tool calling, and embeddings work the same way across every provider. There's no \"OpenAI is the real path; Ollama is the demo path.\"

\n

Zero hidden runtime dependencies

\n

LogicGrid targets netstandard2.0, net6.0, and net8.0. The full SBOM is published as bom.json in the public repo. The only thing you're pulling in is what's strictly needed.

\n

For air-gapped deployments, that matters: you can audit the entire dependency graph before the package touches your build server.

\n

Observability by default​

\n

Every agent step, tool call, retry, and LLM call emits a structured event:

\n
var ctx = new AgentContext()
    .WithLogging()
    .WithTracing(out var trace);

await agent.RunAsync(\"Hello\", ctx);

// trace contains every step, tool call, retry, and LLM call
foreach (var span in trace.Spans)
    Console.WriteLine($\"{span.Name} — {span.Duration.TotalMilliseconds:F0}ms\");
\n

You don't have to opt into telemetry. You opt out if you don't want it.

\n

Migration considerations​

\n

If you're considering moving from Semantic Kernel to LogicGrid, the conversion is generally straightforward — both frameworks model the same concepts (agents, tools, memory) but with different APIs. The biggest mental shift is around orchestration: Semantic Kernel encourages a \"planner\" mindset where the LLM decides the workflow; LogicGrid encourages explicit graphs where you decide the workflow and the LLM fills in the steps.

\n

Neither approach is wrong — but if you've been frustrated by Semantic Kernel planners going off-script, LogicGrid's graph orchestration will feel like a relief.

\n

When not to switch​

\n

If any of these are true, stick with Semantic Kernel:

\n\n

LogicGrid is a better fit when:

\n\n

Try it in 5 minutes​

\n
dotnet add package LogicGrid.Core
ollama pull llama3.2
\n
using LogicGrid.Core.Agents;
using LogicGrid.Core.Llm;

var llm = LlmClientBase.Ollama(\"llama3.2\");

IAgent agent = new Agent<string>(
    name: \"Helper\",
    description: \"Answers questions concisely.\",
    systemPrompt: \"Answer in one short sentence.\",
    llm: llm);

var result = await agent.RunAsync(
    \"What is the capital of France?\", new AgentContext(\"run-1\"));

Console.WriteLine(result);
\n

That's it. No appsettings.json ritual, no SDK initialization dance, no API keys (until you want to use a hosted provider).

\n

If you've been frustrated with Semantic Kernel's posture toward local LLMs or its dependency weight — give LogicGrid 30 minutes. If it doesn't fit, you'll know quickly. If it does, the quickstart walks you through the next steps.

\n
\n

Want a deeper comparison? The follow-up post LangChain vs Semantic Kernel vs LogicGrid goes feature-by-feature across all three frameworks.

", "url": "https://logicgrid.dev/blog/semantic-kernel-alternative-for-dotnet", "title": "A Semantic Kernel Alternative for .NET — When and Why You'd Reach for One", "summary": "Microsoft Semantic Kernel is the default agent framework for .NET. Here's an honest look at where it shines, where it struggles, and what an alternative built around local LLMs and observability looks like.", "date_modified": "2026-03-15T00:00:00.000Z", "author": { "name": "LogicGrid Team", "url": "https://logicgrid.dev" }, "tags": [ "dotnet", "csharp", "semantic-kernel", "ai-agents", "llm", "comparison" ] } ] }