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). Measured 2026-08-28, and the advice needs a qualifier (how-many-tools-should-an-agent-see, Meta, T1): on BFCL's 370 pooled tools a learned policy matches a fixed shortlist of 50 while showing 7.4 tools on average — so "minimal" is right, and the right minimum is per query, not a constant. On ToolBench's 3,251 tools the same design inverts: a shortlist of five wins on aggregate coverage and finds nothing where the correct tool ranks 6th–20th, which the adaptive agent recovers 16.7% of. Aggregate accuracy and hard-case accuracy move in opposite directions, so any single number about how many tools an agent should see is answering only one of them.
• 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