The Earned Complexity Principle
TRIGGER
Teams default to building sophisticated multi-step agentic systems because they seem more capable, without validating that the complexity actually improves outcomes. Frameworks make it easy to add abstraction layers that obscure what's happening and make debugging harder.
APPROACH
Anthropic's most successful customer implementations follow a complexity ladder: start with the augmented LLM (single LLM call plus retrieval and in-context examples), then add workflows only when measurements show improvement. Input: task requirements and success criteria. Output: the simplest architecture that meets requirements. The progression is: (1) single LLM calls with retrieval, (2) workflows like prompt chaining, routing, or parallelization when needed, (3) full agents only when workflows are insufficient for open-ended problems. When using frameworks like LangChain or Rivet, teams must understand the underlying code—incorrect assumptions about what's under the hood are a common source of customer errors. Many patterns that seem to need frameworks actually require only a few lines of direct API calls.
PATTERN
“Each abstraction layer in an LLM system multiplies latency and cost while obscuring debugging—unlike traditional code where abstractions are essentially free. Earn complexity through measurement: add workflows only when single calls demonstrably fail, agents only when workflows are insufficient.”
✓ WORKS WHEN
- You have evaluation infrastructure to measure whether added complexity improves outcomes
- Task requirements are well understood so you know what 'better' means
- Latency and cost constraints allow experimentation with simpler approaches first
- Team has capacity to iterate and compare multiple implementation approaches
✗ FAILS WHEN
- Task inherently requires multi-step orchestration from day one (complex file edits across repository)
- No clear metrics exist to compare simple vs complex implementations
- Time pressure forces picking an architecture before validating alternatives
- Domain expertise strongly indicates a specific pattern is needed (don't A/B test obvious requirements)