Orchestration Sediment Anti-Patterns

Pillar: sediment-patterns | Date: April 2026
Scope: Custom orchestration sediment: what heavy orchestration builders deleted and why. Specific patterns: AI strategic planner personas, multi-agent debate systems (Tribunal-style), tool-profile abstractions, knowledge graphs nobody queries, skills loaded into context but never invoked, commands mirroring native functionality, hooks firing on every event with no observable behavior change, write-only databases. Net deletion stories — what practitioners tore down, what they kept, and why.
Sources: 65 gathered, consolidated, synthesized.

Table of Contents

1. The Sediment Accumulation Mechanism
2. Framework Abstraction Sediment: LangChain / LangGraph Teardowns
3. Multi-Agent Complexity Anti-Patterns
4. Tool Proliferation and MCP / Tool-Profile Bloat
5. Skills Loaded But Never Invoked
6. System Prompt and CLAUDE.md Sediment
7. Zero-Observable-Effect Hooks
8. Write-Only Databases and Memory Systems
9. AI Strategic Planner Personas and Meta-Orchestrators
10. Net Deletion Stories: Metrics and Outcomes

Section 1: The Sediment Accumulation Mechanism

Orchestration sediment is the residue of solutions whose problems have been solved. The defining characteristic is asymmetric growth: additions are triggered by incidents and failures; removals have no trigger at all. Every bad output causes an instruction, guardrail, or wrapper to be added. Good output generates no feedback loop. The result is unbounded accumulation toward zero signal-to-noise ratio.^[11]

Key finding: "If your skill files only ever grow — if you add new guidance whenever something goes wrong but never audit what's already there — context rot is accumulating by default."^[11] The asymmetry is structural: the addition trigger is automatic; the removal trigger does not exist.

The Four Formation Pathways

Platform Absorption: Three Deleted Categories

Between 2024 and 2026, three previously-custom orchestration categories became sediment when their underlying platform shipped native equivalents:^[62]

1. Custom RAG pipelines — absorbed by native document context in Claude Projects and ChatGPT Projects
2. Web search orchestration — absorbed by native search in most LLM services
3. Custom MCP orchestration layers — described as having "a meteoric rise and then fizzled out"

Similarly, developers who built manual context-clearing workflows, external artifact directories (thoughts/ directories), elaborate verbose prompts, and custom session segmentation found all of these absorbed by automatic compaction, native plan mode, and platform session management.^[1]

The Karpathy Principle: Nothing Speculative

The Karpathy principle^[65] provides the core deletion heuristic: speculative abstractions (for imagined futures), speculative features (for potential use cases), and speculative error handlers (for scenarios that have not occurred) are all sediment. They were added for imagined futures that never came; now they consume context without producing value. Deletion criteria: if the scenario the code handles has never occurred in production, the code is speculative sediment.^[43]

Section 2: Framework Abstraction Sediment: LangChain / LangGraph Teardowns

The LangChain exit is the most thoroughly documented net-deletion story in AI orchestration. Multiple independent teams arrived at the same conclusion independently, across different application domains, without coordinating. Each team built on LangChain when it solved a real problem (inconsistent vendor APIs, 2022–2023), then tore it down when that problem disappeared (vendor API convergence, 2025).

Key finding: "The abstraction LangChain provided in 2022 was solving a temporary problem. By 2025, the model providers solved most of it themselves."^[3] Every framework has an expiration date tied to the stability of its underlying problem space.

Documented Deletion Cases

Octomind (raw_31.md)

Octomind eliminated LangChain after 12+ months in production from an AI agent system that used multiple LLMs to automatically create and fix end-to-end tests in Playwright.^[31] The deletion was driven by three specific capability gaps:

• "Rigid high-level abstractions" that became limiting at scale rather than enabling
• Inability to support required capabilities: spawning sub-agents, enabling agent interaction, dynamically adjusting tool availability
• Forced scope reduction: "had to reduce the scope of implementation to fit into the limited functionality available" rather than building what was needed

Abstraction stacking anti-pattern: The framework layers "abstractions on top of other abstractions," forcing developers to navigate "nested abstractions" and debug framework internals. Developers spent "as much time understanding and debugging LangChain as it did building features."^[31] What replaced it: Direct LLM client libraries, carefully selected external packages, simple comprehensible low-level code.

