AUGUST 2026 \u00b7 ~7 MIN READ \u00b7 .NET \u00b7 AGENTIC AI<\/p>\n
Who Picks the Next Step – You<\/span> or the LLM<\/span>?<\/h1>\nI built two agent apps in .NET before I understood they weren’t the same thing. This is what I learned – and how you can build either one without rebuilding halfway through.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n\n\nKey takeaway<\/p>\n
Before you pick Semantic Kernel or roll your own pipeline, answer one question: who picks the next step – your code or the LLM?<\/strong><\/p>\nKnown stages and fixed order \u2192 you own the flow (pipeline). Open-ended user messages \u2192 the model picks tools (Semantic Kernel). I learned that the hard way by building both.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
![\"Pipeline](\"https:\/\/tothenewco.pro\/blog\/wp-ttn-blog\/uploads\/2026\/08\/sticky-notes-comparison-1.png\")
<\/p>\n
\n\n\n\nIt started with a simple goal: I wanted an AI that could take a rough product idea and turn it into something useful – requirements, architecture, a code plan, a review. The kind of output a small software team might produce over a week, but in minutes.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
I didn’t start by picking a framework. I started by asking: who decides what happens next?<\/em><\/p>\nThat question turned out to matter more than the model, the hosting, or the UI. I only wish I’d written it down before I shipped the first app – because I ended up building twice.<\/p>\n
How I decide now (before opening Visual Studio)<\/h2>\n
After building both apps, I sketch the same four questions. Your answers point you to one pattern – not both.<\/p>\n
\n\n\nQuestion<\/th>\n You pick (pipeline)<\/th>\n LLM picks (tool-calling)<\/th>\n<\/tr>\n<\/thead>\n \n\nUser input<\/td>\n One idea in, staged deliverables out<\/td>\n Conversation – intent changes every message<\/td>\n<\/tr>\n \nOrder of work<\/td>\n Fixed: PO \u2192 Architect \u2192 Dev \u2192 Review<\/td>\n Model chooses tools per turn<\/td>\n<\/tr>\n \nWhat you write<\/td>\n Agent classes + one chain method<\/td>\n Plugins with [KernelFunction]<\/code> descriptions<\/td>\n<\/tr>\n\nStack I used<\/td>\n Plain C#, IAIProvider<\/code>, SignalR<\/td>\nSemantic Kernel, ChatCompletionAgent<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nNeither column is “better.” They answer different product questions. The expensive mistake is picking SK vs plain C# before you know who’s holding the baton.<\/p>\n
\n\n\n<\/td>\n \nThe first build: I became the conductor<\/h2>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
For the pipeline app, I mapped out the work the way a real team would. Product Owner first. Then Architect. Then Developer. Then Reviewer. The order wasn’t negotiable – requirements before design, design before code, code before review.<\/p>\n
\n\n\n\nPipeline mental model:<\/strong> Product Owner \u2192 Architect \u2192 Developer \u2192 Reviewer. Fixed order. You own the choreography.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nEach agent became a C# class with a role and a prompt. They share a base that handles the LLM call and pushes status to the browser through SignalR:<\/p>\n
\n\n\nBaseAgent.cs – the pattern every agent shares<\/td>\n<\/tr>\n \nprotected async Task<string> Execute(string prompt)
\n{
\nawait _logger.Log($”\ud83e\udd16 {_name}: Thinking…”);
\nvar result = await _ai.Ask(prompt);
\nawait _logger.Log($”\u2705 {_name}: Done”);
\nreturn result;
\n}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nThe Product Owner agent wraps your idea in instructions and sends it to the model. The Architect gets the requirements. The Developer gets the architecture. Nobody sees the full picture – just the handoff from the agent before them.<\/p>\n
Then I wired them together. If you’re building a pipeline agent, this is where you live:<\/p>\n
![\"Pipeline](\"https:\/\/tothenewco.pro\/blog\/wp-ttn-blog\/uploads\/2026\/08\/pipeline-flow-1.png\")
<\/p>\n
\n\n\nOpenAIWorkflowEngine.cs<\/td>\n<\/tr>\n \npublic async Task<WorkflowResult> RunAsync(string idea)
\n{
\nvar po = new ProductOwnerAgent(_ai, _logger);
\nvar arch = new ArchitectAgent(_ai, _logger);
\nvar dev = new DeveloperAgent(_ai, _logger);
\nvar rev = new ReviewerAgent(_ai, _logger);var req = await po.Run(idea);
\nvar architecture = await arch.Run(req);
\nvar code = await dev.Run(architecture);
\nvar review = await rev.Run(code);return new WorkflowResult { Requirements = req, Architecture = architecture, Code = code, Review = review };
\n}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nEarly on I chained the agents with .Result<\/code> inside an async method. That worked until it didn’t – blocked threads, messy logs, hard-to-debug hangs. Switching to await<\/code> all the way through was a small change that made SignalR updates actually behave.<\/p>\nI plugged in OpenRouter behind an IAIProvider<\/code> interface, registered everything in Program.cs<\/code>, and added SignalR so users could watch each agent light up. The app went live at pipeline-based-multiagent-ai-6w7n.onrender.com<\/a>.<\/p>\nIt worked. Type an idea, get a four-part software blueprint. I controlled the choreography completely – and that was the point. Where it fell short was anything conversational. There is no “step two” when the user sends a sentence that mixes three intents.<\/p>\n
\n\n\n\nI wasn’t building an agent. I was building an assembly line – and I was the foreman.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n\n<\/td>\n \nThe second build: I handed over the baton<\/h2>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Then I wanted something different. Not a workflow with a fixed end. A chatbot that could check symptoms, look up medication, book appointments, set reminders, check weather – depending on what the user actually said.<\/p>\n
A pipeline didn’t fit. I couldn’t hardcode “step one: symptoms, step two: booking” because users don’t talk in steps. They talk in sentences.<\/p>\n
So I picked up Semantic Kernel – and the mental model flipped.<\/p>\n
\n\n\n\nThe shift<\/p>\n
Instead of writing the flow, I wrote capabilities<\/strong> – C# methods the LLM could call when it needed them. I stopped being the conductor. I became the toolbox builder.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nMediBot started with a Kernel – SK’s object that connects your model to your tools:<\/p>\n
\n\n\nHealthcareAgentService.cs<\/td>\n<\/tr>\n \nvar builder = Kernel.CreateBuilder();
\nbuilder.AddOpenAIChatCompletion(
\nmodelId: “deepseek\/deepseek-chat”,
\napiKey: apiKey,
\nendpoint: new Uri(“https:\/\/openrouter.ai\/api\/v1”),
\nhttpClient: httpClient);
\nvar kernel = builder.Build();
\nkernel.Plugins.AddFromType<HealthcarePlugin>(“Healthcare”);<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nEach tool is a method with a name and a description. The LLM reads those descriptions and decides when to call them – you don’t write routing logic:<\/p>\n
\n\n\nHealthcarePlugin.cs<\/td>\n<\/tr>\n \n[KernelFunction(“check_symptoms”)]
\n[Description(“Analyzes reported symptoms and returns possible conditions.”)]
\npublic string CheckSymptoms(
\n[Description(“Comma-separated symptoms, e.g. ‘fever, headache'”)]
\nstring symptoms)
\n{
\n\/\/ your logic here
\nreturn $”Based on symptoms ‘{symptoms}’, possible conditions include: ” +
\n$”{string.Join(“, “, unique)}.”;
\n}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nGive the agent a persona, attach the kernel, and invoke it with conversation history:<\/p>\n
\n\n\nthe loop that runs on every message<\/td>\n<\/tr>\n \n_agent = new ChatCompletionAgent
\n{
\nName = “MediBot”,
\nInstructions = “You are MediBot, a compassionate healthcare assistant…”,
\nKernel = kernel
\n};
\nvar thread = new ChatHistoryAgentThread(chatHistory);
\nawait foreach (var message in _agent.InvokeAsync(thread))
\nresponseBuilder.Append(message.Message.Content);<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n![\"Tool-calling](\"https:\/\/tothenewco.pro\/blog\/wp-ttn-blog\/uploads\/2026\/08\/tool-calling-flow-1.png\")
<\/p>\n
\n\n\n\ud83d\udcac<\/td>\n \n“I have fever and body ache, find hospitals near Mumbai”<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
MediBot might call check_symptoms<\/code>, then find_nearby_hospitals<\/code>, then write a single friendly reply. I didn’t plan that sequence. The model did.<\/p>\nThe part that took iteration wasn’t the C# – it was the tool descriptions and system prompt. Vague descriptions meant the model called the wrong plugin or skipped one entirely. I built Aria the same way (different plugin, different instructions, same pattern). Both went live at agentic-ai-yihx.onrender.com<\/a>.<\/p>\n
\n\n\n\nI stopped writing if\/else. I started writing small methods and trusting the model to pick the right one.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n\n<\/td>\n \nThe question that ties them together<\/h2>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Same language – “agent.” Same stack – .NET, Razor Pages, OpenRouter. Completely different answer to one question:<\/p>\n
\n\n\n\nWho picks the next step?<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n![\"Sticky](\"https:\/\/tothenewco.pro\/blog\/wp-ttn-blog\/uploads\/2026\/08\/you-vs-llm-comparison-2.png\")
<\/p>\n
\n\n\n\nYou pick<\/span><\/p>\nPO \u2192 Architect \u2192 Developer \u2192 Reviewer. Every time. One class per role, one chain method, LLM behind an interface. Plain C# – no framework required.<\/p>\n<\/td>\n
<\/td>\n \nLLM picks<\/span><\/p>\nKernel + plugins with [KernelFunction]<\/code> + ChatCompletionAgent<\/code>. You write capabilities; SK runs the loop.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nNeither is better. They answer different questions.<\/p>\n
Your process has known stages<\/strong> \u2192 build a pipeline. You own the flow.<\/p>\nYour users bring unpredictable requests<\/strong> \u2192 build tool-calling agents. You own the capabilities.<\/p>\nWhat took me too long to accept: you have to choose upfront. You can’t bolt a pipeline onto a chatbot or vice versa without rethinking who holds the baton.<\/p>\n
What I’d build next (honestly)<\/h2>\n
I haven’t shipped a third app yet. If I did, it would probably mix both patterns – a fixed outer flow (intake, draft, review) with tool-calling inside each stage, so the model has room to move but can’t skip a human approval before something important goes out.<\/p>\n
For now, the lesson from two live demos is simpler: pick who owns the next step on day one. Everything else – SK vs plain C#, OpenRouter vs something else – is easier once that’s clear.<\/p>\n
Key takeaway<\/p>\n
Before you pick Semantic Kernel or roll your own pipeline, answer one question: who picks the next step – your code or the LLM?<\/strong><\/p>\n Known stages and fixed order \u2192 you own the flow (pipeline). Open-ended user messages \u2192 the model picks tools (Semantic Kernel). I learned that the hard way by building both.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n It started with a simple goal: I wanted an AI that could take a rough product idea and turn it into something useful – requirements, architecture, a code plan, a review. The kind of output a small software team might produce over a week, but in minutes.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n I didn’t start by picking a framework. I started by asking: who decides what happens next?<\/em><\/p>\n That question turned out to matter more than the model, the hosting, or the UI. I only wish I’d written it down before I shipped the first app – because I ended up building twice.<\/p>\n After building both apps, I sketch the same four questions. Your answers point you to one pattern – not both.<\/p>\n Neither column is “better.” They answer different product questions. The expensive mistake is picking SK vs plain C# before you know who’s holding the baton.<\/p>\n For the pipeline app, I mapped out the work the way a real team would. Product Owner first. Then Architect. Then Developer. Then Reviewer. The order wasn’t negotiable – requirements before design, design before code, code before review.<\/p>\n Pipeline mental model:<\/strong> Product Owner \u2192 Architect \u2192 Developer \u2192 Reviewer. Fixed order. You own the choreography.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Each agent became a C# class with a role and a prompt. They share a base that handles the LLM call and pushes status to the browser through SignalR:<\/p>\n The Product Owner agent wraps your idea in instructions and sends it to the model. The Architect gets the requirements. The Developer gets the architecture. Nobody sees the full picture – just the handoff from the agent before them.<\/p>\n Then I wired them together. If you’re building a pipeline agent, this is where you live:<\/p>\n Early on I chained the agents with I plugged in OpenRouter behind an It worked. Type an idea, get a four-part software blueprint. I controlled the choreography completely – and that was the point. Where it fell short was anything conversational. There is no “step two” when the user sends a sentence that mixes three intents.<\/p>\n I wasn’t building an agent. I was building an assembly line – and I was the foreman.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Then I wanted something different. Not a workflow with a fixed end. A chatbot that could check symptoms, look up medication, book appointments, set reminders, check weather – depending on what the user actually said.<\/p>\n A pipeline didn’t fit. I couldn’t hardcode “step one: symptoms, step two: booking” because users don’t talk in steps. They talk in sentences.<\/p>\n So I picked up Semantic Kernel – and the mental model flipped.<\/p>\n The shift<\/p>\n Instead of writing the flow, I wrote capabilities<\/strong> – C# methods the LLM could call when it needed them. I stopped being the conductor. I became the toolbox builder.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n MediBot started with a Kernel – SK’s object that connects your model to your tools:<\/p>\n Each tool is a method with a name and a description. The LLM reads those descriptions and decides when to call them – you don’t write routing logic:<\/p>\n Give the agent a persona, attach the kernel, and invoke it with conversation history:<\/p>\n “I have fever and body ache, find hospitals near Mumbai”<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n MediBot might call The part that took iteration wasn’t the C# – it was the tool descriptions and system prompt. Vague descriptions meant the model called the wrong plugin or skipped one entirely. I built Aria the same way (different plugin, different instructions, same pattern). Both went live at agentic-ai-yihx.onrender.com<\/a>.<\/p>\n I stopped writing if\/else. I started writing small methods and trusting the model to pick the right one.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Same language – “agent.” Same stack – .NET, Razor Pages, OpenRouter. Completely different answer to one question:<\/p>\n Who picks the next step?<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n You pick<\/span><\/p>\n PO \u2192 Architect \u2192 Developer \u2192 Reviewer. Every time. One class per role, one chain method, LLM behind an interface. Plain C# – no framework required.<\/p>\n<\/td>\n LLM picks<\/span><\/p>\n Kernel + plugins with Neither is better. They answer different questions.<\/p>\n Your process has known stages<\/strong> \u2192 build a pipeline. You own the flow.<\/p>\n Your users bring unpredictable requests<\/strong> \u2192 build tool-calling agents. You own the capabilities.<\/p>\n What took me too long to accept: you have to choose upfront. You can’t bolt a pipeline onto a chatbot or vice versa without rethinking who holds the baton.<\/p>\n I haven’t shipped a third app yet. If I did, it would probably mix both patterns – a fixed outer flow (intake, draft, review) with tool-calling inside each stage, so the model has room to move but can’t skip a human approval before something important goes out.<\/p>\n For now, the lesson from two live demos is simpler: pick who owns the next step on day one. Everything else – SK vs plain C#, OpenRouter vs something else – is easier once that’s clear.<\/p>\n<\/p>\n\n\n
\n \n How I decide now (before opening Visual Studio)<\/h2>\n
\n\n
\n \nQuestion<\/th>\n You pick (pipeline)<\/th>\n LLM picks (tool-calling)<\/th>\n<\/tr>\n<\/thead>\n \n User input<\/td>\n One idea in, staged deliverables out<\/td>\n Conversation – intent changes every message<\/td>\n<\/tr>\n \n Order of work<\/td>\n Fixed: PO \u2192 Architect \u2192 Dev \u2192 Review<\/td>\n Model chooses tools per turn<\/td>\n<\/tr>\n \n What you write<\/td>\n Agent classes + one chain method<\/td>\n Plugins with [KernelFunction]<\/code> descriptions<\/td>\n<\/tr>\n\n Stack I used<\/td>\n Plain C#, IAIProvider<\/code>, SignalR<\/td>\nSemantic Kernel, ChatCompletionAgent<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n\n
\n <\/td>\n \n The first build: I became the conductor<\/h2>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n
\n \n \n\n
\n BaseAgent.cs – the pattern every agent shares<\/td>\n<\/tr>\n \n protected async Task<string> Execute(string prompt)
\n{
\nawait _logger.Log($”\ud83e\udd16 {_name}: Thinking…”);
\nvar result = await _ai.Ask(prompt);
\nawait _logger.Log($”\u2705 {_name}: Done”);
\nreturn result;
\n}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/p>\n\n\n
\n OpenAIWorkflowEngine.cs<\/td>\n<\/tr>\n \n public async Task<WorkflowResult> RunAsync(string idea)
\n{
\nvar po = new ProductOwnerAgent(_ai, _logger);
\nvar arch = new ArchitectAgent(_ai, _logger);
\nvar dev = new DeveloperAgent(_ai, _logger);
\nvar rev = new ReviewerAgent(_ai, _logger);var req = await po.Run(idea);
\nvar architecture = await arch.Run(req);
\nvar code = await dev.Run(architecture);
\nvar review = await rev.Run(code);return new WorkflowResult { Requirements = req, Architecture = architecture, Code = code, Review = review };
\n}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n.Result<\/code> inside an async method. That worked until it didn’t – blocked threads, messy logs, hard-to-debug hangs. Switching to await<\/code> all the way through was a small change that made SignalR updates actually behave.<\/p>\nIAIProvider<\/code> interface, registered everything in Program.cs<\/code>, and added SignalR so users could watch each agent light up. The app went live at pipeline-based-multiagent-ai-6w7n.onrender.com<\/a>.<\/p>\n\n\n
\n \n \n\n
\n <\/td>\n \n The second build: I handed over the baton<\/h2>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n
\n \n \n\n
\n HealthcareAgentService.cs<\/td>\n<\/tr>\n \n var builder = Kernel.CreateBuilder();
\nbuilder.AddOpenAIChatCompletion(
\nmodelId: “deepseek\/deepseek-chat”,
\napiKey: apiKey,
\nendpoint: new Uri(“https:\/\/openrouter.ai\/api\/v1”),
\nhttpClient: httpClient);
\nvar kernel = builder.Build();
\nkernel.Plugins.AddFromType<HealthcarePlugin>(“Healthcare”);<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n
\n HealthcarePlugin.cs<\/td>\n<\/tr>\n \n [KernelFunction(“check_symptoms”)]
\n[Description(“Analyzes reported symptoms and returns possible conditions.”)]
\npublic string CheckSymptoms(
\n[Description(“Comma-separated symptoms, e.g. ‘fever, headache'”)]
\nstring symptoms)
\n{
\n\/\/ your logic here
\nreturn $”Based on symptoms ‘{symptoms}’, possible conditions include: ” +
\n$”{string.Join(“, “, unique)}.”;
\n}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n
\n the loop that runs on every message<\/td>\n<\/tr>\n \n _agent = new ChatCompletionAgent
\n{
\nName = “MediBot”,
\nInstructions = “You are MediBot, a compassionate healthcare assistant…”,
\nKernel = kernel
\n};
\nvar thread = new ChatHistoryAgentThread(chatHistory);
\nawait foreach (var message in _agent.InvokeAsync(thread))
\nresponseBuilder.Append(message.Message.Content);<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/p>\n\n\n
\n \ud83d\udcac<\/td>\n \n check_symptoms<\/code>, then find_nearby_hospitals<\/code>, then write a single friendly reply. I didn’t plan that sequence. The model did.<\/p>\n\n\n
\n \n \n\n
\n <\/td>\n \n The question that ties them together<\/h2>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n
\n \n <\/p>\n\n\n
\n \n <\/td>\n \n [KernelFunction]<\/code> + ChatCompletionAgent<\/code>. You write capabilities; SK runs the loop.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWhat I’d build next (honestly)<\/h2>\n