Vincent van Deth 

In February 2026, Anthropic shipped Agent Teams — a native multi-agent coordination feature for Claude Code. A lead agent decomposes tasks, spawns teammates, and coordinates work through a shared task list. Teammates communicate directly with each other and with you. It's built into the product, it's elegant, and it works.

I watched the announcement with a very specific feeling: the feeling of someone who spent eight months building their own version of something the platform just made native.

But after weeks of comparing both systems — running Agent Teams on side projects while VNX handles my production work — I've come to a conclusion that surprised me. **Agent Teams and VNX aren't competitors. They solve different problems.** And the gap between them is exactly the gap I've been writing about in this series: governance.

## What Anthropic built

Agent Teams coordinates multiple Claude Code instances working together. Here's the architecture:

A **lead agent** (your main Claude Code session) acts as the team coordinator. It understands the overall task, breaks it into subtasks, and delegates work to **teammates** — separate Claude Code instances, each with their own context window.

Teammates share a **task list** — a common work queue where tasks have states (pending, in progress, completed) and dependencies. A teammate finishes a task, picks up the next available one. If tasks depend on each other, blocked tasks wait automatically.

Teammates also have a **mailbox** — a direct messaging system. They can talk to each other, challenge findings, share discoveries. The lead doesn't need to relay every message. In split-pane mode (tmux or iTerm2), you can see all teammates working simultaneously and click into any pane to interact directly.

It's genuinely impressive. The team can parallelize code reviews, investigate bugs from competing angles, and build new features with each teammate owning a separate module. Anthropic's own stress test — 16 agents writing a Rust C compiler across nearly 2,000 sessions — demonstrated the scale it can handle.

Anthropic Agent Teams: lead coordinates teammates through shared task list with direct inter-agent messaging

## What I built

VNX — the system I've been running for eight months and documenting in this series — looks different. Here's the same view:

Notice what's missing: there are no arrows between workers. T1, T2, and T3 never communicate. There's no shared task list between them. There's no mailbox. Each worker operates in complete isolation.

All coordination goes through T0 — and T0 itself can't write code. It can only read, plan, and dispatch. Every dispatch requires human approval. Every completion requires evidence. Every evidence goes through quality gates before T0 can accept it.

VNX: orchestrator dispatches through human gates, workers isolated, quality gates evaluate independently

## Where they overlap

The similarities are real and worth acknowledging:

**Lead-agent coordination.** Both systems use a central coordinator. Agent Teams has the lead; VNX has T0. Both decompose tasks, assign work, and synthesize results. The pattern is the same: one agent thinks, others execute.

**Parallel workstreams.** Both run multiple agents simultaneously on separate aspects of a problem. Agent Teams uses teammates claiming tasks from a shared list. VNX uses track-agnostic workers that can handle any type of task. The parallelism model is fundamentally similar.

**Task dependencies.** Both handle ordered work. Agent Teams blocks tasks with unresolved dependencies. VNX's staging queue prevents dispatches from promoting until prerequisite PRs are complete. Different mechanisms, same principle.

**Shared project context.** Both give workers access to the same codebase. Teammates load CLAUDE.md and project files. VNX workers operate in the same repository with their own CLAUDE.md configurations. The agents see the same code.

**Plan-before-implement.** Agent Teams can require teammates to plan before executing — the lead reviews and approves the plan. VNX's staging queue serves the same function: the orchestrator reviews the dispatch scope before the worker begins. This is one of the core **[Glass Box Governance](/blog/glass-box-governance-multi-agent-ai)** principles: no action without approval.

These overlaps aren't coincidental. Both systems converged on the same patterns because those patterns work. Decompose, delegate, coordinate, synthesize. It's the multi-agent playbook.

> 📖 **Read also:** **[Context Rot Is Silently Killing Your Claude Code Sessions](/blog/context-rot-claude-code-automatic-rotation)** — Why session management is critical when running multiple agents in parallel

## Where they diverge

The differences tell a more interesting story. They reveal fundamentally different assumptions about trust, risk, and who should be in control.

### 1. Inter-agent communication

**Agent Teams**: Teammates message each other directly. They can share findings, challenge hypotheses, and coordinate without the lead relaying every message. This is powerful for research and review tasks where cross-pollination of ideas adds value.

**VNX**: Workers never communicate. All information flows through T0 and the governance layer. Workers don't know about each other's existence.

**Why this matters**: Direct inter-agent communication is the mechanism that enables [the Cascade of Doom](/blog/cascade-of-doom-ai-agent-hallucination). When Agent A can influence Agent B's decisions without a checkpoint in between, one hallucination can propagate across the entire system. My 2am incident — where one agent hallucinated a dependency and another helpfully created it — happened precisely because agents could react to each other's output without an independent check.

Agent Teams mitigates this partially through the lead's oversight, but the lead is itself an AI agent. It makes autonomous decisions about whether teammate plans are good enough to approve. In VNX, that decision is always human.

### 2. Provider lock-in

**Agent Teams**: All teammates are Claude Code instances. You can choose different Claude models (Opus, Sonnet) per teammate, but you can't mix providers. No Codex teammate. No Gemini teammate.

**VNX**: Each worker can run any provider. T1 can be Codex CLI while T2 runs Claude Sonnet and T3 runs Gemini. The dispatch system adapts per provider. The governance pipeline is provider-neutral — it observes terminal output, not API calls.

**Why this matters**: Model diversity isn't just about having options. Different models catch different types of errors. When I run a Claude Opus investigation on any task against code that Claude Sonnet wrote on any task, I'm getting a second opinion from a fundamentally different model configuration. If T1 is running Codex, its code generation patterns are different enough that it won't reproduce the same hallucination patterns as Claude. Provider diversity is a governance property, not just a convenience. I use an **[external watcher pattern](/blog/external-watcher-pattern-ai-agent-observation)** to observe output across all providers without trusting their self-reports.

### 3. The governance layer

This is the big one.

**Agent Teams**: The lead decides when work is done. Teammates mark tasks as complete. The lead synthesizes results. There are hooks — `TeammateIdle` and `TaskCompleted` — that can enforce rules, and you can require plan approval before implementation. But the audit trail is the conversation history, which doesn't persist across sessions. There's no receipt ledger, no external quality gate, no evidence-based closure system.

**VNX**: Completion is never self-reported. Every action writes a receipt to an append-only ledger. Every completion triggers an **[independent quality advisory](/blog/async-quality-gates-ai-agent-workflows)** (file sizes, function lengths, dead code, test hygiene). Only T0 — after reviewing the evidence and the quality verdict — can declare work done. The agent's "I'm done" is input, not verdict.