Nathan Cole's Deletion (raw_44.md)

The turning point: "a LangChain agent called a DELETE endpoint I had not intended to expose."^[44] The framework passed LLM tool selection directly to execution without an intervening validation layer. Replacement: 80 lines of Python. The root anti-pattern: LangChain treats LLM outputs as program output; the 2026 pattern treats them as untrusted user input requiring validation.

Ravoid Case Studies (raw_3.md)

Production teams migrating to raw SDKs reported consistent, measurable gains:^[3]

Post-migration outcomes: 70–90% drop in framework incidents, 40–60% code reduction within 2–6 months amortization period.^[3] Observable sediment indicator: Stack traces spanning "15 to 40 frames of internal framework code" — debug signal buried in abstraction layers with no signal value.

AutoGen Deletion (raw_49.md)

An insurance company built a multi-agent conversation system for a training simulator using AutoGen, then deleted the entire system:^[49]

• Agents kept talking without converging on answers
• Debugging required reading pages of generated text
• 5x baseline token consumption
• 3 weeks to implement → deleted entirely, replaced with CrewAI deterministic task sequencing in 1 week

Hacker News Developer Consensus

Community feedback on LangChain identified a consistent anti-pattern:^[4]

• "The second you need to do something a little original you have to go through 5 layers of abstraction just to change a minute detail" (sc077y)
• "Most LLM applications require nothing more than string handling, API calls, loops, and maybe a vector DB if you're doing RAG. You don't need several layers of abstraction." (w4)
• "LangChain isn't usable beyond demos." (tkellogg)
• Developer replaced the entire framework with 80 lines of direct API calls (thefourthchime)

LangChain CEO Harrison Chase acknowledged the structural cause: "The initial version of LangChain was pretty high level and absolutely abstracted away too much."^[4]

What Gets Deleted vs. What Gets Kept

Preferred replacement stack (2026): Vanilla Python + direct SDK + LlamaIndex for retrieval + Pydantic/Instructor for structured output.^[56]

Section 3: Multi-Agent Complexity Anti-Patterns

Multi-agent systems are the single largest source of orchestration sediment because they are the hardest to delete: each agent appears to have a purpose, and decomposing the system requires understanding how agents coordinate. The empirical evidence shows the coordination overhead routinely exceeds the capability benefit.

Key finding: A Google DeepMind study found unstructured multi-agent networks amplify errors "up to 17.2 times compared to single-agent baselines."^[14] A system with 95% per-step success drops to 59.9% reliability across 10 sequential steps and 35.8% across 20 steps.

Quantitative Evidence on Coordination Failure

The Coordination Tax Formula

The net performance calculation for multi-agent systems:^[5]

Net Performance = (Individual Capability + Collaboration Benefits) − (Coordination Chaos + Communication Overhead + Tool Complexity)

Three failure mechanisms materialize when the subtraction side exceeds the addition side:

1. Coordination Tax: Agents spend cognitive resources on tool management rather than problem-solving — measured as 35% performance drop in controlled tests^[5]
2. Capability Saturation: When a single agent can already solve a problem with >45% accuracy, adding more agents delivers diminishing or negative returns^[5]
3. Error Amplification: The 17.2x factor — errors propagate and compound across agent handoffs rather than self-correcting^[14]

Tribunal / Debate System Anti-Patterns

The "Tribunal" pattern — advocate agent + attacker agent + radical agent — is structurally identical to the "Bag of Agents" anti-pattern that produces the 17.2x error amplification: agents interact without enforced contracts or structured topology.^[14]

Specific exotic topologies documented as sediment-generating:^[9]

Key finding on debate systems: "95% of investments in generative AI have produced zero measurable returns" (MIT Media Lab 2025, cited in raw_9.md) due to architectural patterns lacking production foundations — multi-agent debate systems are the leading culprit.^[9]

A Payment Pipeline Deletion Story

From agentpatterns.tech, a documented payment processing pipeline teardown:^[39]

