Building AI Agents? Here Are Some Anti-Patterns to Avoid
Machine Learning Mastery (Bala Priya C): a nine-item checklist of agent-building anti-patterns. Its value here isn’t a new idea — it’s that an independent practitioner list lands almost one-to-one on the spoke’s synthesis threads, so it works as a compact failure-mode index and outside corroboration. Cites Anthropic’s Building Effective Agents, OpenAI’s agent guide, Google Cloud eval, and MongoDB memory patterns. T3 — educational roundup, no original data.
The nine, mapped to the spoke
- Multi-agent too soon & one agent doing everything (15+ tools) → start with one agent, narrow scope, add agents only when data proves it — the “start simple, workflows before agents” rule and the structure-over-capability discipline.
- Tool-list sprawl (more tools → more bad choices + prompt bloat) → minimal, non-overlapping tools. The tool-count face of context bloat (cf. Breunig’s confusion).
- Hardcoded monolithic logic → prompts in config files, modular tools, composable agents — the compose-from-single-concern-pieces and externalize-the-spec moves.
- Skipping memory architecture → layered session / long-term (vectors) / logs — directly agent-memory (and its durability/auditability split).
- Shipping without observability → structured logging + distributed tracing from line one; the clearest
seam to
../platform-ops-wiki(verification needs a runtime signal). - Ungoverned write access → separate read/write, validate outputs, human confirm high-stakes — verbatim agent-guardrails (reversibility/human-checkpoints).
- Context drift in long tasks → clear stale outputs, paginate, cap tool-output size — verbatim content-rot governance (the prune/offload levers).
- Deploying without evaluation → adversarial + edge-case tests, metrics tied to business outcomes — the verification-is-the-bottleneck thread and the spoke’s standing Benchmarks gap.
Why it matters here
It’s a second outside-in corroboration of the layer model after EvoMap: where EvoMap taxonomizes the field, this enumerates the failure modes, and both independently reproduce the spoke’s structure (start-simple / guardrails / memory / context-rot / verification). No new node — it strengthens existing ones and is a handy checklist to hang them on. The one mild tension: it recommends layered memory + observability + eval as near-defaults, i.e. more structure up front, which sits against its own lead anti-pattern (“don’t over-engineer / multi-agent too soon”) — the perennial start-simple ↔ build-the-scaffolding balance the spoke keeps circling.
Related
building-effective-agents · agent-guardrails · constraint-evading-behavior · context-rot · agent-memory · agent-middleware · loop-engineering · agent-orchestration · awesome-agent-evolution · bala-priya-c