**Why this matters**: In any system where agents can declare their own work complete, you're trusting the agent's self-assessment. An agent that reports "confidence 0.97" may have written an 847-line file that violates every quality standard. The confidence score reflects the model's internal state, not external reality. Independent verification — by a process the agent can't influence — is what makes governance trustworthy.

Feature comparison table showing Agent Teams excels at ease of use, VNX excels at governance

### 4. Who makes the final call

**Agent Teams**: The lead agent decides autonomously. You can influence its judgment through prompts ("only approve plans that include test coverage"), but the approval decision is the lead's to make. You can also interact with teammates directly, but the system is designed for the lead to run the show.

**VNX**: Every dispatch requires explicit human approval before execution. A popup appears, you review the scope, and you press Accept or Reject. There is no autonomous dispatch path. T0 proposes; you decide. This was a deliberate choice after the [Cascade of Doom incident](/blog/cascade-of-doom-ai-agent-hallucination) — I permanently disabled auto-accept.

This is not a criticism of Agent Teams' approach. For research tasks, code reviews, and exploration work, having the lead coordinate autonomously is exactly right. The overhead of human approval on every task would destroy the productivity benefit.

But for production code — the kind where a wrong decision at 2am results in three files being rewritten and tests being "fixed" to match the wrong behavior — I want a human in the loop. Every time.

## The cascade of doom test

Here's the thought experiment I use to evaluate any multi-agent system:

*It's 2am. An agent hallucinated a dependency. Another agent sees the failing tests and "fixes" them by creating the hallucinated dependency. A third agent notices the new module and refactors surrounding code to use it. By morning, three files are rewritten, all tests pass, and the git history looks clean.*

**Can your system prevent this?**

In Agent Teams: the lead would need to catch the hallucination before approving the teammate's plan. If the lead misses it — and the lead is an AI agent operating without human oversight at that point — the cascade proceeds. The `TaskCompleted` hook could catch it, but only if you've written the right validation logic. There's no built-in quality gate that checks file sizes, function complexity, or dead code.

In VNX: the cascade can't start. The first agent's completion would trigger a quality advisory. Even if the quality gate didn't catch the specific hallucination, the human approval gate would. The dispatch to "fix the failing tests" would appear as a popup. A human would see that the proposed fix is "create a module that didn't exist before" and ask: why?

**The governance gap isn't about which system is better. It's about which failure modes are acceptable for your use case.**

## When to use which

After running both systems, here's my honest recommendation:

**Use Agent Teams when:**

- You're exploring, researching, or reviewing (not writing production code)
- Tasks benefit from inter-agent discussion and cross-pollination
- You want parallel work without building infrastructure
- Speed of setup matters more than auditability
- You're comfortable with AI-mediated approval (the lead decides)

**Use VNX (or something like it) when:**

- You're writing production code that ships to users
- You need an audit trail that survives session expiry
- You use multiple providers (Claude + Codex + Gemini)
- You want human approval on every action that touches code
- You need to reconstruct "what happened and why" after the fact
- You've already experienced your first cascade and sworn never again

**Use both when:**

- Agent Teams for research spikes and code reviews
- VNX for the implementation pipeline with receipts and gates

They're not mutually exclusive. I've started using Agent Teams for investigation work — spinning up three teammates to explore different hypotheses about a bug — and then funneling the findings into VNX dispatches for the actual fix. The exploration is fast and collaborative. The implementation is governed and auditable.

Decision matrix: Agent Teams for exploration, VNX for production governance, both for comprehensive coverage

## What I hope Anthropic builds next

Agent Teams is a genuinely good v1. The architecture is sound, the developer experience is smooth, and the parallel exploration model works well. If I were advising Anthropic on what to add next, the list would be short:

**Persistent audit trail.** Today, the governance record is the conversation history, which doesn't survive session termination. A structured, append-only log of team actions — who did what, when, with what result — would transform Agent Teams from an exploration tool into a production tool. (This is essentially [Part 4: The NDJSON Receipt Ledger](/blog/ndjson-receipt-ledger-ai-audit-trail) built into the platform.)

**External quality gates.** The `TaskCompleted` hook is a start, but it runs in the same environment the agent controls. An independent validation layer — file size checks, complexity analysis, dead code detection — that evaluates agent output without the agent's influence would close the biggest governance gap.

**Multi-provider teammates.** The ability to spawn a Codex or Gemini teammate alongside Claude teammates would make Agent Teams the first platform to offer native multi-provider orchestration. The external watcher pattern — observing agent output from outside the agent's context — shows this is architecturally feasible.

**Configurable human gates.** A setting between "the lead decides everything" and "ask me for every action." Something like: autonomous for research tasks, human-approved for code changes. Risk-proportional oversight.

## The deeper question

The emergence of Agent Teams validates something I've believed since the first month of running VNX: multi-agent coordination is becoming table stakes. Everyone will be running agent teams soon — whether through Anthropic's product, LangGraph, CrewAI, or homebrew systems like mine.

But coordination without governance is a recipe for sophisticated failure. The more capable your agent team, the more convincingly it can produce work that *looks* correct but isn't. The Cascade of Doom doesn't get less dangerous with better models — it gets more dangerous, because the output becomes harder to distinguish from genuine good work.

The question isn't "should I use Agent Teams or build my own?" The question is: **what happens when your agents are wrong, and how will you know?**

If you have a good answer to that question, use whatever orchestration tool fits your workflow. If you don't — I help businesses build exactly this kind of **[AI architecture](/ai-architectuur)** through **[my consulting practice](/diensten)**. Or read the rest of this series. Especially [Part 3](/blog/cascade-of-doom-ai-agent-hallucination). Because the cascade will find you eventually. And it's much cheaper to build the gates before it does.

***

*This is Part 5 of the Glass Box Governance series. [Part 1](/blog/multi-model-ai-orchestration-single-terminal) introduces the multi-model orchestration setup. [Part 2](/blog/glass-box-governance-multi-agent-ai) defines the four governance pillars. [Part 3](/blog/cascade-of-doom-ai-agent-hallucination) covers the incident that made governance non-negotiable. [Part 4](/blog/ndjson-receipt-ledger-ai-audit-trail) covers the receipt ledger. [Part 6](/blog/async-quality-gates-ai-agent-workflows) introduces async quality gates. [Part 7](/blog/external-watcher-pattern-ai-agent-observation) covers the external watcher pattern.*