Key metric: "A typical user request triggers 4+ agent handoffs where 1–2 would be enough."^[39] Decision rule for future additions: "Add a new agent only when there is a clear role, measurable value, and explicit ownership boundary."

What Production Systems Actually Look Like

Organizations that successfully deployed multi-agent systems in 2025–2026 deliberately constrained scope:^[5]

• 68% of production systems limit agents to 10 steps or fewer
• 80% of successful deployments use "structured control flow" with human-designed workflows
• Teams create "simplified wrapper APIs" rather than granting direct API access
• Only 12% require prompts exceeding 10,000 tokens with extensive guardrails

Anthropic's Position: Complexity Without Demonstrated Value

Anthropic's Building Effective Agents documentation (raw_16.md): "Finding the simplest solution possible, and only increasing complexity when needed is essential... Many teams mistakenly add complexity without demonstrating it improves outcomes."^[16]

Anthropic's Applied AI team at AWS re:Invent 2025: "What didn't work: Breaking tasks into concurrent sub-tasks for parallel execution didn't succeed practically." They moved away from "complex 50-prompt chained workflows" toward "agentic loops with tools — fewer edge cases to hardcode."^[18]

Claude Code best practices guide: "Despite multi-agent systems being all the rage, Claude Code has just one main thread… I highly doubt your app needs a multi-agent system."^[53]

Epsilla analysis of Anthropic's harness philosophy:^[36] BrowseComp benchmark showed that giving models code-writing capabilities for self-filtering improved accuracy from 45.3% to 61.6% — removing the orchestration harness improved outcomes. "Models demonstrating near-human coding abilities no longer need hand-holding through restrictive harnesses."

Section 4: Tool Proliferation and MCP / Tool-Profile Bloat

Tool proliferation is structural sediment: each tool is added for a reason, but tools are never removed when that reason disappears. The result is ever-expanding schema surface area that consumes context budget before any work begins.

Key finding: MCP costs 4x to 32x more tokens than CLI for identical operations. Simple task comparison: 1,365 tokens via CLI vs. 44,026 tokens via MCP. The difference is eager schema injection vs. progressive disclosure via --help.^[50]

The Tool Soup Problem: Context Cost Quantified

Eager Loading as Structural Sediment

