Agentic Simplicity

The thesis of agent engineering: find the simplest solution possible and add complexity only when it demonstrably improves outcomes. The most successful production agent systems are built from simple, composable patterns, not complex frameworks. For many applications a single optimized LLM call (with retrieval and in-context examples) is enough — agentic systems trade latency and cost for task performance, so the tradeoff has to actually pay.

The corollary for frameworks: they help you start by hiding low-level plumbing (LLM calls, tool parsing, chaining), but the same abstraction layers obscure the underlying prompts and responses, make debugging harder, and tempt you to add complexity a simpler setup wouldn't need. Start from the LLM API directly; if you adopt a framework, understand what it does underneath — incorrect assumptions about what's under the hood are a common source of error.

Claims

Find the simplest solution possible; add complexity only when it demonstrably improves outcomes. principle — durable: the whole discipline reduces to spending complexity only where it earns its keep against measured results.
Success is building the right system, not the most sophisticated one. principle — durable: sophistication is not a goal; fit to the need is.
Agentic systems trade latency and cost for task performance — only pay when the tradeoff makes sense. observation — a factual property of agentic designs that frames the build/don't-build decision.
Start from the LLM API directly; adopt a framework only with understanding of its internals. best practice — context: teams moving from prototype to production; framework abstraction obscures prompts/responses and invites premature complexity, so the "best" default is minimal abstraction until a concrete need justifies more.
Measure performance and iterate — add multi-step agentic machinery only when simpler solutions fall short. principle — durable: complexity decisions are gated on evidence, not intuition; this is the same measure-don't-vibe discipline the eval graph insists on.
More agents, more autonomy, and more compute do not always mean better outcomes — the simplicity discipline extends to team size, not just call count. principle — durable: parallelism without coordination adds cost and error surface, not capability. A second source (IndyDevDan, "anti-hype agentic coding") frames this as the antidote to "slop engineering and vibe coding" — stay close to the fundamentals of the agent, don't bolt on autonomy for its own sake. See Agent Task Graph.
Complexity climbs with sophistication, but capability does not automatically — climb only for a pain you actually feel ("no pain, no climb"). principle — durable: a third source (Nate Herk, on second brains) reaches the same rule for retrieval architecture — higher Retrieval Maturity Levels cost complexity, not capability, so "most people should land at 1–3" and only move up when a felt pain point demands it. Same discipline as "add complexity only when it demonstrably improves outcomes," applied to storage/retrieval.
The majority of tasks don't need an agent loop — reach for the loop only for the verification/iteration it buys, and prefer one terminal session + a good prompt over a massive multi-agent architecture. principle — durable: the same source (Nate Herk, on agent loops) applies the simplicity thesis to loop machinery — a "solo loop" beats a swarm for most work, and 24/7 fleets of agents-prompting-agents scale problems, not capability, if you don't understand what you're doing. See Agent Loop, Loop Engineering.
The Claude Code team started with a vector database, then dropped it for grep + agentic search because it performed better and was easier to maintain. observation — a fourth, independent source (Damian Galarza, on OpenClaw memory search) corroborates "no pain, no climb" in the concrete: the fancier Retrieval Maturity Levels level (a vector DB) lost to the plainer one (keyword/grep) on both quality and maintenance cost. Complexity climbed; capability didn't. See Hybrid Retrieval.
The same discipline holds at the prompt level: for a capable model, a short instruction steers as well as an exhaustive rulebook, and "act when you have enough" beats option-surveying. principle — durable: a fifth source (Nate Herk, on prompting Fable 5) reaches "simplest thing that works" for prompts — over-prescriptive prompts can degrade output, and endless deliberation burns budget on choices never used. See Concise Prompting, Reasoning Effort Control.
Don't over-engineer a personal system — the only genuinely wrong choice is overthinking the small ones; "action produces information," so favour reps over planning and delete any piece that isn't making it better. principle — durable: a sixth source (Austin Marchese, on building a Self-Improving System) applies the simplicity thesis to operating a system — folder names and run times "just don't matter," systems "sharpen through reps, not whiteboard sessions," and you should cut components that don't earn their place. Same "add complexity only when it demonstrably improves outcomes," aimed at the operator's own machinery.
The discipline needs a pre-flight procedure, not just a disposition: estimate the work's shape before choosing machinery, and let "no AI at all" be a first-class verdict. best practice — context: an operator facing a specific task, where "default small and justify the climb" is sound but under-determined. A seventh source (Nate B Jones) supplies the missing step — four estimates (size, independence, separation of concerns, checkability) run in about a minute, yielding chat / one agent / a team / nothing (Agent-Shape Triage). It sharpens this page's "sometimes the right answer is not to build an agentic system at all" from an aside into an outcome you can land on, and states the failure mode this cluster keeps circling: "I'm the last person to suggest a multi-agent solution where you don't need one. The trick is you might need one." Contingent on the estimate being cheap — a careful analysis would cost more than guessing wrong.
"More agents ≠ better" is about roster size, not about attempts — the two dials behave differently and conflating them inverts this page's lesson. principle — durable, and a necessary boundary on this page's most-quoted claim. Retries against a mechanical checker scale smoothly in a way agent count does not; the simplicity discipline argues against unjustified parallelism, not against persistence. See Repeated-Sampling Scaling, Bounded Fan-Out.

