# Why Wouldn't Claude Code Handle Your Org Context Itself?


URL: https://getunblocked.com/blog/why-not-just-claude-code/
Published: 2026-08-19T10:00:00Z
Author: Dennis Pilarinos
Categories: Context Engine, AI Agents

Claude Code ships CLAUDE.md, auto memory, and MCP. But across 50 repos, Slack, and Jira, organizational context is infrastructure, not an agent feature.

---
The scene repeats in almost every evaluation we sit in on. Three weeks into a Claude Code rollout, the pilot team is happy, and someone proposes adding a context engine. The CTO looks up from the deck and asks, near-verbatim: "Why wouldn't Claude solve this problem? Why would we need a third-party solution?"

It's the right question, and it deserves a straight answer rather than a vendor dodge. So here it is. Claude Code is genuinely closing context gaps: CLAUDE.md, auto memory, subagents with their own memory, skills, MCP. For a solo developer on one repository, the built-ins are often enough, and we'll say so explicitly below. What Claude Code structurally won't become is the org-wide, cross-tool, permission-aware synthesis layer, because that's infrastructure, not an agent feature. An agent reads context. Something still has to decide what's true across 50 repositories, Slack, Jira, and Confluence, for every agent and every engineer, with permissions enforced. Whether Claude Code needs a context tool comes down to whether that job exists at your scale. Let's take it apart honestly.

## What can Claude Code already do about context?

More than most third-party pitches admit. Per the living [Claude Code memory docs](https://code.claude.com/docs/en/memory), CLAUDE.md files now carry persistent instructions at four scopes: an org-wide managed policy file IT can deploy via MDM, user-level preferences, project files shared through version control, and gitignored local overrides. A `.claude/rules/` directory splits instructions into topic files, and rules can be path-scoped so they only load when Claude touches matching files. Auto memory lets Claude write its own notes per repository, loading the first 200 lines or 25KB of its MEMORY.md index into every session, with topic files read on demand. [Skills](https://code.claude.com/docs/en/skills) package procedures that load only when invoked. [Subagents](https://code.claude.com/docs/en/sub-agents) can maintain their own persistent memory. And [MCP](https://code.claude.com/docs/en/mcp) connects the agent to Jira, Sentry, Postgres, or anything else speaking [the protocol](https://modelcontextprotocol.io/). If your mental model is one flat CLAUDE.md fighting for [context window space](/blog/claude-code-context-window/), it's a year out of date. Any honest case for a context tool has to start from this baseline, not a strawman.

## Where do the built-ins stop?

At the boundary between one engineer's setup and the organization's truth. Auto memory is explicitly per-machine: the docs state files "are not shared across machines or cloud environments," so the lesson Claude learned debugging your teammate's flaky ingestion job never reaches your session. CLAUDE.md is per-repo and hand-maintained; across 50 repositories that's 50 files that [rot independently](/blog/claude-code-forgets-codebase/) and need [syncing against AGENTS.md and .cursorrules besides](/blog/keeping-claude-md-agents-md-cursorrules-in-sync/). There's no conflict resolution: the docs warn that when two rules contradict each other, "Claude may pick one arbitrarily." And there's no cross-source permission model. Each MCP server is its own credential with its own access rules; nothing checks whether the engineer driving the agent should see what a connector returns from another system. That's the Claude Code organizational context problem in one sentence: every mechanism is scoped to a user, a machine, or a repo, while the truth you need is scoped to the org. The agent re-derives that truth from scratch every session, at inference time, and gets it differently each run. [Rules files can't close that gap](/blog/rules-files-vs-context-engine/) by getting longer.

## Won't Anthropic just build this?