Claude Code loads all context at startup regardless of need. The startup context budget allocation, documented via the feature request for lazy loading (GitHub #44536):^[59]

The baseline eager-loading behavior is structurally sediment — loading everything whether or not it's relevant.^[59] ToolSearch already demonstrated the fix: defer MCP tool definitions, load full schemas only on demand, achieve 85% token reduction with zero functionality loss.

The API-Mirroring Anti-Pattern

One-tool-per-endpoint designs — jira_create_issue, jira_update_issue, jira_add_comment — mirror the REST API exactly, creating maximal schema surface area.^[50][37] Specific call-out from raw_37.md: "Dozens of tools mirroring REST API (read_thing_a(), read_thing_b()) create context bloat and rigid abstractions."

Replacement pattern: Task-level tools that combine related operations into fewer, broader tools; dynamic tool loading via two-step routing (cheap planner selects tool families, specific tools loaded on demand).^[37]

Per-Turn MCP Overhead: The Uncached Mechanism

From Claude Code system prompt analysis:^[20] "MCP Server Instructions" are "recomputed every turn (not cached)." Any MCP server with verbose instructions contributes uncached token overhead on every turn — this is the mechanism by which tool-profile abstractions accumulate as sediment. Each registered MCP server contributes per-turn overhead whether or not its tools are invoked that session.

The March 2026 Caching Incident

Two bugs in Anthropic's prompt caching (GitHub #40524) caused 10–20x token inflation with no warning. Users had to reverse-engineer the Claude Code binary to find the cause.^[30] This incident reveals the diagnostic problem with tool-profile sediment: overhead accumulates silently, with no observable signal until someone audits the billing.

Vercel's Tool Reduction: The Canonical Case

Vercel removed 80% of their agent's tools — 15+ specialized tools collapsed to 2 — with measurable performance improvement across every metric.^[28] Full metrics in Section 10 (Net Deletion Stories). The lesson: "The best agents might be the ones with the fewest tools. Every tool is a choice you're making for the model."^[28]

Section 5: Skills Loaded But Never Invoked

The skill activation problem is the purest form of orchestration sediment: infrastructure that is present in context, consuming tokens on every turn, and producing outcomes identical to having no infrastructure at all. The empirical evidence shows the activation failure rate is the majority case, not the exception.

Key finding: Vercel evaluation study found that in 56% of evaluation cases, the agent never invoked the skill it needed — despite the skill mechanism functioning correctly and documentation existing.^[34] Skills delivered zero improvement over having no documentation at all.

The Invocation Failure Benchmark

Three activation failure mechanisms prevent skills from being invoked:^[45]

1. Recognition gap: Agent must recognize it needs information before requesting it — fails when the agent doesn't know what it doesn't know
2. Sequencing failures: Agents unsure whether to explore first or read documentation first; often chooses exploration and never returns to documentation
3. Access variability: Skills only available when agent decides to retrieve them — the decision itself is the failure point

Production Audit: The Scale of Non-Invocation

A real audit of a 192-file skill setup found:^[12]

• 59 broken internal references
• 20 orphaned skills (zero invocations since installation)
• 30 duplicate definitions
• One 1,239-line legacy command still executing alongside its replacement

Silent failure modes documented:^[12]

• Broken references: Internal path references point to moved/deleted files; agent reads and continues silently — appears as model non-compliance, is actually a 404
• Orphan files: Skills exist but no commands or workflows ever invoke them — non-invocation rate unknown, unmeasured
• Singletons that split: Flat .md files balloon to 600–800 lines then split into diverging versions; both persist
• Duplicate doctrine: Two files defining the same task; agent "picks whichever has the most recent positional weight" — selection is unpredictable
• Dead aliases: Legacy commands never deleted continue running alongside current systems

Token Cost of Skill Accumulation at Scale

From a production Hermes-agent setup managing 146+ skills:^[58]

Zero visibility into which skills are dead weight vs. active: "There's no way to know: How many times a skill has been loaded via skill_view, When a skill was last used, Which skills are 'dead weight' (never used since installation)."^[58] Without invocation metrics, skills accumulate without any feedback signal that they're being used.

Manual Skills Fail 90% of the Time

From Claude Code best practices:^[53] "Manual Skills Are Ignored: Skills without auto-activation hooks fail approximately 90% of the time, rendering them useless regardless of quality." An entire category of manually-invoked skills is effectively sediment by default — present in context, consuming tokens, failing to activate.

Context Rot: The Accumulation Mechanism

Context rot occurs when skill files grow large enough to flood the context window.^[11] Three performance failure modes:

1. Instruction conflicts: Contradictions accumulate as skill files grow — agent resolves conflicts unpredictably, appearing as inconsistent behavior
2. Token budget compression: "If your skill files consume 20,000 tokens out of a 200,000-token context, that's 10% of total capacity gone before a single line of code is read"^[11]
3. Relevance mismatch: "A file that began as documentation for three API methods eventually becomes a catch-all for every decision, preference, and edge case"^[11]

The Fix: Passive Context over Active Skills

The solution to 56% non-invocation is eliminating the invocation decision entirely. AGENTS.md embeds compressed documentation index directly into the system prompt rather than requiring dynamic retrieval. Raw documentation (40KB) compressed 80% to 8KB using pipe-delimited structures — making "passive context" (always-present) feasible without excessive token cost.^[34]

Design principle: "Reduce optionality at points where optionality introduces failure." Skills requiring an invocation decision introduce optionality at a failure point. Static context eliminates the option to miss.^[34]

Deletion criteria for skills: "If the right behavior is what a competent developer would do anyway, you don't need to document it."^[11] Targets: instructions that contradict each other, guidance added for a specific situation but never scoped to it, documentation for tools or patterns the project no longer uses.

Section 6: System Prompt and CLAUDE.md Sediment

CLAUDE.md sediment accumulates through the same asymmetric mechanism: rules are added when something breaks, never pruned when the problem disappears or Claude already handles it natively. The result is a file that grows until it exceeds the reliable attention limit, at which point additional rules actively degrade behavior by crowding out the rules that matter.

Key finding: CLAUDE.md pruned from 1,400 lines to 420 lines (70% reduction) produced simultaneous improvement in Claude's output quality. The reduction itself improved performance — fewer rules means more attention per rule.^[55]

The Attention Limit: Hard Ceiling on Rule Effectiveness

Frontier LLMs reliably follow 150–200 instructions.^[6][23] Claude Code's system prompt already uses approximately 50 of those slots. Mathematical reality: a 200-line CLAUDE.md has already exceeded the reliable attention window. Research by Jaroslawicz et al. (2025) demonstrated that instruction compliance decreases linearly as instruction count increases.^[63]

Measured Deletion Impact (TonyRobbins.com Project)

200 Rules That Produced Zero Behavior Change

One practitioner documented 200 lines of CLAUDE.md instructions that were systematically ignored:^[63]

Resolution: Cut from 200 rules to ~20; replace the rest with code-based enforcement (hooks). "Rules in prompts are requests. Hooks in code are laws." The 180 deleted rules were pure sediment — loaded into context every session, zero observable behavior change.^[63]

Official Anthropic Exclusion List

Official Anthropic documentation explicitly lists what NOT to include in CLAUDE.md:^[51]

• Anything Claude can figure out by reading code
• Standard language conventions Claude already knows
• Detailed API documentation (link to docs instead)
• Information that changes frequently
• Long explanations or tutorials
• File-by-file descriptions of the codebase
• Self-evident practices like "write clean code"

The advisory vs. deterministic distinction: "Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens."^[51] CLAUDE.md-based behavioral instructions produce zero observable effect when they conflict with trained behavior — they are advisory, not enforceable.

Specific Anti-Pattern Categories

The Core Pruning Test

From HN discussion: "If removing this line wouldn't cause Claude to make a different mistake, delete it."^[7] The real cost of bloat is not token count per se — it is diluted signal. Instructions that would change behavior get buried under instructions that describe what Claude already does by default.

Contradictory finding on markdown headers: One HN commenter pushed back on complete removal: "LLMs do understand header levels in markdown. So removing these is detrimental." Consensus: compression matters most for resource-constrained models (Haiku) with large codebases; on Opus with simple projects, readability typically outweighs token savings.^[7]

Section 7: Zero-Observable-Effect Hooks

Hooks that fire on every event without producing an observable behavior change are the most insidious form of orchestration sediment: they appear active (logs show they ran), they appear configured (settings show they're registered), and they produce no value. Detection requires distinguishing "hook ran" from "hook changed behavior" — a distinction that is rarely made in practice.

Key finding: The zero-observable-effect hook pattern has a precise five-step sequence: (1) hook is configured and runs, (2) output is delivered to the model, (3) model acknowledges the hook content, (4) model proceeds with the original action anyway, (5) net effect: hook ran, nothing changed.^[46]

The Stop Hook Failure Pattern

Hacker News thread on Claude 4.7 ignoring stop hooks (raw_46.md):^[46] Users report stop hooks designed to prevent session termination without running tests are routinely ignored. Four failure mechanisms identified:

Documented GitHub Bug Reports: Hooks That Look Active But Aren't

Both failure modes — "configured but never firing" and "firing but producing no behavioral change" — create identical user experience: complexity in the configuration, zero observable value, no way to distinguish functional from broken hooks without dedicated investigation.

Specific Hook Sediment Cases

The Ornamental Hook (raw_13.md)

A practitioner audit found hooks including one that "printed a cute message on session start" — the canonical ornamental hook.^[13] Two more were "semi-broken and I'd been ignoring the errors for weeks." This is why hooks accumulate: deletion requires investigation (broken or working silently?), so practitioners accept broken/noisy hooks rather than investigating.

Auto-Formatting Hook Overhead (raw_53.md)

Auto-formatting hooks consumed 160K tokens across three rounds — not worth the marginal convenience.^[53] The hook fired, performed formatting, consumed tokens, but the marginal value of automatic vs. manual formatting was negligible. Observable activity; no observable behavior improvement.

The Retry Loop at Scale (raw_60.md)

From the Claude Code source analysis: "over 1,200 sessions had experienced 50 or more consecutive compaction failures before a simple three-line fix capped retries at three attempts, saving roughly 250,000 wasted API calls per day globally."^[60] The unbounded retry loop kept firing, consuming API calls, producing no observable value change. Fix: 3 lines. This is the prototype of "hooks firing on every event with no observable behavior change" at scale: 250K wasted API calls per day, zero observable output change.

memoryAge.ts Zero-Effect Pattern (raw_61.md)

The memoryAge.ts module appends age warnings to memories but "doesn't reduce the memory's weight" or trigger verification.^[61] It fires, adds a note, but observable behavior (what the agent does with old memories) is unchanged. Classic sediment: code runs on every memory operation, produces output, changes nothing.

The Fundamental Category Error

The deletion conclusion from practitioners who tried stop hooks:^[46] "I never got stop hooks to work and gave up on them." Replaced with pre-commit git checks (deterministic enforcement) or removed behavioral hooks entirely, relying on CLAUDE.md instructions.

Fundamental category error: Expecting text-based instructions to enforce hard stops in probabilistic systems. Exit code 2 (block) works reliably. Natural language behavioral instructions via hooks do not.^[46][51] The deletion story: elaborate stop-hook systems get torn down because they create complexity without observable effect.

Section 8: Write-Only Databases and Memory Systems

Write-only memory systems are the database equivalent of zero-observable-effect hooks: the write path works, data accumulates, but the read path fails silently or is never invoked. The agent's behavior is indistinguishable from an agent with no memory at all — while the memory infrastructure consumes storage, maintenance overhead, and, where LLMs are used for retrieval, compute cost.

Key finding: "Write-manage-read must function as an integrated system, not isolated components. A memory system where writes far outnumber reads is a write-only database — infrastructure theater rather than functional cognition."^[35]

Memory System Benchmark Failures

The Diary vs. Notebook Failure

"The current memory tools are diaries. They record events. What I actually need is a notebook."^[8]

Anti-pattern: A session log documenting "Changed connection pool from 10 to 20. CPU usage went up 15%. Timeout issue wasn't resolved" gets stored as disconnected facts rather than the learned lesson that connection pool increases correlate with CPU degradation without solving timeouts. The write path captures; the learning path that transforms observations into retrievable lessons doesn't exist.

Confirmation bias in extraction:^[8] "I've seen it extract 'reducing timeouts improves performance' when the actual cause was a concurrent deployment." Single-model extraction produces wrong lessons that compound across future sessions if they persist unchallenged.

Cold start abandonment: "A new installation has no beliefs. The first 10–20 sessions don't benefit from accumulated knowledge." The system is write-only for its entire initial phase; by the time enough data accumulates to produce value, practitioners have often abandoned it.^[8]

The 258 Knowledge Base Files Nobody Retrieved

Double sediment from a single practitioner's setup:^[63]

1. 258 knowledge base files were written to but never retrieved — write-only database
2. "KNOWLEDGE RETRIEVAL PROTOCOL" — a 200-line CLAUDE.md rule about how to query the knowledge base — had zero observable effect

Both layers are sediment simultaneously: the data store nobody queries AND the rule about querying it that produced no behavior change.

Knowledge Graphs: Write-Only Infrastructure Pattern

The knowledge graph anti-pattern in AI agents:^[27][22]

• Write path succeeds: Graph ingestion pipelines work; entities and relationships are extracted and stored
• Read path fails silently: "Multi-hop retrieval failures occur because answers to complex queries often depend on entities not in the original query. Pure similarity matching cannot bridge this gap."^[22]
• Infrastructure theater: Teams build KG ingestion pipelines without confirming whether the graph will ever be meaningfully queried for tasks that simpler retrieval cannot handle^[27]
• KG construction costs: Extracting entities and relationships requires "passing your whole corpus through an LLM for extraction. For a big dataset, that's $$$ and hours gone." Schema inconsistencies break graph connectivity: "Paris tagged as 'Location' while France gets tagged as 'Country'"^[27]

Simpler alternatives that often outperform KG: Classic RAG, smarter chunking, better embeddings, and re-rankers — at far lower cost and maintenance burden.^[27] The Letta/Mem0 benchmark confirms: basic file storage (74.0%) beat specialized vector retrieval (68.5%).^[22]

LLMs in Memory Retrieval Path: Deletion Story

One practitioner abandoned LLMs in memory retrieval after identifying four production problems:^[41]

What was deleted: LLM query rewriting, re-ranking, and summarization from the retrieval path entirely. Replacement: Deterministic mathematical retrieval — vector similarity + graph traversal + token-based matching + fusion ranking. Philosophy: "Treat memory as infrastructure, not prompt engineering."^[41]

The Specific Write-Only Incident Pattern

Mark McArthey documented the canonical write-only failure:^[48] After rejecting a particular solution approach on April 20, a different Claude instance proposed the identical rejected idea three days later. The prior reasoning existed in accessible session files, but the agent couldn't retrieve it — context window limitations had rendered the information inaccessible. "The agent is writing structured session data to disk already. The agent just isn't reading its own archive."

A Microsoft engineer documented the efficiency cost: repeatedly re-explaining code to the same agent consumed significant daily time — the cost of a write-only memory system measured in human hours.^[48]

Section 9: AI Strategic Planner Personas and Meta-Orchestrators

Strategic planner personas are the highest-complexity form of orchestration sediment: they are the hardest to build (requiring careful prompt engineering and coordination logic), the hardest to delete (because removing the planner requires redistributing its responsibilities), and the least likely to deliver on their promise (because LLM-based planning of LLM work introduces a compounding layer of probabilistic behavior).

Key finding: Anthropic's Claude Code Coordinator — their own orchestrator — deliberately removes capabilities: "The Coordinator cannot execute Bash. It cannot read files."^[2] The deliberate deletion of capabilities from the orchestrator is the design pattern. An orchestrator that can do everything will fail in catastrophic ways.

The "Super AI" Failure Pattern

The strategic planner that gets deleted is typically a grand coordinator agent designed to orchestrate everything. Its properties:^[47]

• Adds a full LLM call to every operation just for planning
• Becomes the single point of failure (a minor bug creates cascading failures)
• Cannot be tested in isolation (all context-dependent)
• Accumulates strategic rules nobody reviews
• Prevents swapping in better specialized models without overhauls

Four failure modes of monolithic coordinators:^[47]

1. Brittleness: "A minor bug in one small, seemingly unrelated module can create cascading failures that bring down the entire system"
2. Inefficient scaling: Upgrading one function forces scaling the whole system
3. Innovation lock-in: Prevents swapping in better specialized models
4. Black-box risk: "Context blindness" when optimizing narrowly

The Mega-Prompt as Planner Sediment

Anti-Pattern #1 from achan (raw_9.md): "Overloading a single agent with hundreds of instructions it cannot reliably execute." One real deployment gave an agent "close to 500 lines of procedural instructions" expecting exact execution. Result: LLMs compress context and optimize for intent, not strict procedural execution.^[9]

From hatchworks:^[57] "Mega-prompts" explicitly called out — "one prompt tries to handle everything; nobody can maintain it." The prompt grows incrementally, each addition appearing reasonable, until "nobody can maintain it." This is the signal that the thing exists but is effectively inert — a strategic planner that accumulates rules nobody reviews and produces behavior nobody can predict.

Anthropic's Prompt Chain Deletion

Anthropic's Applied AI team at AWS re:Invent 2025:^[18]

The Invisible State Anti-Pattern in Multi-Planner Systems

Anti-Pattern #3 from achan: "Relying on LLMs to remember past actions instead of explicit state management" produces "repeated steps, contradicting actions, collapsing context windows, hallucinated states."^[9] Kamradt's benchmark showed state buried in long conversations becomes "effectively unreliable." Strategic planner personas that rely on conversation history to maintain planning state are structurally exposed: as the planning conversation grows, the planner's memory degrades.

Google's Titanium Agent Deletion

From Google's production AI agent refactor (raw_64.md):^[64]

Prompt-string schema enforcement is the strategic-planner-in-miniature: verbose instructions describing JSON output format inside the prompt consume context on every call, "just in case" the model needs reminding. Classic speculative sediment.^[64]

When Strategic Coordination Is Actually Needed

The deletion story points to where coordination genuinely adds value. Anthropic's own Building Effective Agents documentation:^[16] orchestration that adds value has three properties: clear task decomposition with explicit ownership boundaries, structured topology (not "bag of agents"), and state that is explicit and externalized (not held in conversation history). Routing decisions that were previously encoded as strategic planning prompts become simple conditional logic — the planning abstraction was compensating for code that was not written.

Section 10: Net Deletion Stories: Metrics and Outcomes

Net deletion stories — complete before/after comparisons with measured outcomes — are the empirical foundation for identifying which orchestration components are sediment. The consistent finding across independent teams: deletion improves performance on every measurable dimension simultaneously. If deletion had trade-offs, the pattern would not be consistent.

Key finding: Vercel removed 80% of their agent's tools, replacing 15+ specialized tools with 2, and improved every metric: 3.5x faster execution, 20% higher success rate, 37% fewer tokens, 42% fewer steps.^[28] "The model makes better choices when we stop making choices for it."

Vercel d0: The Canonical Tool Deletion

The original system had 15+ specialized tools built on the assumption that the AI needed hand-holding through complex schemas:^[28][15]

Tools deleted: GetEntityJoins, LoadCatalog, RecallContext, LoadEntityDetails, SearchCatalog, ClarifyIntent, SearchSchema, GenerateAnalysisPlan, FinalizeQueryPlan, JoinPathFinder, SyntaxValidator, VisualizeData, ExplainResults (and others)

Tools retained: 2 — bash command execution and SQL execution

Why the specialized tools existed: "Solving problems the model could handle on its own." Engineers believed the AI would "get lost in complex schemas, make bad joins, or hallucinate table names." Every specialized tool was an assumption about AI limitations. Those assumptions were wrong. "We were doing the model's thinking for it."^[28]

What replaced the tooling: A filesystem agent architecture where Claude accesses raw Cube DSL files (YAML, Markdown, JSON) directly and uses standard Unix utilities (grep, cat, ls, find). "File systems are an incredibly powerful abstraction. Grep is 50 years old and still does exactly what we need."

LangChain → Raw SDK: Full Economics

CLAUDE.md 70% Reduction → Improved Quality

Personal Session Waste Audit

One practitioner's cleanup quantified in dollar terms:^[13]

• 58 slash commands (couldn't name the purpose of half)
• CLAUDE.md at 80+ lines when 10 would suffice
• 4 MCP servers loading at user scope for every project including irrelevant ones
• 1 ornamental hook (printed a startup message)
• 2 semi-broken hooks ignored for weeks
• 46 disabled plugins still contributing overhead

Measured waste: ~$3.75 per session in orchestration overhead; "potentially $200–400/month in recovered productivity" after cleanup.^[13]

mabl Agent: 4.5x Clean Session Rate

Replacing a sprawling monolithic state object with focused schema-validated artifacts:^[17]

• Clean sessions increased roughly 4.5x
• Severely problematic sessions dropped by over 90%
• Bad assertions dropped by over 80%

The monolithic state object is the structural manifestation of orchestration sediment: an undifferentiated blob of context accumulated over time, where everything is kept because nothing can safely be discarded.

AutoGen → Deterministic Sequencing: 3x Development Speed

Same task (table reservation workflow):^[49]

ToolSearch Deferred Loading: 85% Token Reduction

Claude Code's ToolSearch pattern achieved 85% token reduction for tool schemas by deferring MCP tool definitions and loading full schemas only on demand.^[59] This is the most direct evidence that eager loading of tools and skills is sediment: switching from "load everything at startup" to "load on demand" improved context economics by 85% with no functionality loss.

Cross-Deletion Pattern: What Gets Kept

Across all documented deletion stories, a consistent set of components survives:

The convergence principle: The surviving components share one property — they cannot be replaced by model capability improvements. Flat file systems work because the access pattern is explicit. Deterministic enforcement works because exit code 2 is not probabilistic. Direct SDK calls work because they have no hidden assumptions. Everything else is subject to deletion as models improve.^[28][36][16]

Home