About
Production AI Field Notes is about the engineering that starts after the demo works.
Most AI writing stops at the impressive part. A model answers a hard question, a retrieval pipeline returns something relevant, an agent finishes a multi-step task, and the post ends there. The problems worth writing about begin one step later: the request that fails, the document that went stale six weeks ago, the tool call that should never have been permitted, the bill that quietly tripled.
These notes are about that second half.
A complete series, not a feed
Most writing in this space arrives as weekly one-offs. Useful, but you cannot learn a domain from a stream of disconnected posts.
This is built the other way round. Sixty posts, in order, from what a language model actually is, through retrieval and RAG, into agents and multi-agent systems, and out the far side into tracing, evaluation, security and governance. Ten chapters, six posts each, each one a short read built around a single production decision.
Eight specialist tracks go deeper on the areas that need more than one post: MCP, agent infrastructure, production RAG, evaluation, safety engineering, multi-agent design, architecture patterns, and operations.
Read it in sequence if you are starting out. Jump to the chapter matching whatever is currently on fire if you are not. Start Here lays out all sixty.
Who writes this
I am Vamsi Krishna Annamreddy, an enterprise AI architect. I build agentic platforms for organisations that need AI to be dependable, auditable, and actually shipped.
Three of those are in production: an enterprise agentic AI platform, where I led the team and shipped alongside them; an enterprise MCP gateway, as sole architect and developer; and a self-service support assistant, where satisfied sessions ended without a case being filed at all. The stack behind them is LangGraph, Azure OpenAI, Azure AI Search, MCP, Databricks, Postgres and TypeScript. I also handle Claude administration across the organisation.
Everything here comes out of that work. When I write that retrieval permissions are an architecture problem rather than a filter, it is because I have watched the filter version fail.
How the notes are written
Each note takes a single production decision and works through it. What usually breaks, why the obvious fix often makes things worse, and what a team can realistically do about it on a Tuesday afternoon.
They are short on purpose. A few minutes, one idea, no attempt at completeness. There is no vendor angle. Where a specific tool genuinely matters I name it; where the choice does not matter, I say that instead.
Getting in touch
If one of these notes changes how you build something, I would genuinely like to hear about it. If you think one is wrong, I would like to hear that more. Corrections get made and credited.