Workflows vs Agents — the first fork of "how much complexity": often the answer is a workflow, or no agentic system at all.
Agentic Workflow Patterns — the composable building blocks you reach for before full autonomy.
The Augmented LLM — the minimal unit; frequently a single augmented call is the whole "simplest solution."
Eval-Driven Development — "add complexity only when it demonstrably improves outcomes" is the same "don't trust vibes; measure" discipline, applied to architecture decisions.
Agent Task Graph — "more agents ≠ better"; coordination structure, not agent count, is what buys the gain.
Retrieval Maturity Levels — "no pain, no climb" up the retrieval ladder is this simplicity thesis applied to knowledge storage.
Loop Engineering — "does this apply to you?" — adopting loops is itself a triage judgment; don't cargo-cult the loudest example.
Agent-Shape Triage — this disposition turned into a procedure: the four estimates that decide, on a specific task, which operating point (including none) the simplicity thesis actually implies.
Team-Forming Constraints — the positive criterion behind "more agents ≠ better": the two limits (capacity, separation of concerns) that justify a team at all. A roster answering neither is the unjustified complexity this page warns against.
Repeated-Sampling Scaling — the boundary on "more ≠ better": attempts against a verifier do scale, so the simplicity discipline is about roster size, not persistence.
Distillate: Building Effective Agents.
Distillate: Claude Code Task System: Orchestrating a Team of Agents Through a Task Graph.
Distillate: Every Level of a Claude Second Brain Explained.
Distillate: Finally. Agent Loops Clearly Explained. — loop engineering, decoded for the rest of us — corroborates from the agent-loop angle: most tasks don't need a loop; prefer a solo loop over a swarm.
Distillate: How AI Agents Search Their Memory — Hybrid Retrieval, in Practice (OpenClaw) — corroborates from the retrieval angle: Claude Code dropped a vector DB for grep because simpler won on quality and maintenance.
Distillate: How Anthropic Engineers Actually Prompt Fable 5 — six habits for a smarter, lighter touch — corroborates from the prompt angle: "say less, not more" and "act when you have enough" for a capable model.
Distillate: How to Build a Self-Improving System with Claude Code — corroborates from the personal-system angle: "run it, don't over-engineer it; action produces information."
Distillate: Building Great Agent Skills: The Missing Manual — corroborates from the skill-authoring angle: keep SKILL.md minimal and prune no-ops (delete anything that doesn't change behavior). See Minimal Skill Surface, Skill Pruning.
Distillate: 1.6M agents registered for OpenClaw and did NOTHING. — supplies the pre-flight procedure this page lacked, promotes "no AI at all" to a first-class verdict, and draws the attempts-vs-agents boundary on "more ≠ better."
Distillate: You're the Problem, Not Claude — Six Fixes to 10x Output — corroborates from the process-design angle (Marchese again): "don't treat everything like a nail," and Elon's five steps (question → delete → simplify → augment → automate) with "the most common error of a smart engineer is to optimize the thing that should not exist" — delete before you build.

Agentic Simplicity

Claims

Related

Linked from