DEV Community: logicgrid-dev

Introducing LogicGrid — Multi-Agent AI Orchestration for .NET

logicgrid-dev — Sun, 24 May 2026 21:36:37 +0000

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.

Why multi-agent?
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.

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

Research — needs broad context, can use tools, ok to be slow
Writing — needs focused context, ok to be fast, no tools needed
Fact-checking — needs verifying mindset, can use tools, narrow context
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.

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

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

Latency — each agent is an LLM call. Three agents means 3x the wall-clock time.
Cost — same math, 3x the tokens.
Failure modes — any agent in the chain can fail or hallucinate, and downstream agents have to handle it.
Debugging complexity — when something goes wrong, which agent caused it?
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.

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

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

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");

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

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

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

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

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

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

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?");

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

Parallel + Map-Reduce Run multiple agents in parallel and aggregate results.

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

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

Reflexion (self-critique) 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.

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

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

How to choose a pattern
Start by asking: what does my problem actually look like as a flowchart?

One step? You don't need multi-agent.
A linear sequence of steps? Sequential.
Steps that depend on what previous steps said, in a non-deterministic way? Group chat.
Steps with branches and merges? Graph.
Multiple independent perspectives that combine? Parallel + aggregate.
One step but you want it to be really, really good? Reflexion.
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.

Observability — the part nobody talks about
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?

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.

LogicGrid does this by default:

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");

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.

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

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

Mix model sizes. Use a small fast model for orchestration decisions and a large model only for the actual work.
Cache aggressively. Many multi-agent flows have agents that produce the same output for the same input. Cache at the agent boundary.
Run independent steps in parallel. Sequential is the worst case; parallel is free latency.
Run local for orchestration. Local LLMs (Ollama, vLLM) are essentially free per call. Use them for the cheap routing decisions and reserve hosted models for the heavy lifting.
LogicGrid makes all four easy because providers are interchangeable in one line.

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

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

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.

Going further
Orchestration patterns — sequential, group chat, graph, parallel, map-reduce, reflexion
Observability— events, logging, tracing
Quickstart— build your first multi-agent system

A Semantic Kernel Alternative for .NET — When and Why You'd Reach for One

logicgrid-dev — Sun, 03 May 2026 05:09:22 +0000

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.

Where Semantic Kernel shines

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

Azure-native. If your stack is already Azure OpenAI + Azure AI Search + App Service, Semantic Kernel snaps into place with minimal ceremony.
First-party support. It's a Microsoft project. That alone reduces procurement friction in enterprise environments.
Plugins ecosystem. The plugin model is well-documented and Microsoft has shipped a steady stream of integrations.
Backed by serious R&D. The team behind Semantic Kernel has poured real engineering into kernel orchestration, planners, and prompt templating.

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.

Where teams start looking elsewhere

1. Local LLMs are a second-class citizen

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.

This matters for a growing number of teams:

Regulated industries — banks, healthcare, defense — that can't ship customer data to OpenAI's servers
Cost-sensitive products that need to handle high request volumes without paying $0.001 per call
Edge deployments running on customer hardware with no internet connection
Air-gapped enterprises where any outbound traffic is a security incident

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

2. The runtime is heavy

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.

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

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

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?

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.

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

What an alternative looks like

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.

Local LLMs are first-class

// 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"));

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

Zero hidden runtime dependencies

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

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

Observability by default

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

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");

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

Migration considerations

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.

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.

When not to switch

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

Your stack is fully on Azure and you use Azure OpenAI exclusively
You need first-party Microsoft support contracts
Your team has already invested significant tooling and training in Semantic Kernel
You're building primarily for Microsoft 365 / Copilot integration

LogicGrid is a better fit when:

Local LLMs are part of your roadmap, not a side note
You ship to enterprises who scrutinize dependencies
You want observability without writing your own telemetry layer
You're targeting older .NET versions (.NET Framework 4.7.2+ via netstandard2.0)

Try it in 5 minutes

dotnet add package LogicGrid.Core
ollama pull llama3.2

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

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

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.

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