Q&A
Developing Agentic Systems in .NET: From Concept to Code
In the rush to add AI to applications, it has been easy to mistake a chatbot for an agent. But as enterprises move beyond conversational interfaces, the real architectural question is no longer simply how to get a model to answer a prompt. It is how to build systems that can perceive context, make plans, call tools, maintain state, collaborate with other agents and operate safely inside production environments.
That shift is the focus of Developing Agentic Systems in .NET: From Concept to Code, an intermediate-to-advanced session at Visual Studio Live! San Diego 2026 set for September. Presented by Alon Fliess, founder of ZioNet, the session is designed to help .NET developers understand what it really means to build agentic systems rather than just AI-powered chat experiences.
"The first shift developers need to make is understanding the difference between using agentic development tools, like Copilot, Claude, or Codex, and building agentic systems."
Alon Fliess, Founder, ZioNet
For Fliess, the key distinction is that chatbots talk, while agents act. That seemingly simple difference introduces a much larger design challenge. Agentic systems are probabilistic, not deterministic, which means they require guidance, validation, guardrails, identity controls, memory boundaries and operational oversight. They also need to connect safely to APIs, databases and local systems, often through deterministic tools that complement the reasoning capabilities of large language models.
The session will walk attendees through that architecture using C# and the Microsoft Agent Framework, moving from an agent's "brain" -- reasoning loops, memory and state management -- to its "hands," where function calling and the Model Context Protocol connect agents to external capabilities. From there, Fliess will explore how developers can move from a single agent to coordinated multi-agent teams using patterns such as group chat and handoffs, and then into production concerns such as hosting, observability, governance and enterprise security.
The result is a session aimed less at AI hype and more at practical software architecture: how to decide where agent state should live, how to keep tool integration maintainable, when to use ASP.NET Core, Azure Functions or Microsoft Agent Service, and why agent identity may be one of the first security questions development teams need to answer.
We caught up with Fliess to discuss the mindset shift from chatbots to agents, how the "Perception → Planning → Action" loop maps to real C# systems, and what .NET developers should understand before building autonomous software that can act on behalf of users and organizations.
VisualStudioMagazine: What inspired you to present on this topic?
Fliess: Whenever a new technology emerges, especially in its earliest, not-yet-fully-baked stages, I like to step back and understand its deeper meaning: the concepts, the real impact, and how it will actually be used months down the line. I usually experiment early, build proofs of concept, and explore scenarios that only become mainstream later. I followed the same path with AI and agentic systems, building agents back when we only had raw LLM APIs and no supporting frameworks.
What I've consistently seen since then is that many developers struggle with a fundamental shift in thinking. Agentic systems are inherently probabilistic; they behave more like humans than traditional software. Like humans, they need guidance, guardrails, validation, and oversight. They can also make mistakes. The real power of agentic systems comes from combining these LLM-based agents with deterministic code, tools, and data, knowing when to rely on each and how to connect them safely.
For me, an agent is a new kind of microservice: powerful, flexible, but not fully predictable. That means we must design systems that instruct, evaluate, validate, and supervise agents, sometimes with humans in the loop, sometimes with agents guarding other agents. Architecting solutions that remain stable while the underlying AI technology evolves rapidly is a real challenge, and that challenge is exactly what inspired this session.
What is the biggest mindset shift .NET developers need to make when moving from chatbot-style apps to true agentic systems?
The first shift developers need to make is understanding the difference between using agentic development tools, like Copilot, Claude, or Codex, and building agentic systems. These tools help developers write code, but they are not the same as designing systems where agents reason, plan, choose actions, and collaborate over time.
The second shift is understanding the fundamentals of how agentic systems actually work. An agent is not a single LLM call. Frameworks such as the Microsoft Agent Framework orchestrate multiple LLM interactions by carefully shaping context and giving the model explicit choices: return a final answer, ask a clarification question, invoke a tool, call a skill via MCP, or even delegate work to another agent. When the model returns structured output, the framework fulfills that intent by executing tools, chaining actions, and managing the flow.
Using an agentic framework eliminates a lot of low-level plumbing and lets developers focus on architecture rather than on prompt wiring. But to do that effectively, developers must clearly understand the roles of each component: the model, the agentic framework, the tools, and any extensions. Once that mental model clicks, agentic systems become far more predictable, testable, and maintainable.
In your session, how do you translate the 'Perception -> Planning -> Action' loop into practical C# architecture?
One important thing I emphasize in the session is that the classic "Perception -> Planning -> Action" loop looks different depending on the type of agent you're building. There isn't a single universal implementation; there are several distinct architectural patterns.
The first type is a self-contained agent. These agents are typically event-driven: they're triggered by an external signal, extract information from the event, gather additional context through tool calls, and then produce either an action or a state change. In this case, the loop is compact and focused, and maps cleanly to a single unit of responsibility in C#.
The second type is an agent that participates in a workflow. Here, each agent has a specific role, intent, and bounded context. The overall solution emerges from the orchestration of multiple specialized agents, each using the most appropriate model and tools for its task. This approach not only improves clarity and reliability but can also reduce costs, because focused agents require fewer tokens and simpler prompts than a single "do-everything" agent.
The third type is a human-like agent or agentic system, designed to behave more like a team member. These agents can respond to multiple triggers, operate across channels such as Teams, Slack, Copilot, and WhatsApp, and maintain identity, permissions, and continuity over time. In these cases, the agent loop becomes more sophisticated, with long-lived state, access control, and richer perception mechanisms.
So when we talk about implementing the agent loop in C#, the key takeaway is that it must be shaped by the agent's role and context. The architecture reflects whether the agent is reactive, collaborative, or persistent, and that's what turns the abstract loop into a production-ready design.
What part of building the agent's 'Brain' tends to be the hardest to get right in real code, reasoning, memory, or state management?
State management is usually the hardest, and not just technically but conceptually. To get it right, developers first need to clearly define the agent's scope and identity, much as they would for a microservice.
Some agents are short-lived, stateless agents. They receive a request with contextual information, call tools to enrich that context, produce an outcome, and then forget everything. These agents scale extremely well. In this model, the "brain" is similar to a microservice's business logic, except that, instead of deterministic code paths, we use the probabilistic reasoning power of an LLM.
The complexity increases with long-running agent interactions, where the agent maintains short-term memory for the duration of a session, similar to how chats in ChatGPT or Gemini work, and often also long-term memory across sessions. Long-term memory introduces difficult design questions: What should be remembered? Who owns that memory? Is it per user, per tenant, per group, or global?
This is where multi-tenancy becomes a critical architectural concern. Memory might belong to a single user, a team, or an entire organization, and that directly affects isolation, privacy, access control, and cost. Getting these boundaries wrong leads to unpredictable behavior or serious security risks.
So while reasoning and prompting can usually be improved incrementally, state and memory require deliberate architectural decisions up front. Defining an agent's identity, lifespan, memory ownership, and tenancy boundaries ultimately makes an agent reliable in real production systems.
What is one example of how MCP helps keep agent-to-tool integration cleaner or more maintainable?
Tooling in agentic systems can take many shapes and forms. For example, frameworks such as the Microsoft Agent Framework allow developers to register local functions as tools. Other frameworks define tools as scripts, markdown files, or skills, different representations, but conceptually the same idea.
From the LLM's perspective, all of these tools are exposed through the prompt as structured descriptions. The model sees a "menu" of capabilities and can choose whether to produce a final answer, ask for clarification, or invoke a specific tool.
MCP fits naturally into this model. Each registered MCP server dynamically contributes its own set of tools and prompts, enriching the agent's context. You can think of it as adding new dishes to the LLM's menu, without rewriting the agent itself. MCP also allows servers to explain how their tools should be used, guiding the model toward correct behavior.
What makes MCP especially powerful is its dynamism and separation of concerns. Servers can be added or removed at runtime, tools can live remotely or locally, and the protocol defines how the agent and the tools interact. Some MCP servers can even call back into the LLM using sampling, almost like attaching a robotic arm that receives both power and instructions from the robot's brain.
In that sense, MCP acts as a plugin mechanism for agentic systems: a standardized way to extend an agent with new capabilities while keeping integration clean, maintainable, and loosely coupled.
When an agent needs to interact with APIs, databases, or local systems, what security concern should developers think about first?
The first and most important concern is identity. Like any piece of code running in a system, an agent has an identity, either implicitly, based on where it's hosted, or explicitly, if we choose to manage it properly. That identity defines security boundaries, access rules, and auditability.
One common approach is to let the agent act using the delegated identity of the calling user. In this model, the agent operates on behalf of the user and can access anything the human user is allowed to access. While simple, this creates a serious problem: when you later examine audit logs, it becomes very difficult to distinguish which actions were performed by a human and which were initiated by an agent.
A more robust approach is to give each agent its own identity, with the minimum required privileges to perform its role. The agent becomes a first-class principal in the system, just like a service account or an application identity. This enables clear separation of duties, precise permissions, and clean audit trails.
Managing agents the same way we manage users or services provides the highest level of security and governance. Platforms such as Microsoft Agent Service / Agent 365 help enforce this model by providing a built-in governance layer for identity, access control, and observability. This approach makes agentic systems safer, more traceable, and far easier to operate at enterprise scale.
What is the key architectural difference between building a single capable agent and orchestrating a multi-agent team with handoffs or group chat?
Modern LLMs are extremely capable; there are very few individual questions or tasks they cannot technically handle. So a natural question arises: why not build a single powerful agent that does everything?
The answer lies in focus, reliability, and control. A single "mighty" agent is often overloaded with context, responsibilities, and tools. That leads to larger prompts, higher costs, slower responses, and, most importantly, a greater chance of confusion or incoherent results. Dedicated agents, on the other hand, are focused. Each agent operates with a smaller, more relevant context, uses the most appropriate model and tools for its domain, and produces more consistent outcomes.
Breaking a system into multiple agents also unlocks different orchestration patterns. In a pipeline-based flow, agents execute in a predefined order, providing predictability and repeatability, ideal for structured, deterministic processes. In contrast, a group-chat or collaborative model allows agents to participate without a strict sequence, exchanging ideas and refining solutions together. This makes it easier to recover from dead ends, revisit earlier reasoning, or explore alternatives dynamically.
Each orchestration style yields different behaviors and outcomes. Pipelines emphasize control and structure; group chats emphasize adaptability and exploration. Choosing between them, or combining both, is an architectural decision, not a tooling detail.
Ultimately, multi-agent systems trade raw power for clarity and correctness. By designing agents with clear roles and well-defined collaboration patterns, architects can build systems that are faster, cheaper, easier to reason about, and far more robust in real-world scenarios.
How do you decide whether to host a stateful agent in ASP.NET Core, Azure Functions, or Microsoft Agent Service?
Like any hosting decision, it starts with understanding the quality attributes your system requires, lifecycle, scalability, identity, observability, and state management. Historically, when new technologies emerge, we tend to host them on familiar platforms simply because those are the tools we already have. But over time, as patterns stabilize, dedicated hosting models emerge to better support the unique needs of that technology.
Agentic systems are no exception.
ASP.NET Core, whether running as a web app, in containers, on Azure Container Apps, or AKS, works well when you need full control, custom pipelines, or long-running services. Azure Functions are a good fit for reactive, event-driven agents with short execution paths and clear triggers. Both are valid options, but neither was originally designed specifically for agentic workloads.
Agentic systems introduce new requirements: managed agent identity, long-running state and memory, reinvocation, traceability across reasoning steps, human-in-the-loop patterns, and orchestration across agents and workflows. As these needs became clearer, dedicated hosting models began to emerge.
Microsoft Agent Service is an example of such a host. It is designed with agent-specific concerns in mind: identity management using application-only or on-behalf-of models with Entra ID, built-in governance and auditing, memory and state handling, reinvocation support, workflow coordination, and observability. Instead of retrofitting these capabilities onto a general-purpose host, the platform provides them as first-class features.
So the decision isn't about which option is "best" in general, it's about fit. Existing hosts work well when you need simplicity or maximum control. A dedicated agent host makes sense when agent identity, governance, lifecycle management, and long-running behavior are core requirements rather than afterthoughts.
How can attendees learn more about this topic and prepare for your session?
Attendees don't need prior experience building agentic systems, but they will get the most value if they come with a solid understanding of .NET fundamentals and an open mind about new architectural patterns. Familiarity with asynchronous programming, APIs, and basic AI concepts is helpful, but not required.
In the session, I focus on practical architecture, real trade-offs, and production-oriented thinking, not theoretical AI research. I'll walk through concrete examples and patterns developers can apply immediately, whether they're experimenting with agents or planning enterprise-grade systems.
For preparation, I recommend following current discussions on agentic systems, tools, and orchestration models, and considering how AI might fit into real systems beyond chat. The goal of the session is to help attendees leave with a clear mental model and a concrete starting point for building agentic systems responsibly and effectively in .NET.
Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $400 by registering by the July 17 Super Early Bird Savings deadline!" said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.