Agentic .NET is a publication about building production AI agents on the .NET stack — the Microsoft Agent Framework, Semantic Kernel, the Model Context Protocol, retrieval pipelines, and what it takes to run any of it reliably on Azure and Google Cloud.
It exists because most writing about AI agents stops at the demo. The tutorial ends exactly where the interesting part begins: the retry that silently bills you twice, the tool schema that quietly degrades selection accuracy once you pass a dozen tools, the streaming endpoint that works on localhost and buffers behind a proxy in production. Every article here is written to carry on past that point.
Who writes it
Everything on this site is written, tested and reviewed by Manikandhan Balakrishnan, a principal engineer & technical architect with more than fifteen years designing and shipping cloud-native .NET microservices platforms on Google Cloud and Azure. That work has included sizeable Kubernetes estates running Istio, and messaging backbones built on Kafka and MQTT — the kind of systems where an outage is measured in revenue rather than embarrassment.
That experience has been earned in architect roles at large multinationals, including Harman International, Accenture and Shell — environments where systems carry real traffic, real budgets and real compliance obligations, and where an architectural decision has to survive contact with an organisation rather than just a code review. Much of what appears here is shaped by that: the articles tend to care about cost, failure modes and operability, because those are the things that decide whether a system survives its second year.
The current focus is the point where .NET meets AI: building agents that call real tools against real systems, and keeping them accurate, observable and affordable once they are serving live traffic. This is not a side interest written up from documentation. It is the day job, written down.
Video versions of some of these guides are on Mani Tech Universe on YouTube.
How these articles are written
Every article follows the same process, and it is worth stating plainly, because it is the reason to trust what you read here.
- Code is run, not imagined. Sample code is compiled and executed against the SDK version named in the article before it is published. Where an article quotes a response body, an error message or an error code, that output came from a real call rather than from memory.
- API surfaces are checked against primary sources. Method signatures, package names and defaults are verified against the vendor's own documentation or the XML documentation shipped inside the NuGet package — the only source guaranteed to match the assembly you will actually reference.
- Versions and dates are stated. This ecosystem moves fast enough that advice without a version number is close to useless. Where behaviour is specific to a release, the release is named.
- Uncertainty is marked as uncertainty. Where sources genuinely disagree — pricing, benchmarks, contested figures — the article says so instead of picking the most convenient number and presenting it as settled.
- Trade-offs are included, and so is "don't". Most articles end with the cases where the approach is the wrong choice. A guide that can only recommend its own subject is marketing, not engineering writing.
Corrections
Technical writing goes stale, and some of it is wrong on the day it is published. If code in an article no longer compiles, a version number has moved, or an explanation is simply incorrect, please tell me. Corrections take priority over new articles.
Independence
This site carries advertising and may contain affiliate links, both disclosed in the privacy policy and the terms. No vendor pays for coverage, for a review or for a recommendation, and no article is sent to a vendor before publication. Guest posts, paid links and sponsored placements are not accepted.
Tools are recommended here because they were used on real work. Where something is a poor fit — including products from the same vendors covered positively elsewhere on the site — the articles say so.
Get in touch
Questions, corrections and topic suggestions are welcome. See the contact page, or email mani.bc72@gmail.com directly.