Connecting the Tools: Tracker, Docs, and Chat Without Drowning in Integrations

After part three, the repo knows things. But product work doesn’t happen in the repo — it happens in a tracker (Jira, Linear, Azure DevOps), a docs tool (Notion, Confluence, Google Docs), and a chat tool (Slack, Teams). The naive endgame is to sync everything with everything, and that way lies the integration swamp: duplicated content, three “sources of truth,” and a maintenance tax that kills the system inside two quarters.

The design that works is narrower and almost disappointingly simple. Don’t sync systems — give your AI assistant read access to all of them in one session, and write access to exactly one place per artifact type. The assistant is the integration. The repo stays small and authoritative; the tools stay authoritative for what they already own; and nothing mirrors anything.

One truth per system

Write this table into your AGENTS.md, because every integration decision falls out of it:

System	Source of truth for	Never the source of truth for
Context repo	What the product is, means, decided; customer evidence	Work status, drafts-in-progress
Tracker	Work items and their state	Product rationale, customer evidence
Docs	Collaborative drafts, meeting notes	Final decisions (those distill into decisions/)
Chat	Real-time discussion	Anything anyone needs to find in three weeks

Two flows in that table do all the work. Distill up: when a docs draft or a chat argument produces a decision, it gets distilled into a decision record in the repo — the thread dies, the record survives. Reference down: when a tracker story needs rationale, it links to repo files and signal IDs rather than restating them. Content is written once, where it’s true, and referenced everywhere else. The moment you catch yourself copying prose between systems, one of them is claiming a truth it doesn’t own.

How the connections actually work: MCP

The plumbing that makes “one assistant, all systems” real is the Model Context Protocol — the now-standard way AI tools connect to external systems. Every major tracker, docs platform, and chat tool has an MCP server (first-party or well-maintained community ones), and every serious AI assistant — chat apps and CLI agents alike — can consume them. Configuration is a few lines per tool and an OAuth flow; no custom code.

What changes when the connections exist is the session shape. Before: you are the integration — six open tabs, copy-paste in both directions, context evaporating between hops. After, one session does this:

1. Reads product/areas/reporting.md, the glossary, and the last four weekly digests from the repo.
2. Queries the tracker: open items in the reporting epic, to avoid drafting a duplicate.
3. Pulls the PRD draft from the docs tool for the surrounding feature.
4. Drafts three user stories grounded in all of it, citing signal IDs.
5. Files them in the tracker — as drafts, in a triage state, never straight to the sprint.

Fifteen minutes, and the output knows what last week’s tickets said and what’s already in flight. That loop — with the repo as ground truth at step 1 — is exactly what part five packages into a reusable command.

Read wide, write narrow

The rule that keeps this safe and debuggable: grant reads broadly, grant writes reluctantly, and route every write through a human approval.

Reads are low-risk and high-value — let the assistant read the tracker, docs, and chat history freely (within your normal access, of which more below). Writes are where trust erodes, so constrain them structurally, not aspirationally:

• Tracker writes go to a staging state. Drafted stories land labeled ai-drafted, in a triage column, unassigned. Nothing the assistant writes can appear in a sprint without a human moving it. This single convention defuses the team’s most reasonable fear — machine-generated tickets appearing in their queue — because appearing in the queue is precisely what can’t happen.
• Docs writes create new drafts, never edits to shared documents in place.
• Chat gets no autonomous writes. Messages send when you hit send. A bot posting the weekly digest to a channel is fine — that’s a broadcast you configured, not the assistant speaking as you.
• Repo writes go through pull requests — which you already have from part two. Extraction drafts arrive as a branch; review is a diff.

Least privilege applies at the account level too: the assistant connects with your credentials and sees only what you can see. Resist any clever architecture that gives an AI integration a service account with broader access than its operator — that’s how “the assistant read the HR space” incidents happen.

The privacy boundary

Part three’s rule — signals are anonymized at creation — has a systems-level counterpart here. Your help desk, CRM, and call recorder hold customer-identifying data governed by contracts and privacy law. Before wiring any of them into an AI session, get an explicit answer from whoever owns security: which systems may be read by which AI tools, under what data-processing terms? Most vendors have AI/sub-processor terms for exactly this; your job is to know the answer is yes before the connection exists, not to discover the question in a vendor review. The repo-side anonymization discipline means the most-read artifacts — cards and digests — are clean by construction, which makes that conversation dramatically easier.

Build order (not all at once)

1. Tracker read — immediately useful (“what’s open in this epic?”, duplicate detection) and zero-risk.
2. Tracker draft-write — with the staging convention agreed with the team first. This is the one to socialize before enabling: show the label, show the triage column, show that nothing reaches a sprint by itself.
3. Docs read — pulls existing PRDs and meeting notes into drafting sessions.
4. Chat read — surprisingly high-value for decision archaeology (“find where we discussed the export limit”) feeding decisions/ records.
5. Everything else — help desk, CRM, call recorder — only after the privacy conversation above, and only if weekly extraction via export files (which works fine) has become the bottleneck.

Each step is independently useful, so you can stop anywhere and keep the value. Steps one through four are typically an afternoon of setup in total.

Two smells tell you you’ve overbuilt. Mirroring: any job whose description is “copy content from system A into system B on a schedule” — delete it; link instead. Mystery writes: if anything appears in any system and a teammate can’t immediately tell it was machine-drafted and who approved it, tighten the labels before someone’s trust — not the tooling — becomes the thing you have to repair.

The rails are now laid: context in the repo, evidence flowing weekly, tools reachable in one session, writes gated by humans. What’s left is making the workflows repeatable — versioned commands that turn “draft me a story” into a grounded, reviewable, team-shared operation.