Is source code alone enough context for coding agents, or do they also need our docs, tickets and chat?

Source code is enough context for coding agents on small, self-contained work, and not enough for most of the rest. Code tells an agent what the system does right now. It cannot explain why it behaves that way, what the team already tried, what was agreed last week, what the task is for, or who currently owns the module. Off-repo context is the knowledge a change depends on that was never written into the repository: the reasons, history, decisions and ownership that live in tickets, pull requests, docs and chat. Developers report the same gap. The 2026 Stack Overflow survey asked 12,678 developers which context they need their AI to consider at work. Project goals or requirements came first (85.2%), code, repositories or documentation second (73.3%) and prior decisions and rationale third (44.0%) (Stack Overflow 2026 survey). Only 2.1% said they do not usually need additional context (Stack Overflow, 2026).

What the code does tell an agent#

More than many teams expect. Anthropic's Claude Code guide says Claude begins every task by reading the code, calling current models "very good at" it. Claude identifies "your file layout, your conventions, your test framework, and how existing components are built" (Claude Code best practices). Explaining directory structure or naming conventions to a modern agent is usually unnecessary.

That makes code alone sufficient for a real class of tasks. Examples include a bug with a failing test, a refactor inside one module, or an endpoint that copies its neighbors. In each case the answer to "what should this look like?" is already on disk.

The same page draws the line. What Claude cannot find "is the information that was never in the repo," and it offers three examples:

• A decision the team made in a meeting.
• A deploy process that lives in one person's head.
• The environment variable the integration tests need.

What code cannot tell an agent: reasons and history#

Design rationale is the reasoning behind a choice in the code: the constraint, the incident or the tradeoff that made the team pick it. The cases below are invented. In each one the code is correct and the agent still errs.

Why it works that way. For example, a function sleeps 200 milliseconds before every call to a payments partner. To an agent it looks like an obvious bug, so it removes the delay. The reason sits only in a support ticket from last spring: the partner throttles bursts and returns errors disguised as success.

What was tried and rejected. Consider a team that moved order sync onto a queue, hit duplicate charges and reverted. The agent proposes the identical queue again. git blame annotates each line "with information from the revision which last modified the line" (git-blame docs), which here is a commit titled "Revert". The reason lives in the incident channel.

What code cannot tell an agent: decisions, intent and ownership#

The same gap shows up for anything still in motion. Again, the cases are invented.

What was decided but not yet done. Last week in Slack the team agreed to retire an old date library. It is still imported in hundreds of files, so the agent dutifully copies it into new code. Anthropic's guide names this trap, "an old pattern that's everywhere but that new code must not copy," as something worth putting in CLAUDE.md.

What the task is for. "Add export to CSV" could mean ten different features. The ticket specifies which: who requested it, which columns, and what counts as done. GitHub's guide for its Copilot coding agent asks for "Complete acceptance criteria on what a good solution looks like" and says "it's useful to think of the issue you assign to Copilot as a prompt" (GitHub Docs).

Who owns it, and what is changing. A CODEOWNERS file names "individuals or teams that are responsible for code in a repository" (GitHub Docs). It does not mention that the owning team is halfway through replacing the service, or that the named owner left in June. So the agent carefully polishes code scheduled for deletion.

None of these is a model failure. The code did not hold the answer. Why was this built this way? covers more cases.

Where each answer actually lives#

Code answers one row. The remaining answers are scattered across several systems, and the most recent one usually sits in the least formal location.

How to give agents the rest without dumping everything in#

Find your own gaps first: pull the last ten agent tasks that needed a second pass and ask, was the missing fact in the code? If most misses were reasons, reverts, decisions or acceptance criteria, longer prompts will not help. Connect the systems where those facts live.

A rules file is a markdown file such as CLAUDE.md or AGENTS.md that the agent loads at the start of every session. Anthropic's test before adding anything to it: "Could it find this by reading the code?" and "Would it actually go and look?" If both are yes, leave it out. CLAUDE.md vs AGENTS.md vs Cursor rules covers which file each agent reads.

Slack threads and open tickets will not fit in a rules file. For those, Anthropic notes "some of what Claude can't see lives in another system entirely, like your issue tracker," and points to CLIs and MCP servers as the way in. One server per system works for a small team; past that, see what goes wrong when everyone connects their own MCP servers.

Unblocked's research tool covers that gap. It runs "multi-source research across code, PRs, docs, issues, and messaging" and "returns a synthesized answer with citations" (Unblocked docs). It works in Claude Code, Cursor, Copilot, VS Code and JetBrains, and with Data Shield on, answers "only contain source material that the user posing the question is authorized to access" (Data Shield docs). Setup for each agent is in one MCP for Claude Code, Codex and Devin.