Directing @yagni · Lesson 4 of 4
Which tools does YAGNI connect to, and what does it do with them?
Published June 9, 2026 · Updated August 14, 2026
YAGNI connects through native, first-party connectors to the tools you already pay for: GitHub, Slack, Jira, Confluence, Linear, Google Workspace, Notion, HubSpot, and Stripe today, plus your own MCP servers, databases, and custom services. It reads them to ground the work and ships approved work back into them.
Which native connectors exist today?
| Connector | What it feeds |
|---|---|
| GitHub | The repos your Teams answer for: PRs to review, issues, what merged |
| Slack | What the team is saying and deciding; threads that become tickets |
| Jira and Linear | Engineering work: issues, cycles, what is blocked |
| Confluence and Notion | The docs behind the decisions |
| Google Workspace | Gmail, Calendar, and Drive: the inbox, the agenda, the files |
| HubSpot | The customer behind the ticket, the deal behind the priority |
| Stripe | What the business actually earns; billing truth for billing code |
| MCP Server, Custom Service, Database | Your own tools, spoken to directly |
The list grows in the order customers run on. GitHub connects as an App installation on your org, workspace-wide, so it is installed once, on the onboarding call, and never per developer.
What does read access feed?
The grounding. Connected tools are what let a PR review know about the ticket, a proposal know about the incident, and an @yagni answer cite the row it came from instead of guessing. For YAGNI Code they are what turns a coding agent that knows your repo into one that knows your company. With nothing connected the harness still works; each connection makes the same work better grounded.
How does work ship back?
Through approval, under your identity model. A drafted reply, a filed ticket, a PR: each ships only when a person approves it or a Team has earned the authority for that class of act, and each leaves a Receipt proved from the destination. Where the tool supports it, writes carry the right identity, so a ticket filed from the CLI lands under your name, not a bot account nobody recognizes.
What never happens?
Your tools are never hosted, migrated, or replaced. A workspace-wide connection never auto-attaches anyone’s personal source: a founder’s inbox joins only through Settings, with explicit consent, bound to the Team you choose. And credentials never ride in model prompts; they are resolved at execution time, inside the tool call, and the security page documents the full posture.
Which connection should come first?
GitHub, almost always. It is the one an engineering workspace is built around, it is installed on the onboarding call, and it gives every Team its first real scope the same day. Slack and your tracker usually follow in the first week; the rest attach when a Team’s Responsibilities call for them.
Common questions
What does additive mean in practice?
YAGNI sits on top of your stack. It reads your tools and ships approved work back into them, and it never hosts your apps or migrates your data. Your issues stay in Jira, your repo stays on GitHub, your Stripe data stays in Stripe.
What if a tool I run on is not built yet?
Connect it anyway: the MCP Server connector speaks to any MCP server you already run, and the Custom Service and Database connectors cover the rest. Native, first-party connectors ship regularly, in the order customers actually run on.
Are connectors priced separately?
No. Connectors are part of the product, not add-ons. Which tools you connect is a coverage decision, never a line item.
How is connector access secured?
Connector credentials are customer-scoped, AES-256-GCM encrypted, resolved only at execution time, and never placed in model prompts. Tool calls record sanitized action metadata, application data access is workspace- or customer-scoped, and inference runs on US-hosted providers under zero data retention agreements.