Your Agent Isn’t Dumb. It’s Just Lost.

We were building a system that assembled project updates from where work happens: messages, email, meetings, documents, and task trackers. It had the right tools and could search across sources. But it still produced a confident update grounded in the wrong evidence: it found a nearby conversation, cited it cleanly, and missed the decision that mattered.

The model was not failing to reason. It was reasoning over an unmapped workspace.

After a few rounds of prompt tuning and tool-description rewrites, content accuracy plateaued at 64%. The model was reasoning correctly over the wrong context, with no clean fix short of restructuring the layer underneath.

Two design changes made the difference: a Table of Contents built directly into the MCP tool layer, so the planner reads actual content instead of tool docstrings, and an Auto Atlas of the project, an LLM-maintained, source-cited, structured view of who the people are, what the workstreams are, and where everything stands. The agent reads it instead of re-deriving the project state every turn. The TOC/planner split increased report content accuracy from 64% to 91%, with similarly large gains in grounding and concreteness. Auto Atlas solved the longer-horizon problem separately, taking cross-time Q&A accuracy from 58% to 89%. The architecture is a worked example of context engineering applied to multi-source agentic synthesis.

The Problem

On one of our projects, the output surfaces were familiar. Weekly executive reports for leadership: where the project stands, what shipped, what's at risk, what got decided last week. A project chat for everyone on the team: any question about the project (who owns this?, when did we decide that?, what's the current status of X?) answered with source citations. The raw activity is scattered across Slack, email, calendar, Jira, Linear, Drive, meeting notes.

This setup breaks the standard tool-using agent pattern in a specific way: the planner agent has to decide what to fetch before it knows what's there. With a wide tool surface and a sparse-signal corpus, the planning step is where most of the error lives.

The Trap: Tools Expose APIs, Not Contents

The default MCP shape exposes each connected system's underlying API: search_slack_messages, list_recent_emails, get_jira_issue. The agent picks tools from docstrings and iterates. The code-execution-with-MCP pattern names one cost of this shape: tool definitions and intermediate results burn context. We hit a different one. The planner has no view of the content before committing to a search strategy. It reads "search_slack_messages: returns Slack messages matching a query" and has to guess what to query for.

On our internal eval, where humans scored generated reports against the underlying source data and human written reports, the baseline looked like this:

Several rounds of prompt and tool-description tuning only managed to take us to 64% content accuracy. The model was reasoning correctly over the wrong context, and we had no clean handle to fix that.

The Insight: Two Missing Maps

The agent was failing upstream of writing the weekly report, at deciding what to read. It had no global view of what data existed in the current window, and no model of the project itself. What it lacked were two maps.

A human writing the same report wouldn't guess search queries against tool docs. They'd skim. Scan channel headers, glance at email subjects, look at the Jira board. Build a mental table of contents of what happened in the period. And they wouldn't approach the project as a stranger either. They'd already know who the people are, what the workstreams are, what was decided last quarter, what's currently at risk. Both kinds of context are required for the writing step to land right. Our agent had neither.

That reframing produced two architectural moves, one for each missing map.

Move 1: Tables of Contents in the MCP Tool Layer

We rewrote the tool layer with one rule: tools split by abstraction level, not by data source.

• Overview tools bulk-assemble the structure of a source over the active window: channel summaries with thread IDs, email subjects with thread keys, ticket titles with current status, doc titles with summaries. No full bodies. The union of all overview tools over a typical window is sized to fit in one LLM context.
• Detail tools are the traditional fetches: get this thread, this body, this comment chain, this doc.

We call this overview output the Table of Contents: a comprehensive, structured, lightweight view of the window with reference IDs that resolve to detail-tool calls. Not similarity-ranked, but comprehensive by construction. Not embeddings, IDs that hydrate via the same MCP layer.

A TOC entry looked roughly like this:

{
  "ref": "meeting:2026-05-18:platform-readiness",
  "source": "meeting",
  "period": "IN",
  "title": "Platform readiness review",
  "summary": "Team confirmed the rollout plan, identified API throughput as the main launch risk, and assigned follow-ups for load testing and partner comms.",
  "signals": ["decision", "risk", "owner_change"],
  "related_refs": [
    "task:load-test-plan",
    "doc:partner-launch-checklist",
    "chat:api-throughput-thread"
  ]
}

The important part was not the summary. It was the handle.

The planner no longer had to ask, 'What should I search for?' It could plan directly against the shape of the window.

For instance, for the risks section:

• Inspect meeting:2026-05-18:platform-readiness.
• Follow task:load-test-plan for current status.
• Check chat:api-throughput-thread for unresolved concerns.
• Use doc:partner-launch-checklist only for launch-readiness context.

