At the end of Part 1, I had IronClaw running on EC2, connected to Slack, with 28 tools registered — 8 of them from a Synthesis MCP server backed by 155 indexed files. The architecture looked correct. The logs said "connected." The tool list confirmed registration.
So I sent it a task.
IronClaw is the internal AI agent I run for eXOReaction. It sits on an EC2 instance, connected to Slack via a Python Socket Mode bridge, and answers questions from the team. The underlying model is kimi-k2.5 via OpenRouter. It is fast and capable, and it has no idea who we are.
Most writing about AI agents is aspirational. Autonomous systems that plan, reason, and execute complex workflows end-to-end. The vision is compelling. The reality, after building and running agents in production across multiple projects, is more mundane and more useful. The patterns that survive contact with real workloads are not the clever ones. They are the simple ones that fail in predictable ways.
What follows are five architectural decisions that made the difference between agents that reliably complete tasks and agents that confidently fail. None of them are universal. Each has a specific context where it works and a specific context where it does not. I have learned both sides, sometimes expensively.