They'll keep building, and the built-ins will keep improving; betting against that would be foolish. But look at what they ship: managed CLAUDE.md, subagent memory, an `/init` that reads your Cursor and Copilot rules, an `/import` that carries over a whole agent config. Every feature makes Claude Code better at consuming context. None of them makes Claude Code the arbiter of organizational truth, because that layer is vendor-neutral infrastructure and your org isn't single-vendor. [Pragmatic Engineer's March 2026 tooling survey](https://newsletter.pragmaticengineer.com/p/ai-tooling-2026) of 900+ engineers found 70% use two to four AI tools simultaneously, and 15% use five or more. [JetBrains' January 2026 data](https://blog.exceeds.ai/ai-coding-tools-adoption-rates/) shows Copilot, Cursor, and Claude Code splitting workplace usage 29/18/18. Your team runs Claude Code and Cursor and CI review agents today, and will run something else in eighteen months. The layer that knows what's true has to outlive any one agent choice, the way your identity provider outlives any one SaaS app. Anthropic optimizing that layer for Claude alone would make it worse at its actual job. That's why [team memory belongs in a hub, not an agent](/blog/team-memory-hubs-ai-agents/).

## What does a context engine actually add?

This is where Unblocked sits: institutional context for coding agents, built as infrastructure rather than as a feature of any one of them. [A context engine](/blog/what-is-a-context-engine/) ingests your repos, Slack, Jira, Confluence, support knowledge base, and docs continuously, resolves aliases and contradictions at ingestion time, and serves synthesized, cited, permission-enforced answers to [any agent that asks](/blog/unblocked-context-engine-for-agents/), over a single MCP connection. The agent stops being the integration layer; the organizational knowledge layer does the assembly before a token hits your context window. One customer put it better than we can:

> You cannot make coding agents work without domain and functional context. We connected and trained Unblocked on our Code repos, Atlassian tools, Internal docs, Product Documentation, KB from Support and Slack history. When an agent asks a question, it gets the full picture — not just the code analysis, but also why decisions were made and what the constraints are. Other tools like Copilot know only the code. That's limited value. Unblocked is a game changer for Coding Agents.
>
> — Raphael Bres, CTO, Tradeshift


Note what he connected: six source families, exactly the surface no per-repo file reaches. And note the phrase "when an agent asks," singular mechanism, plural agents: the same engine answers Claude Code, Cursor, and whatever runs in CI, identically, with each requester seeing only what its human is entitled to see. That's what it means to give Claude Code organizational context instead of asking it to reconstruct some approximation per session.

## When are the built-ins genuinely enough?

Honestly: often. If you're a solo developer, or a small team living in one repository with decisions that fit in a couple hundred lines of CLAUDE.md, you don't need us. Keep a tight project CLAUDE.md, let auto memory accumulate what it learns, add a [well-chosen MCP server or CLI tool](/blog/when-to-use-mcp-vs-cli/) for the one external system you touch, and revisit when something breaks. Even [dedicated memory MCP servers](/blog/memory-mcp-servers-compared/) are overkill at that scale. The trouble starts on predictable thresholds: multiple repos with shared conventions, decisions living in Slack threads and Jira comments instead of the repo, engineers whose agents answer differently because their private memories diverged, or a compliance team asking who can retrieve what. A useful tell: count how often an agent's answer gets corrected in review with information that existed somewhere but not in the repo. Once that's weekly, the gap is organizational, not personal. Below those thresholds, saying Claude Code needs a context tool would be selling you something. Above them, the built-ins aren't failing; they were never scoped for the job, and no amount of CLAUDE.md gardening rescopes them.

## FAQ

### Is CLAUDE.md enough organizational context for Claude Code?

For one repo and one team, usually yes. It stops scaling when conventions span repositories, when the reasoning behind decisions lives in Slack and Jira rather than in files anyone maintains, and when contradictions accumulate that nothing resolves. A checked-in file records what someone remembered to write down; [institutional memory](/blog/claude-code-institutional-memory/) is mostly the things nobody did.

### Can MCP servers give Claude Code organizational context on their own?

They give it access, which is different. A Slack MCP returns Slack messages; a Jira MCP returns tickets. Your agent still does the cross-source assembly at inference time, on your token bill, guessing at project nicknames it has never seen and not knowing which of two conflicting answers is current. Connectors are the transport for organizational context, not the source of it. The synthesis has to happen somewhere, and an agent's context window is the most expensive possible place.

### Does a context engine replace CLAUDE.md or auto memory?

No. Keep CLAUDE.md for repo-specific instructions and auto memory for personal working notes; they're good at that, and the docs keep making them better. When people ask whether Claude Code needs a context tool, they usually picture a replacement. It's a foundation: the shared, permission-aware layer the per-repo files silently assume, the thing that knows what the org actually decided, across every repo and every tool, for every agent and engineer.

## The one-question test

When the question comes up in your own eval meeting, you don't need our framing or Anthropic's roadmap. Ask one thing: when two sources disagree about how your systems work, what decides which one the agent believes? If the answer is "the engineer notices and fixes it," you're describing the per-repo world, and Claude Code's built-ins will carry you for a while. If the answer needs to hold across 50 repos, four tools, and 200 engineers with different access rights, you've just specified infrastructure: ingestion, synthesis, conflict resolution, permission enforcement, and citations so a human can audit the answer. That spec doesn't shrink because the agent got smarter. And the agent can't grant it to itself, any more than an app can be its own identity provider. So the CTO's question has a clean answer after all. Anthropic will keep making the agent better at reading context, and you should use every bit of it. Someone still has to decide what that context says, and make your organization legible to every agent you'll ever run.