Writing

If you have ever built an agent that dazzled in a demo and then came apart the first time it touched something real, you already know the problem this article is about.

When it falls apart, the reflex is to blame the model. Once in a while that is fair. Far more often the model was fine and the layer around it was not. The context it got was stale, a tool handed back garbage, a command ran somewhere it should not have, or a confident final answer went out with nobody checking whether it was true.

I have been working in managed cloud hosting for about seven years. In that time, I have built a few production AI systems that handle real customer conversations and diagnose server issues. One of them handles about 30% of incoming conversations on its own. Another cut investigation time for complex server issues from 30 minutes down to about 8 minutes.

When I picked up Lakshmanan and Hapke’s Generative AI Design Patterns (O’Reilly, 2025), I wanted to see how many of their 32 patterns mapped to what I want to build next: a context-aware AI hosting support agent that can answer informational questions, debug complex server issues, and suggest application code optimizations for speed and security. 28 of the 32 patterns apply. The other four don’t, either because they require self-hosted models, add cost without proportional benefit, or belong to a separate system that is out of scope for what we are building here.

I build AI agents that run in production: a server diagnostics agent with SSH access, a conversation QA evaluator, and a signup verification system that collects threat intelligence. They handle real data every day.

The longer I do this, the more I notice a pattern. The problems have nothing to do with model capability. The models are great and getting better every quarter. My problems are all in the space between the model and the real world. And I do not think they go away with GPT-6 or Gemini 4 or whatever comes next.