*Vincent van Deth is a product architect and AI system builder based in the Netherlands. He builds production systems with AI and teaches others to do the same. The VNX architecture and prototype are available on [GitHub](https://github.com/Vinix24/vnx-orchestration).*

large_agent-teams-vs-vnx-orchestration_cover

medium_agent-teams-vs-vnx-orchestration_cover

small_agent-teams-vs-vnx-orchestration_cover

thumbnail_agent-teams-vs-vnx-orchestration_cover

agent-teams-vs-vnx-orchestration_cover

Claude Agent Teams vs. Building Your Own: What Anthropic Solved (And What They Left Out)

Your Claude Code session doesn't crash when the context window fills up. It does something worse — it starts forgetting. Your Claude Code gets dumber the longer you use it, and there's no error message to warn you.

Not dramatically. Not with an error message. The agent just... drifts. It loses architectural decisions you made an hour ago. It rewrites code it already wrote. It proposes changes that contradict its own earlier analysis. The output still looks professional — clean commit messages, reasonable diffs — but the substance quietly degrades. If you've ever wondered why Claude Code forgets earlier instructions after a long session, this is why.

I call this **context rot**, and after running multi-agent AI workflows daily for six months, I believe it's the single biggest unaddressed problem in AI-assisted development. This is especially critical in production systems using the **[Glass Box Governance architecture](/blog/glass-box-governance-multi-agent-ai)** I've built as part of the **[VNX orchestration toolkit](https://github.com/Vinix24/vnx-orchestration)** — when agents can't see or verify their own state, context rot leads to undetectable quality drift.

Context window usage over time, showing quality degradation after 65%

## What context rot actually is

Claude Code operates within a fixed context window — roughly 200,000 tokens. Every message, every file read, every tool result consumes part of that budget. When the window approaches capacity, Claude Code activates auto-compaction: it summarizes earlier messages to free up space.

This is where rot begins.

Auto-compaction is lossy compression on your working memory. It doesn't crash your session — it silently drops nuance. The summary of a 50-line architectural discussion becomes a single sentence. The specific test failure you debugged for 20 minutes gets compressed to "fixed test issues." The agent loses the *why* behind decisions and retains only a shallow *what*.

This isn't just my experience — it's well-documented in research. Stanford's **["Lost in the Middle"](https://arxiv.org/abs/2307.03172)** (Liu et al., TACL 2024) showed that LLM performance degrades significantly when models must access information in the middle of long contexts, with performance drops of 15-47% as context length increases. A 2025 study on **["Context Discipline and Performance Correlation"](https://arxiv.org/html/2601.11564v1)** confirms that reasoning accuracy and retrieval reliability degrade under maximum context loads, regardless of model size. And the **[Needle in a Haystack research](https://www.researchgate.net/publication/396291682_Context_Length_Alone_Hurts_LLM_Performance_Despite_Perfect_Retrieval)** demonstrated something counterintuitive: context length alone hurts performance even when retrieval is perfect. More context doesn't help — it actively makes things worse.

The symptoms are predictable once you know what to look for. The agent repeats work it already completed — re-reading files it read 30 minutes ago because the compacted summary doesn't mention them. It makes decisions that contradict earlier analysis, because the analysis was compressed away. Multi-step tasks fail in the middle stages because intermediate state vanished during compaction. And the most insidious symptom: you don't notice until the output is wrong, because the agent's confidence never wavers. It just confidently produces worse work.

This is different from a model getting confused or hallucinating. Context rot is a structural problem — the information was there, the agent made good decisions based on it, and then the system silently removed it. The agent didn't make a mistake. Its working memory was taken away. Understanding how **[context flows through multi-agent systems](/ai-architectuur)** is essential for building reliable AI workflows.

> 📖 **Read also:** **[Receipts, Not Chat Logs: Glass Box Governance](/blog/glass-box-governance-multi-agent-ai)** — How audit trails help you detect quality degradation early

## Why /clear isn't the answer

The obvious fix is `/clear` — wipe the context and start fresh. But `/clear` is a nuclear option. You lose *everything*: task state, files touched, progress made, architectural decisions, the entire working memory of the session. Starting over from scratch.

For simple tasks, that's fine. For a multi-hour implementation session where you're six PRs into a feature plan? Starting from zero is brutal.

I looked for a middle ground. What I wanted was simple in concept: detect that context is filling up, save the important state, clear the window, and resume from the saved state. A checkpoint-and-rotate pattern.

The problem: you can't trigger `/clear` from a Claude Code hook. There's a community feature request for this — **[issue #9118](https://github.com/anthropics/claude-code/issues/9118)** on the Claude Code repository — but Anthropic closed it as NOT\_PLANNED. That issue has 200+ upvotes from developers hitting the same wall.

So I built a workaround.

## The tmux workaround

The key insight: Claude Code runs inside tmux panes in my **[multi-terminal orchestration setup](https://github.com/Vinix24/vnx-orchestration)**. And tmux can send keystrokes to any pane — including typing `/clear` and pressing Enter. You can't call `/clear` from a hook, but you can call it from outside the process entirely.

This opened the door to a fully automated rotation pipeline.

Context rotation pipeline: PreToolUse detects pressure, PostToolUse launches rotator, tmux clears, SessionStart recovers

## How the rotation pipeline works

The system uses three Claude Code hooks and one detached bash script. Here's the flow:

**Step 1 — Detect pressure (PreToolUse hook)**

A hook called `vnx_context_monitor.sh` fires before every tool call. It reads the `context_window` data from Claude Code's hook input and checks the `remaining_pct` field.

When context usage hits 65% or higher, the hook returns `decision: "block"` — it literally stops the agent mid-task and tells it: "You're running out of context. Write a handover document before proceeding."

Why 65% and not 80%? Because Claude Code's built-in auto-compaction fires around 80%. Rotating 15 points earlier gives the pipeline enough headroom to complete the handover and execute `/clear` before auto-compaction can race and win. If auto-compact fires first, you lose the nuance you're trying to preserve.

**Step 2 — Detect the handover (PostToolUse hook)**

The agent, now blocked from continuing its task, does the one thing it's still allowed to do: write a file. Specifically, it writes `ROTATION-HANDOVER.md` — a structured markdown document containing the current task state.

A second hook, `vnx_handover_detector.sh`, watches for file writes. When it detects a file with `ROTATION-HANDOVER` in the path, it knows the agent has completed its handover. It acquires an atomic lock (to prevent race conditions if multiple terminals rotate simultaneously) and launches the rotator script `vnx_rotate.sh` as a detached process via `nohup`.

**Step 3 — Clear and inject (the rotator + SessionStart hook)**

The rotator script runs outside Claude Code's process entirely. It:

1. Resolves the correct tmux pane for the terminal
2. Sends `/clear` via `tmux send-keys`
3. Waits for a signal file from the SessionStart hook (up to 15 seconds)
4. Extracts the Dispatch-ID from the handover document
5. Recovers the original dispatch file and agent skill
6. Injects a continuation prompt via `tmux load-buffer` + `paste-buffer`

Meanwhile, the SessionStart hook fires on the fresh session and finds the most recent handover document (less than 300 seconds old). It injects the handover content as context, so the new session knows what was happening.

Two-stage injection: the SessionStart hook provides the *what* (task state, progress, remaining work), and the rotator provides the *how* (the continuation prompt with the correct skill and dispatch context).

The agent picks up exactly where it left off. Zero human intervention.

## The handover contract

The handover document is the critical artifact. It's what bridges the old session and the new one. Here's a real example:

This isn't a transcript dump. It's a structured task state — enough for the incoming session to continue without re-reading the full conversation. Completed work, remaining tasks, and specific next steps with concrete details (PID numbers, port numbers, which target to start from).

The format is constrained deliberately. Claude writes this under context pressure — the whole point is that context is running low. A freeform summary would be unreliable. The structured sections (Completed / Remaining / Next Steps) constrain the output enough to be consistently useful.

## What nobody else has built

I analyzed five open-source projects attempting parts of this problem. None solve the full loop:

| Project | Auto-detect | tmux /clear | Handover inject | Atomic locking | Zero-touch |
|---------|:-----------:|:-----------:|:---------------:|:--------------:|:----------:|
| **VNX Context Rotation** | ✅ PreToolUse hook | ✅ async nohup | ✅ SessionStart + rotator | ✅ mkdir + TTL | ✅ |
| **[claude-code-handoff](https://github.com/Sonovore/claude-code-handoff)** | — manual `/handoff` | — | ✅ SessionStart hook | — | — |
| **[claude-session-restore](https://github.com/ZENG3LD/claude-session-restore)** | — manual CLI | — | ✅ transcript parsing | — | — |
| **[claude\_code\_agent\_farm](https://github.com/Dicklesworthstone/claude_code_agent_farm)** | Semi (threshold flag) | ✅ Ctrl+R broadcast | — task queue restart | — | — |
| **[/wipe gist](https://gist.github.com/GGPrompts/62bbf077596dc47d9f424276575007a1)** | — manual `/wipe` | ✅ send-keys | ✅ paste-buffer | — | — |
| **[claude-code-context-sync](https://github.com/Claudate/claude-code-context-sync)** | — manual save | — | ✅ cross-window sync | — | — |

Here's what each project misses:

**[claude-code-handoff](https://github.com/Sonovore/claude-code-handoff)** is the most recent (February 2026). It uses a `/handoff` slash command that generates a context file, which a SessionStart hook injects on the next session. Solid recovery mechanism — but you have to manually decide when to rotate and manually trigger `/clear`. No pressure detection, no automation.

**[claude-session-restore](https://github.com/ZENG3LD/claude-session-restore)** takes a different approach entirely: it's a Rust CLI that parses JSONL session files after the fact. Multi-vector analysis (tasks, user messages, tool operations, git history) to reconstruct context. Powerful for forensics, but it's a reconstruction tool, not a real-time intervention.

**[claude\_code\_agent\_farm](https://github.com/Dicklesworthstone/claude_code_agent_farm)** is the most architecturally similar to what I built — multi-agent tmux orchestration with 20+ parallel agents. It has a `--context-threshold` parameter that lets agents self-clear. But after clearing, agents restart from their task queue with no handover document. Session continuity is lost. The work the agent did before clearing? Gone, unless it happened to commit something.

**[The /wipe gist](https://gist.github.com/GGPrompts/62bbf077596dc47d9f424276575007a1)** is technically closest to the VNX rotation flow. It uses the same `tmux send-keys` + `load-buffer` + `paste-buffer` pattern for clearing and injecting. But it's a manually triggered slash command with a fixed 8-second delay instead of signal-based coordination. No locking, no multi-terminal awareness, no automatic pressure detection.

**[claude-code-context-sync](https://github.com/Claudate/claude-code-context-sync)** focuses on multi-window context synchronization — saving and resuming context across different windows. Useful for a different workflow, but no automatic detection or clearing.

The gap: every project solves one or two parts of the problem. None connect all four: automatic detection → structured handover → tmux clear → continuation injection. That's the closed loop I couldn't find and had to build. The full implementation is **[open source on GitHub](https://github.com/Vinix24/vnx-orchestration)** — including the hook chain, lock mechanism, and handover templates.

There are also multiple open feature requests on the **[Anthropic Claude Code repository](https://github.com/anthropics/claude-code)** asking for native solutions to this problem — from **[context window reset without session restart](https://github.com/anthropics/claude-code/issues/3314)** to **[session handoff and continuity support](https://github.com/anthropics/claude-code/issues/11455)** to **[context management CLI flags](https://github.com/anthropics/claude-code/issues/21388)**. The original **[hook-based /clear request (#9118)](https://github.com/anthropics/claude-code/issues/9118)** was closed as NOT\_PLANNED, and related issues like **[restoring blocking Stop command hooks (#3656)](https://github.com/anthropics/claude-code/issues/3656)** and **[/clear breaking transcript hooks (#3046)](https://github.com/anthropics/claude-code/issues/3046)** remain open. The demand is clear. The supply, for now, is community workarounds.

## The safety mechanisms

Running automatic context rotation in production requires more than just the happy path. Here's what I built to prevent things from going wrong:

**Atomic locking.** When the PostToolUse hook triggers rotation, it acquires a `mkdir`-based lock with timestamp-based stale detection (300-second TTL). This prevents double-rotation when multiple terminals try to rotate simultaneously. One terminal rotates; the others wait.

**Loop prevention.** The PreToolUse hook passes `Write`, `Read`, `Glob`, and `Grep` through unconditionally, even when context pressure is high. This is critical — without it, the hook would block the agent from writing the handover document, creating a deadlock where the agent needs to write a file to rotate but can't write a file because rotation is pending.

**Multi-terminal isolation.** Each terminal (T1/T2/T3) has independent pane resolution, lock files, and handover documents. T0 — the orchestrator — is excluded from rotation entirely. The orchestrator's context is long-lived by design and manages terminal coordination, so clearing it would break the system.

**Fallback chain.** The SessionStart recovery hook supports a `--fallback` parameter so worker terminals bootstrapping fresh tasks don't get confused by rotation recovery. A fresh dispatch shouldn't inherit a rotation handover from a previous task.

## What I learned about timing

The biggest surprise from production testing: 65% is already late. I'm now experimenting with rotation at 60% — even 55% for complex tasks where context quality is critical.

The reasoning: context quality doesn't degrade linearly. This aligns with the research — the "Lost in the Middle" paper showed that degradation accelerates in the later portions of the context window, not gradually across the full length. At 50% context usage, everything is fine. At 65%, you start losing nuance in the compacted regions. At 75%, the agent is noticeably worse — it starts re-reading files, contradicting earlier decisions. By 80%, Claude Code's auto-compaction fires and you've lost the war.

The sweet spot appears to be rotating when the context is still healthy — before you notice degradation, not after. It feels wasteful to clear a session that's still working well. But the handover quality is much higher when the agent writes it from a position of strength rather than under pressure. An agent at 60% context writes a clear, structured handover with specific details. An agent at 78% writes vague summaries and misses critical state.

I track every rotation event in the **[VNX receipt ledger](https://github.com/Vinix24/vnx-orchestration#receipt-ledger)** — the same append-only NDJSON file that logs all agent actions. This gives me data on rotation frequency, handover quality, and task completion rates before and after rotation. Early data suggests that proactive rotation (60-65%) produces better handover documents and faster task resumption than reactive rotation (75%+).

> **"The best time to rotate context is when you don't think you need to yet."**
> That's the counterintuitive lesson from six months of production data. An agent writing a handover at 60% context produces clear, structured state. At 78%, it writes vague summaries and misses critical details. Rotate from strength, not desperation.

Context quality curve showing sweet spot between 60-65%

## Known limitations

I want to be honest about what doesn't work perfectly.

**tmux timing race.** There's a small window (~1-2 seconds) after `/clear` where the terminal may not be ready for input. The rotator mitigates this with a settle delay and signal file, but it's not 100% deterministic. Occasionally the continuation prompt arrives before the session is fully initialized.

**Handover quality varies.** The handover document is written by Claude under context pressure. Sometimes the "Remaining Tasks" section is vague. Sometimes critical details are missing. The structured format constrains it enough to be usually useful, but "usually" isn't "always."

**No native Anthropic support.** This entire system exists because `/clear` can't be called from hooks (**[#9118](https://github.com/anthropics/claude-code/issues/9118)** — NOT\_PLANNED). If Anthropic ever adds **[native context management support](https://github.com/anthropics/claude-code/issues/3314)**, the tmux workaround becomes unnecessary — and good riddance. The workaround works, but it's fragile compared to what a native implementation could be.

**Skill context lost on /clear.** Active Claude Code skills are not preserved across rotation. The rotator re-activates the original skill via a `/{skill}` prefix on the continuation prompt, recovered from the original dispatch file. This works, but it means the skill reloads from scratch — any in-session skill state is lost.

## Try it yourself

Context rotation is part of the **[VNX Orchestration System](https://github.com/Vinix24/vnx-orchestration)** — an open-source toolkit for multi-agent terminal workflows. The rotation feature is opt-in:

You need Claude Code with hooks support, tmux, and Bash 4+. The full setup is three hook registrations in `.claude/settings.json` and one environment variable. The documentation covers the complete hook chain, file structure, and configuration options.

> 📖 **Read also:** **[Multi-Model AI Orchestration From a Single Terminal](/blog/multi-model-ai-orchestration-single-terminal)** — How I run Claude, Codex, and Gemini in parallel with unified governance

The dry-run demo (`demo/dry-run/replay.sh --fast`) shows the full governance pipeline — including context rotation — without requiring any LLM API calls.

## Quick wins before you need full rotation

Not every session needs the full rotation pipeline. Here are lighter context management strategies that reduce the rate of context rot:

**Use subagents for research.** Subagents run in separate context windows and return only summaries. Delegate file scanning, code reviews, or research tasks to subagents — your main context stays clean. But subagents don't solve the core problem: your main session still fills up during multi-hour implementation work. They reduce the *rate* of rot; rotation addresses the rot itself.

**Maintain a strong CLAUDE.md.** Your CLAUDE.md file persists across sessions — it's your *persistent* context layer. Architecture decisions, coding conventions, project structure — put it there so every session starts informed. But CLAUDE.md handles persistent knowledge; rotation handles *session* state. You need both.

**Use Plan mode for complex tasks.** Plan mode (think before acting) can reduce token usage by 30-40% on complex tasks because it structures reasoning before generating code. Fewer tokens consumed means slower context fill rate.

**Use skills for progressive disclosure.** Claude Code skills load 30-50 tokens initially and expand on demand — far cheaper than MCP servers that load their full schema upfront. Prefer skills over MCP for operations you invoke frequently.

These strategies buy you time. But for multi-hour production sessions — especially multi-agent workflows — automatic rotation remains the definitive solution.

## Context engineering: the bigger picture

Context rot isn't a Claude-specific problem. Every AI coding agent with a fixed context window will hit this wall. Cursor, Cline, Codex CLI, Gemini Code — they all operate within context limits, and they all degrade when those limits are reached.

This is part of a broader discipline emerging in the AI engineering community: **context engineering** — the practice of deliberately structuring what information reaches your model, when, and in what form. Martin Fowler recently wrote about this: the most impactful skill in AI-assisted development isn't prompt engineering, it's context engineering.

Automatic context rotation is one pattern within context engineering. Others include subagent delegation, progressive context loading, and structured handover contracts. The solution doesn't have to look like mine. But the pattern — detect pressure, checkpoint state, clear, resume — is universal. Whether it's implemented as hooks + tmux, or native IDE support, or a language server protocol extension, the need is the same: AI coding sessions need a way to rotate context without losing continuity.

For organizations looking to deploy AI agents in production, this challenge is amplified. **[Smaller companies adopting AI](/ai-voor-het-mkb)** especially need reliable, low-friction solutions — they can't afford to lose work due to context degradation.

Right now, most developers just accept context degradation as a fact of life. They restart sessions manually, lose progress, and re-explain their codebase from scratch. That's the equivalent of rebooting your computer every hour because it runs out of RAM. We can do better.

If you're hitting the context wall in your AI coding workflow, I'd be curious to hear how you handle it. And if you have ideas for improving automatic rotation — better handover formats, smarter timing heuristics, alternative clear mechanisms — the repo is open and I'm building in public.

## Frequently Asked Questions

### Why does Claude Code get dumber the longer I use it?

Claude Code operates within a 200K token context window. As you work, every file read, message, and tool result fills that budget. When it approaches capacity (~80%), auto-compaction kicks in — a lossy summary that drops nuance. The model doesn't change; your working memory shrinks. This is context rot. Symptoms: repeating work, contradicting earlier decisions, re-reading files already processed.

### What is auto-compaction in Claude Code and how does it affect my session?

Auto-compaction triggers when context usage hits roughly 80-95%. Claude summarizes older messages to free space. The tradeoff: a 50-line architectural discussion becomes one sentence. You keep working but the agent loses the *why* behind decisions. Some developers disable auto-compact entirely and manage context manually via `/compact` or `/clear`.

### How do I preserve context between Claude Code sessions?

Three common approaches: (1) Write a handover document before ending a session, then reference it in the next. (2) Use a SessionStart hook to auto-inject project state. (3) Use CLAUDE.md for persistent project context that survives across sessions. The most robust approach combines all three — which is what the VNX rotation pipeline automates.

### Should I use /clear or /compact when Claude Code's context fills up?

`/compact` summarizes and preserves some history — good for short sessions or simple tasks. `/clear` wipes everything — better for a true fresh start. The problem: both lose nuance. The ideal is to write a structured handover *before* clearing, so the next session starts with clean context plus your saved state. Automatic context rotation automates this entire flow.

### How do Claude Code hooks help with context management?

Hooks are shell commands that fire at specific lifecycle events (SessionStart, PreToolUse, PostToolUse). For context management: a PreToolUse hook can monitor context usage and block work when pressure is high. A SessionStart hook can inject context from a previous session. Combined, they enable automatic context rotation without manual intervention.

### What is the best context threshold for rotating a Claude Code session?

Counter-intuitively, earlier is better. At 60-65% context usage, the agent still writes clear, structured handovers with specific details. At 75%+, handover quality drops — vague summaries, missing state. Rotate before you notice degradation, not after. Claude Code's auto-compaction fires around 80%, so rotating at 65% gives enough headroom to complete the handover cleanly.

### Can I use subagents to avoid context rot in Claude Code?

Subagents run in separate context windows and return only summaries, keeping your main context clean. But subagents don't solve the core problem: your main session still fills up during multi-hour implementation work. Subagents reduce the *rate* of rot; context rotation addresses the rot itself. Use both together for maximum session longevity.

### Does context rot affect all AI coding agents, not just Claude Code?

Yes. Any AI agent with a fixed context window — Cursor, Cline, Codex CLI, Gemini Code — will degrade when that window fills. The "Lost in the Middle" research (Stanford, 2024) shows this is a fundamental LLM limitation: performance drops 15-47% as context grows. The solution pattern — detect, checkpoint, clear, resume — is universal regardless of the specific tool.

***

*If you're interested in the multi-agent system that context rotation is part of, read **[Glass Box Governance: How I Built a Self-Auditing Multi-Agent AI System](/blog/glass-box-governance-multi-agent-ai)** — where I explain the full orchestration architecture, receipt-driven audit trails, and why transparency beats trust in production AI.*

context rot claude code automatic rotation cover

large_context-rot-claude-code-automatic-rotation_cover

medium_context-rot-claude-code-automatic-rotation_cover

small_context-rot-claude-code-automatic-rotation_cover

thumbnail_context-rot-claude-code-automatic-rotation_cover

context-rot-claude-code-automatic-rotation_cover

Context Rot Is Silently Killing Your Claude Code Sessions — Here's How I Fixed It

## Introductie tot Claude MCP servers

In een eerdere blog schreef ik over mijn **[top 10 Claude MCP protocollen](https://vincentvandeth.nl/blog/Top10-Claude-MCP-Protocollen-AI-Agent)** over hoe je van Claude een heuse AI agent kan maken. Het installeren van deze MCP servers is een technisch verhaal maar ook voor niet technische mensen makkelijk te doen, kwestie van instructies volgen. Om het je nog makkelijker te maken heb ik een stap voor stap gids gemaakt waarmee je zelf MCP servers kan installeren voor Claude Desktop. 

Nadat je alle stappen hebt doorlopen heb je van jouw Claude Desktop een multifunctionele AI agent gemaakt en heb je geen no-code of andere agent frameworks nodig! 

Ook als je nu nog denkt aan een bus - of treinstation bij het woord terminal heb je na het lezen van deze blog al een stuk meer kennis over computersystemen. De installatiegids werkt voor zowel Mac, Windows en Linux gebruikers. 

## Claude Desktop installeren en configureren voor MCP protocollen

Voordat we beginnen is het belangrijk om te weten dat je alleen met Claude Desktop versie MCP servers kunt gebruiken, met de cloud versie kan dit niet! Download dus eerst de Claude Desktop versie van als je die nog niet gebruikt. 

**Belangrijk!** Het configuratie bestand waarvoor ik in deze blog de .json configuratie geef kun je vinden onder _Claude > Settings_. Dit is niet dezelfde settings als voor Claude Dekstop zelf. Mocht je de fout maken die ik in het begin maakt dan kun je daar zoeken tot je een ons weegt. In de Settings ga je naar de Developer tab en vind je Edit Config. Als je daar op klikt vind je het _claude_desktop_config.json_ bestand. Dat is het bestand wat je straks moet gaan aanpassen. 

**Let op bij het werken met privacy gevoelige informatie in verband met GDPR/AVG ook mijn blog over [GDPR/AVG risico bij MCP servers](https://vincentvandeth.nl/blog/cp-servers-gdpr-privacy-risicos-voor-marketeers-ondernemers) **

## De basis: Node.js installeren

Voordat we beginnen met het installeren van de MCP servers, moeten we eerst controleren of Node.js is geïnstalleerd. Node.js vormt de basis voor alle MCP server installaties.

### Stap 1: Download Node.js

Ga naar de Node.js website: **[https://nodejs.org/](https://nodejs.org/)**

**Tip:** Kies de "LTS" versie (Long Term Support). Dit is de meest stabiele versie en perfect voor de meeste gebruikers. Klik op de downloadknop voor uw besturingssysteem (Windows, macOS of Linux).

### Stap 2: Installatie uitvoeren

De installatie is grotendeels geautomatiseerd en eenvoudig te volgen:

- **Windows:** Open het gedownloade .msi bestand en volg de instructies. Accepteer de standaardinstellingen door op "Next" te klikken bij elke stap, en klik op "Finish" wanneer de installatie is voltooid.

- **Mac:** Open het .pkg bestand en volg de installatie-instructies. Accepteer de standaardinstellingen, klik op "Continue" en "Install". U moet mogelijk uw wachtwoord invoeren om de installatie te autoriseren. Klik op "Close" wanneer de installatie is voltooid.

- **Linux:** De installatieprocedure kan per distributie verschillen. Raadpleeg de Node.js website voor specifieke instructies voor uw Linux-versie onder "Installing Node.js via package manager": [https://nodejs.org/en/download/package-manager/](https://nodejs.org/en/download/package-manager/). Voor Debian/Ubuntu gebruikt u doorgaans `sudo apt-get install nodejs npm` en voor Fedora/CentOS/RHEL `sudo dnf install nodejs`.

### Stap 3: Controleer de installatie

Om te verifiëren dat Node.js correct is geïnstalleerd, opent u de terminal (of opdrachtprompt in Windows):

- **Windows:** Druk op de Windows-toets, typ "cmd" of "opdrachtprompt" en druk op Enter.
- **Mac:** Open Finder → Programma's → Hulpprogramma's → Terminal.
- **Linux:** Gebruik de sneltoets Ctrl+Alt+T of zoek "Terminal" in het applicatiemenu.






Typ de volgende commando's en druk na elke regel op Enter:

Als de installatie succesvol was, zie je versienummers verschijnen (bijvoorbeeld v20.18.2 en 10.8.2). Dit bevestigt dat Node.js correct is geïnstalleerd en klaar is voor gebruik.

## Het configuratiebestand vinden in Claude Desktop

Voordat we beginnen met het installeren van de MCP servers, is het belangrijk om te weten waar u het configuratiebestand kunt vinden dat we later gaan aanpassen.

1. Open Claude Desktop
2. Klik op het tandwiel-icoon voor **Instellingen**
3. Ga naar het menu-item **Developer**
4. Klik op de knop **Edit config**
5. Je configuratiemap opent nu in uw bestandsverkenner
6. In deze map vind je het bestand `claude_desktop_config.json` waarin we de MCP server instellingen gaan toevoegen

In Claude desktop vind je in het developers console de knop om het configuratie bestand te vinden

## 1. Memory Server: Behoud context en bespaar tokens

**Wat het doet:** De Memory Server onthoudt de context van uw gesprekken met Claude, waardoor u tokens bespaart en de continuïteit in langere projecten behouden blijft.

### Stap-voor-stap installatie:

1. Open een nieuwe terminal (of opdrachtprompt)
2. Voer het volgende commando uit:







3. Voeg de server toe in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. Vul bij /path/to/custom/ de folder in waar je hem wilt hebben (Bij mij bijvoorbeeld /Users/vincentvandeth/Desktop/Development/MCP)

### JSON Configuratie:

### Testen:

Start een nieuwe chat met Claude. Bespreek een onderwerp, sluit Claude Desktop af, open het opnieuw om het geheugen te activeren. Voer een gesprek met Claude en vraag hem om het gesprek in het geheugen op te slaan. Claude slaat niet automatisch alles op. In een volgende gesprek verwijs je Claude naar het geheugen en heeft hij meteen de context van het gesprek te pakken. 

Ik schrijf een aparte blog over hoe je efficient met het geheugen kan werken. Als je in de tussentijd vragen hebt mail me of stuur me een bericht op **[Linkedin](https://www.linkedin.com/in/vincentvandeth/)**

## 2. Filesystem Server: Directe toegang tot je bestanden

**Wat het doet:** De Filesystem Server geeft Claude directe toegang tot bestanden op uw computer, ideaal voor het bewerken van documenten of het verfijnen van code.

### Stap-voor-stap installatie:

1. Open een nieuwe terminal (of opdrachtprompt)
2. Voer het volgende commando uit:

3. Voeg de server toe in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. Vul bij /Users/jouwgebruikersnaam de folder in waar je hem wilt hebben 

Bij mij bijvoorbeeld:

Users/vincentvandeth/Desktop/Development/VNXcrawlerdevelopment/
Users/vincentvandeth/Desktop/Development/vinix-marketing/folder1/

Let goed op op welke folders je rechten geeft want dat zijn de folders waarin Claude kan zoeken, lezenk, schrijven, nieuwe folders aanmaken etc. Als je documentatie hebt met privacy gevoelig info die niet selecteren. 


### JSON Configuratie:   







**Belangrijk voor Mac en Linux gebruikers:** Het kan nodig zijn om in uw privacy-instellingen expliciet toegang te verlenen tot bepaalde mappen. Controleer de instellingen voor 'Bestanden en Mappen' als u problemen ondervindt.

### Testen:

Maak een tekstbestand in de geselecteerde map. Start een nieuwe chat met Claude en vraag: "Kun je het bestand [bestandsnaam] in de map [mapnaam] lezen?". Als Claude de inhoud kan lezen, werkt de Filesystem Server correct.

Handige tip: Vraag Claude in een prompt om bepaalde bestanden te lezen als achtergrond informatie. Je kunt Claude opdracht geven rechtstreeks in toegestane folders wijzigingen aan te brengen. Dit werkt ook voor bestanden die code bevatten. 

## 3. Brave Search Server: Realtime webinformatie

**Wat het doet:** Integreert Brave Search, een privacy-vriendelijke zoekmachine, direct in Claude voor efficiënt webonderzoek.

### Stap-voor-stap installatie:

1. Open een nieuwe terminal (of opdrachtprompt)
2. Voer het volgende commando uit:

3. Voeg de server toe in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. Vul bij API sleutel de API sleutel in die je van de website van Brave Search gratis kan halen

### Testen:

Start een nieuwe chat met Claude en vraag: "Zoek op internet naar de laatste trends in digitale marketing". Als Claude recente informatie van het web teruggeeft, werkt de Brave Search Server correct.

## 4. Perplexity Search Server: Diepgaand onderzoek

**Wat het doet:** Integreert Perplexity AI voor diepgaande, gecureerde zoekresultaten, perfect voor serieuze marktanalyse.

#### Stap-voor-stap installatie:

1. Open een nieuwe terminal (of opdrachtprompt)
2. Voer het volgende commando uit:

3. Voeg de server toe in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. Vul bij API sleutel de API sleutel in die je van de website van Perplexity haalt. Deze is helaas niet gratis maar zeer de moeite waar omdat Claude zelf instructies kan geven aan Perplexity en zo altijd de informatie zoekt die relevant is voor de opdracht waar je mee bezig bent. 

### JSON Configuratie:

### Testen:

Start een nieuwe chat en vraag Claude: "Zoek met Perplexity naar de impact van AI op de e-commerce industrie". Vergelijk deze resultaten met een reguliere zoekopdracht om het verschil in diepgang te zien.

## 6. GitHub Server: Codebeheer voor tech-professionals

**Wat het doet:** Integreert GitHub-functionaliteit in Claude, ideaal voor code generatie, review en beheer.

### Stap-voor-stap installatie:

1. Open een nieuwe terminal (of opdrachtprompt)
2. Voer het volgende commando uit:

3. Genereer een GitHub Personal Access Token:

1. Ga naar je Github profiel naar _Settings_
2. Ga naar <> Developer settings helemaal onderaan de lijst
3. Kies Personal acces tokens > fine grained tokens
4. Generate new token
5. Vink tenminste  'Read access to codespaces metadata and metadata,
read and Write access to actions, administration, code, commit statuses, pull requests en workflows aan.



### Toevoegen in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. Vul bij GITHUB_TOKEN het token in wat je op de website van Github hebt gehaald.  

### JSON configuratie:

### Testen:

Start een nieuwe chat en vraag Claude: "Geef overzicht open issues in GitHub repository [gebruikersnaam]/[repository-naam]"

Tip: Maak een fine grained token dan kun je precies instellen wat Claude wel en niet mag doen hierdoor voorkom je dat Claude dingen kan inzien of bewerken die misschien gevoelig zijn. 

**Let op bij het werken met privacy gevoelige informatie in verband met GDPR/AVG ook mijn blog over [GDPR/AVG risico bij MCP servers](https://vincentvandeth.nl/blog/cp-servers-gdpr-privacy-risicos-voor-marketeers-ondernemers) ** 

## 7. ArXiv Search Server Installeren

**Wat het doet:** Integreert ArXiv, het archief voor wetenschappelijke papers, in Claude voor diepgaande research.

### Stap-voor-Stap Installatie:

Deze is iets ingewikkelder dan de andere servers omdat je hiervoor het project op Githubn nodig hebt. Als je stap 6 succesvol hebt afgerond dan kun je gewoon Claude vragen om de server te clonen en je door de installatie te leiden. 

Heb je geen Github? Geen probleem. Het kan ook handmatig:

1. Maak een folder aan waar je de server wilt hebben: /users/jouwnaam/ArXiv bijvoorbeeld
2. Open een terminal en type: cd //users/jouwnaam/ArXiv uit het vorige voorbeeld. Je zou nu in de terminal moeten zien dat je in die map staat (zie schermprint waar ik /users/vincentvandeth/desktop/development heb gebruikt. 
3. Kopieer dit commando in je terminal. Die haalt ArXiv op van Github:

### Toevoegen in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. Vul jouw API key in die haal je **[hier](https://info.arxiv.org/help/api/index.html)**

### JSON Configuratie:

### Testen:

Start een nieuwe chat en vraag Claude: "Zoek op ArXiv naar recente papers over AI in medical diagnostics"

## 8. Google Search Server Installeren

**Wat het doet:** Integreert Google Search in Claude voor maximale zoekdekking.

### Stap-voor-Stap Installatie:

1. Open een nieuwe Terminal of Opdrachtprompt
2. Installeer met NPM:

### Google Custom Search Engine Configureren:

1. Ga naar de [Google Custom Search Engine website](https://programmablesearchengine.google.com/)
2. Maak een Custom Search Engine aan
3. Genereer een API Key en Search Engine ID via de Google Cloud Console

### Toevoegen in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. API Key: Vul jouw Google Custom Search Engine API Key in
4. Search Engine ID: Vul jouw Google Custom Search Engine ID in
5. Ingeschakeld: Aanvinken
6. Klik op 'Opslaan'

### JSON Configuratie:

## Testen:

Start een nieuwe chat en vraag Claude: "Google: Zoek naar recente ontwikkelingen in digitale marketing"

## 9. WolframAlpha Server Installeren

**Wat het doet:** Integreert WolframAlpha in Claude voor complexe berekeningen en datavisualisatie.

### Stap-voor-Stap Installatie:

Net als ArXiv heb je voor Wolfram Alpha de repository van Github nodig. Als je stap 6 succesvol hebt afgerond dan kun je gewoon Claude vragen om de server te clonen en je door de installatie te leiden. 

Heb je geen Github? Geen probleem. Het kan ook handmatig:

1. Maak een folder aan waar je de server wilt hebben: /users/jouwnaam/Wolfram Alpha bijvoorbeeld
2. Open een terminal en type: cd //users/jouwnaam/ArXiv uit het vorige voorbeeld. Je zou nu in de terminal moeten zien dat je in die map staat (zie schermprint waar ik /users/vincentvandeth/desktop/development heb gebruikt. 
3. Kopieer dit commando in je terminal. Die haalt Wolfram Alpha op van Github:

### WolframAlpha API Key Genereren:

1. Ga naar de [WolframAlpha website](https://developer.wolframalpha.com/)
2. Maak een account aan en vraag een API Key aan

### Toevoegen in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. API Key: Vul jouw Wolfram Alpha key hier in


### JSON Configuratie:

### Testen:

Start een nieuwe chat en vraag Claude: "WolframAlpha: Bereken ROI met investering €10.000, opbrengst €25.000, visualiseer in taartdiagram"

## 10. DuckDuckGo Search Server Installeren

**Wat het doet:** Integreert DuckDuckGo, een privacy-vriendelijke zoekmachine, in Claude.

### Stap-voor-Stap Installatie:

1. Open een nieuwe Terminal of Opdrachtprompt
2. Installeer met NPM:

### Toevoegen in Claude Desktop:

1. Open het configuratie bestand via _Claude>Settings_ in de menubar. 
2. Ga naar het developer console
3. Op het configuratie bestand
4. Voeg onderstaande regel toe in het .json bestand
5. API Key: Niet nodig

### JSON Configuratie:


### Testen:

Start een nieuwe chat en vraag Claude: "DuckDuckGo: Zoek naar privacy-vriendelijke zoekmachines"

## Complete JSON Configuratie

Nadat je meerdere servers hebt toegevoegd, ziet uw servers sectie in de config.json file er ongeveer zo uit:

**Belangrijk:** Vervang alle placeholders (UW_API_KEY, UW_GITHUB_PERSONAL_ACCESS_TOKEN, etc.) en voorbeeldpaden met je eigen API keys, tokens en bestandspaden. U kunt deze JSON direct aanpassen in het "JSON Bewerken" tabblad in Claude Desktop (MCP Servers instellingen).

## Conclusie

Gefeliciteerd! Je hebt Claude Desktop uitgebreid met 10 krachtige MCP servers. Deze uitbreidingen maken Claude tot een super AI agent. Experimenteer met deze nieuwe mogelijkheden om te ontdekken hoe ze jouw workflow kunnen optimaliseren.

De MCP community blijft groeien, en er komen regelmatig nieuwe servers beschikbaar. Houd mijn blog in de gaten voor updates over de nieuwste ontwikkelingen.

### Disclaimer

Wees altijd voorzichtig met het installeren van software en het verlenen van toegang tot uw bestanden en online accounts. Gebruik servers van vertrouwde bronnen en lees de documentatie zorgvuldig door. Veiligheid staat voorop!


---

Heb je vragen of hulp nodig bij het installeren? Stuur me een mail of berichtop **[Linkedin](https://www.linkedin.com/in/vincentvandeth/)**


Claude Code

Claude Agent Teams vs. Building Your Own: What Anthropic Solved (And What They Left Out)

Context Rot Is Silently Killing Your Claude Code Sessions — Here's How I Fixed It

Hoe moet ik Claude MCP servers installeren? Een stap voor stap gids