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


URL: https://getunblocked.com/answers/coding-agents-right-context-slack-jira-google-docs/
Published: 2026-11-10T18:30:00Z
Updated: 2026-11-08T16:36:01Z
Author: Dennis Pilarinos
Categories: Context Engine, Engineering Insights

**Short answer:** Pick context per task, not per source. Scope it to the service and ticket being worked on, prefer what changed recently, rank the hits, and hand the agent the few cited passages that matter with links to the rest. Filter at the source with JQL, Slack date filters and Drive queries, or put a context engine in front that does the selection for you.

---
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](https://platform.claude.com/docs/en/build-with-claude/context-windows)). 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](https://arxiv.org/abs/2603.20432)). **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](https://docs.slack.dev/ai/mcp-server/)). Google's Drive MCP server, still in Developer Preview, offers `search_files` and `read_file_content` ([Google Drive docs](https://developers.google.com/workspace/drive/api/guides/configure-mcp-server)). 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](https://developers.google.com/workspace/drive/api/guides/search-files)). 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](https://developers.google.com/workspace/docs/api/how-tos/tabs)). 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.

| Source | Scope it with | Example |
| --- | --- | --- |
| Jira | Component plus a relative date in JQL | component = Billing AND updated \> "-30d" |
| Slack | Search filtered by date and user | Search the ticket key and service name |
| Google Docs | A short folder list plus a Drive date filter | modifiedTime \> '2026-09-01' |
| The agent | One line in the rules file | "Quote the passage and link it; say which source won" |


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](https://support.atlassian.com/jira-software-cloud/docs/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](https://getunblocked.com/blog/give-agents-slack-jira-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](https://docs.getunblocked.com/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](https://getunblocked.com/blog/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](https://docs.getunblocked.com/data-sources/google-drive)). 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](https://docs.getunblocked.com/unblocked-mcp/mcp-overview)).

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](https://getunblocked.com/blog/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](https://getunblocked.com/answers/how-an-ai-knowledge-tool-weighs-a-recent-slack-message-against-an-old-confluence-doc/).

## Read more

- [How to Give AI Agents Your Slack, Jira, and Confluence Knowledge (Tools Compared)](https://getunblocked.com/blog/give-agents-slack-jira-confluence-knowledge/)
- [Context Engineering: The Complete Guide for Engineering Leaders](https://getunblocked.com/blog/context-engineering-guide/)

## Related answers

- [Is an LLM-maintained wiki in git a better fix than a context tool for engineering knowledge?](https://getunblocked.com/answers/llm-maintained-wiki-vs-context-tool/)
- [How do we drive adoption of an AI coding tool from a third of engineering to everyone?](https://getunblocked.com/answers/drive-ai-coding-tool-adoption-across-engineering/)
- [How do I make sure Claude actually calls the context MCP without every engineer editing their CLAUDE.md?](https://getunblocked.com/answers/make-claude-call-context-mcp-without-editing-claude-md/)
- [Atlassian Rovo MCP versus a dedicated context tool for Confluence, Jira and code?](https://getunblocked.com/answers/atlassian-rovo-mcp-vs-context-tool/)