Practical write-ups on building AI systems that survive production: ingestion pipelines, multi-agent orchestration, RAG at scale, and modernization.
Most teams default to buying, or default to building, and both defaults are wrong some of the time. A concrete framework for when a custom agent earns its cost and when it does not.
As agents start calling other agents and tools across systems, the attack surface stops looking like a normal web app. What actually goes wrong when agents talk to each other, and the defenses that hold up in production.
An AI agent is not a chatbot with a better prompt. A plain explanation of what actually makes something an agent, the loop that drives it, and where it fits next to RAG and a simple LLM call.
You cannot improve a RAG system you cannot measure. How to build an evaluation set, what to score (retrieval and generation separately), and how to keep it honest over time.
For regulated work, sending prompts to a hosted model API is often not an option. Here is what it actually takes to run useful LLM systems inside your own boundary: model hosting, retrieval, and evaluation that never phone home.
Multi-agent demos are easy. Multi-agent systems that run reliably need shared memory that is actually safe to share, a single trace across every agent, and clear rules for when control passes. The prompts are the easy part.
RAG and fine-tuning solve different problems. A decision guide: use RAG for knowledge, fine-tuning for behavior, and start with RAG almost every time.
A production ingestion pipeline is what makes retrieval-augmented generation reliable. Here is the architecture we use: normalize every format into one schema, embed on ingest, and keep the whole run replayable.
Not every repetitive task is a good automation target, and picking wrong is how AI projects stall. A concrete filter for choosing which workflows to hand to an agent.
A plain explanation of RAG: what it is, when it beats a plain LLM call or fine-tuning, and the parts of it that actually decide whether it works.
A practical migration path from .NET Framework to modern .NET: assess, port the class libraries, replace the framework-only pieces, and cut over incrementally behind a compatibility layer.
The warning signs that a legacy .NET Framework application is costing you more than a modernization would: crashes, security alerts, hiring friction, cloud blockers, and rising maintenance spend.
The real question is not what modernization costs up front. It is what you pay every year by not doing it: rising maintenance, security exposure, opportunity cost, and a talent premium.
Proven approaches for migrating legacy databases during a .NET modernization: strangler, blue-green, phased migration, and continuous sync. Chosen to minimize risk and protect data integrity.
A decision framework for hosting a modernized .NET application: where cloud wins, where on-premise still makes sense, and why a hybrid model fits many regulated organizations.
How a failing legacy .NET Framework claims-processing system was stabilized within 48 hours, then put on a path to .NET 8. The assessment, the hotfixes, and the results.