How do I give coding agents the right context from Slack, Jira and Google Docs without dumping everything in?

Choose the right context per task, not per source. The right context for coding agents is the few passages that change what the agent will write for this ticket. That means the Jira issue, the Slack thread where the approach was argued, and the two paragraphs of the design doc that still hold. Everything else stays one link away. Task-scoped context is context picked for one task by four tests: scope (which service, repo or component), recency (what changed lately), rank (which source wins when they disagree) and size (a cited passage instead of a whole document). You can apply those tests yourself with filters at each source, or let a context engine apply them before the agent sees anything.

What "right" means for one task#

For example, say the task is to add retries to the billing webhook handler. The right context is the open ticket and the incident that caused it. Add the Slack thread where the team capped retries at three, and the retry section of the billing design doc. The wrong context is the whole #billing channel, every billing ticket since 2023 and the full 40-page design doc.

Extra text costs accuracy as well as tokens. Anthropic's docs put it plainly: "As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what's in context just as important as how much space is available" (Claude docs). A March 2026 paper reports the same thing from the research side: LLMs show "significant performance degradation as context length increases" (Cao et al., arXiv). Context rot is that loss of accuracy as the window fills, and it is why the goal is the fewest passages that would change the code.

To check whether an agent has the right context, pick three tickets where the plan changed in Slack after the doc was written. Ask the agent for the approach on each. Then check whether it named the current decision, whether it cited the thread and doc section it used, and how many tokens the context cost. If the answer is right and short, the context was right.

Why the default tools hand over too much#

Each source's own tools are built to return whole things. Slack's MCP server can "grab the complete message history of channels" and "grab complete message thread conversations" (Slack docs). Google's Drive MCP server, still in Developer Preview, offers search_files and read_file_content (Google Drive docs). Both hand back whole files. Jira's text search matches words across summaries and descriptions, so a query for "retry" returns every ticket that ever used the word.

None of these tools know what task the agent is on. They answer the query they were given. The agent then reads it all, tries to tell the current fact from the stale one, and carries every result forward in its context for the rest of the session. That is the "dumping everything in" problem, and it happens even when each tool works as documented.

Google Docs needs the most care#

Google Docs holds the long-form material, such as RFCs, design docs and launch plans, and it is the hardest of the three to slice. A design doc is long, written once and edited rarely, so whole sections go stale while the title still looks current. Drive search can narrow by date and content, with terms like modifiedTime > '2026-09-01' and fullText contains 'webhook retry' (Drive API docs). But a match is still a whole file.

There is also a trap for anyone building their own reader. The Google Docs API returns only the first tab of a tabbed document by default: "the text fields in the Document Resource (e.g. document.body) will be populated with content from the first tab only" unless includeTabsContent is set (Docs API docs). Teams that keep an RFC in one tab and the decision log in another can hand the agent the proposal and silently drop the outcome. Check this before you trust a homegrown Docs connector.

Filter at the source if you wire it yourself#

If you connect each tool directly, put the four tests into the queries and the agent's instructions.

Jira's updated field takes "w" (weeks), "d" (days), "h" (hours) or "m" (minutes) to set a date "relative to the current time" (Atlassian JQL fields). Slack's search can "filter by date, user, and content type" (Slack docs, linked above), so the agent reads only the threads that come back.

This works for a small team. It breaks down when the right answer depends on weighing a Slack thread against a doc against the merged code, because every engineer's agent has to do that weighing alone. The guide to giving agents Slack, Jira and Confluence knowledge covers the wiring for each source in depth.

Let a context engine do the selection#

A context engine is a service that indexes code, PRs, tickets, docs and chat together, ranks them for the task, and returns one cited answer. Unblocked is one, with Slack, Jira, Google Drive, code and PRs among its sources (Unblocked data sources). It ranks results "using recency, authority, the expert graph" and the asker's own work, and calls code "the strongest ground truth for how the system behaves right now". It cuts the result "down to the most salient information for the task" and leaves "citations that work as breadcrumbs" the agent can follow for more (inside the Unblocked context engine). Permissions come from the source systems, so each agent sees only what its engineer can open.

For Google Docs, you choose which files, folders and shared drives Unblocked may read, and it checks Drive for new and updated files every 15 minutes (Unblocked docs). The agent asks one question via context_research from Claude Code, Cursor, GitHub Copilot, VS Code or JetBrains, and gets one cited answer instead of three result lists (Unblocked MCP docs).

In our test on one repository with the same prompt and model, attaching Unblocked cut tokens by 42 percent and tool calls from 80 to 29 (same prompt, same model, different context). One run is not a population, so run the three-ticket test on your own work. When sources disagree, see how a tool weighs a recent Slack message against an old doc.