Fabric: the AI workspace that writes your docs for you

Every workspace tool stores your documents. Fabric writes them. Decision records from Slack. Meeting notes from recordings. Engineering wikis from GitHub. Documentation that maintains itself.

Documentation has a reputation problem. Everyone agrees it should exist. Nobody wants to write it. The agreement-to-action gap is so wide that most organisations operate with documentation that's either nonexistent, outdated, or both.

Fabric resolves this by changing who does the writing.

How self-writing docs work

Self-writing documentation monitors the connected tools where your team's knowledge is naturally created and shared, and generates structured, cited documentation from that activity.

From Slack. Your team debates two approaches in a channel. The discussion goes back and forth over thirty messages. A decision is reached. In a traditional setup, someone should document the decision and the reasoning, but nobody does because the next task is already waiting. Fabric captures the thread and generates a decision record: what was decided, what alternatives were considered, what reasoning led to the choice, with citations linking each point to the specific Slack messages that expressed it.

From meetings. The sprint planning meeting runs for an hour. Decisions are made, tasks are assigned, priorities are debated. Traditionally, someone writes notes afterward (often incomplete, always late). Fabric transcribes the meeting and generates a structured summary: decisions made, action items assigned, key discussion points, with timestamps linking back to the specific moments in the recording.

From GitHub. An engineer submits a PR that changes how two services communicate. The code review includes discussion of why this approach was chosen over alternatives. In a traditional setup, this context lives in the PR and is never referenced again. Fabric captures the PR description, the review comments, and the related discussions, and updates the engineering documentation to reflect the change. The system architecture documentation stays current because it's derived from the code activity.

From sales. A rep mentions in Slack that a competitor just changed their pricing. A client call reveals a new objection pattern. A deal review identifies a successful approach for enterprise prospects. Each of these creates documentation: the competitive profile updates, the objection-handling guide expands, the sales playbook reflects the new approach. The sales knowledge base grows from the team's actual selling activity.

What the output looks like

The documentation isn't a raw transcript or an AI summary. It's structured, cited, editable knowledge.

Each claim in the documentation links to its source: the specific Slack message, the meeting timestamp, the PR description. Click the citation and you see the original context. This is what earns trust from teams who've learned to distrust stale wikis: every statement is verifiable, and the source of truth is the team's own activity.

The documentation is organised automatically by topic, team, and type (decisions, processes, system documentation, meeting outputs). New team members searching "how does the deployment pipeline work?" find current, cited documentation rather than a wiki page from eighteen months ago that nobody has updated.

What stays current and why

The documentation stays current because it's derived from live activity. When the deployment pipeline changes and the team discusses the change in Slack, the documentation updates. When the sales process evolves and the new approach is discussed in a deal review, the playbook reflects it. The staleness problem that kills Confluence and Notion wikis doesn't apply because the documentation tracks reality rather than being maintained alongside it.

The human role shifts from author to reviewer. Instead of writing documentation from scratch (hours per document, motivation required, consistency unlikely), team members review the auto-generated documentation periodically (minutes per document, verification rather than creation, triggered by the system rather than by discipline). The quality of the documentation improves over time as the team refines the output and the system learns from the corrections.

Who it's for

Engineering teams that need system documentation, decision records, and onboarding materials that stay current as the codebase evolves. The engineering wiki that writes itself is the feature engineering leaders describe as "the thing we've wanted for years."

Product teams that need decision logs, user research repositories, and roadmap context that doesn't go stale. The product documentation captures the reasoning behind decisions from the discussions where decisions are actually made.

Sales teams that need competitive intelligence, account context, and process documentation that reflects how deals actually close rather than how the playbook says they should.

Any team where the answer to "why did we decide this?" or "how does this work?" should be findable in seconds rather than requiring a meeting to reconstruct.

Frequently asked questions

How is this different from AI meeting notes tools? AI meeting notes tools (Granola, Otter, Fireflies) capture individual meetings. Fabric captures meetings alongside Slack, GitHub, email, and every other connected source, and synthesises across all of them. The meeting notes are one input. The self-writing wiki is the comprehensive, cross-source output.

Can the AI really write accurate documentation? The documentation is extraction and synthesis from your team's actual discussions, not generation from training data. Every claim cites its source. The accuracy is bounded by the accuracy of your team's discussions, and the citations let you verify any statement in seconds.

What if the AI gets something wrong? The documentation is fully editable. Review the output, correct any errors, and the system learns from the corrections. The review-and-refine workflow takes minutes compared to the hours required to write from scratch.

Does this require any setup? Connect the sources you want to document from (Slack, GitHub, meetings) and the documentation begins generating immediately. No templates to configure. No schema to define. The system produces documentation from the activity in the connected sources.

How do we control what gets documented? You choose which channels, repositories, and meeting types feed into the documentation. Sensitive channels can be excluded. The system only documents from sources you've explicitly connected.

Is the documentation searchable? Yes, through semantic search that finds by meaning. "How does the authentication system work?" finds the relevant engineering documentation. "Why did we choose this pricing model?" finds the decision record. The search works by concept rather than keyword.

Does it integrate with our existing wiki? Fabric can complement an existing Confluence or Notion wiki. Use the self-writing docs for operational documentation (decisions, processes, system docs) and keep the manual wiki for authored content (policies, strategic documents, style guides). Over time, many teams find the self-writing docs replace the manual wiki entirely.

What does this cost? Self-writing docs are included in Fabric's paid plans starting at $10/month per user. The feature is part of the workspace, not a separate add-on.

Related reading: Self-writing docs explained, Your second brain shouldn't need you to write it, Nobody reads the wiki, Docs that write themselves vs Confluence. Related pages: Self-writing docs, Docs that write themselves, Fabric vs Notion, Fabric vs Confluence.