Then the report writer received that research brief and used detail tools to hydrate the exact refs. The TOC remained lightweight, the writer still fetched the underlying source material before making claims. That separation became the core contract: overview tools tell the planner what exists, detail tools give the writer the evidence, and citations come only from hydrated source material.

Same eval, after the split:

Most of the variance in multi-source agents lives in the planning step. Giving the planner the TOC instead of tool docstrings is what fixed it. Recent work on tool design for agents reaches a similar conclusion from a different angle: the bottleneck isn't model capability, it's the surface area the model has to reason over.

Move 2: An Auto Atlas for the Project Itself

The TOC gives the agent a map of the data from the current window. What it doesn't provide is a model of the project itself. That's the gap Auto Atlas fills.

Auto Atlas is the project's long-term knowledge artifact. The chat surface queries it for cross-time questions (who owns the migration?, what did we decide about region-scoping in September?, is the launch on track?). The report writer draws on it as well: who the people are, what the workstreams are, what was decided last quarter, what's at-risk now.

For the artifact itself, we built on the Auto Wiki framing: an LLM should incrementally compile raw sources into a persistent, source-cited artifact rather than re-derive knowledge on every query. Our version, which we call an Auto Atlas, keeps that operational frame (compile once, keep current) and replaces free-form markdown pages with typed primitives at every level: typed facts, typed clusters, typed snapshots, typed retrieval. The pipeline:

• Typed atomic facts. Each refresh, an LLM stage reads the new period's activity and extracts typed facts: decisions, blockers, todos, in-progress items. Each carries the source ID and an evidence span. Every downstream claim traces back to a specific message, email, or doc line.
• Auto-emergent workstreams. Facts cluster into ongoing tracks of work (Auth Migration, Q1 Launch, Pricing Refresh) that the system discovers and maintains. No hand-curated taxonomy. Closer in spirit to GraphRAG community detection than to schema-driven KG extraction.
• Versioned snapshots. Each refresh merges the prior snapshot with the period's outputs to produce the updated project picture: status per workstream, recent decisions, open blockers, key dates, the people graph. Old facts age out.
• Attention queue. Items flagged for human confirmation (stale, missing, conflicting, or ambiguous) surface in the UI instead of quietly becoming assumptions in the Atlas.

On top sits a retrieval layer. The retrieval planner generates concrete graph questions, executes structured reads against the Auto Atlas, and synthesizes the result shaped to the consumer's purpose.

The practical payoff for the report writer: when the TOC says "three commits and a design doc landed on auth migration this week", the Auto Atlas tells the writer that auth migration has been running two quarters, that it's currently flagged at-risk, that the lead is the same person who flagged the blocker in September, and that the workstream owns four open decisions. The TOC tells the writer what happened recently. The Auto Atlas tells it what it means.

Cross-time Q&A eval, on questions whose answer depends on activity older than the current window:

The TOC walkback is what you'd build if you only had Move 1. It scales poorly for cross-time questions, both because of context rot in the accumulating window, and because most cross-time answers aren't in any single window. They're synthesized across many.

Conclusion

Don't ask the agent to figure out the context. Build the context, then call the agent.

Most of the bad outputs we saw weren't reasoning failures. They were the model reasoning correctly over the wrong context, because its only window into the world was a list of tool docstrings. The fix was structural: a TOC tier in the MCP layer for the active window, and an Auto Atlas for the project itself. One retrieval surface, many consumers.

Key Takeaways:

• Split MCP tools by abstraction level. The overview tier carries content,the detail tier carries bodies. The overview is the Table of Contents the planner reads.
• Plan against content, not tool docs.
• Two horizons, one retrieval surface. Per-window TOCs and a long-running Auto Atlas solve different problems and serve different consumers, but share one purpose-typed retrieval interface.
• Build an Auto Atlas: typed all the way down, source-cited, and continuously updated. Every surface reads from it.

Build the maps. Then let the agent walk them.

References

• Anthropic, Effective context engineering for AI agents (Sep 2025). https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic, Writing effective tools for agents — with agents (Sep 2025). https://www.anthropic.com/engineering/writing-tools-for-agents
• Anthropic, Code execution with MCP: Building more efficient agents (Nov 2025). https://www.anthropic.com/engineering/code-execution-with-mcp
• Hong, K., Troynikov, A., Huber, J. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research (Jul 2025). https://research.trychroma.com/context-rot
• Karpathy, A. LLM Wiki (Apr 2026). https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Edge, D., et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. (2024). https://arxiv.org/abs/2404.16130