Too many tools, too little context

The average company maintains roughly 137 apps across its business. Knowledge workers use about 8 different SaaS applications every day. Each app is individually useful, often excellent at its specific job. Collectively, they create a fragmented information landscape where the same piece of knowledge exists in pieces across three or four systems that have no idea the others exist.

The client's preferences live in the CRM. The project requirements live in the project management tool. The design decisions live in Figma. The technical constraints live in GitHub. The strategic context lives in a Google Doc. The actual agreement about what to build was reached in a Slack thread that's already scrolled off the first page. None of these tools can see the full picture because each one holds a fragment.

Workers toggle between applications 1,200 times per day (HBR 2022). Each toggle carries a cognitive cost: the context switch, the interface adjustment, the moment of reorientation. Multiply that recovery time across hundreds of daily switches, and the aggregate productivity loss is substantial, estimated at $450 billion annually across the global economy by Atlassian.

How we got here

Tool proliferation is a bottom-up phenomenon, and that's why top-down solutions rarely work.

Each team adopts the tool that best fits their specific needs. Sales picks a CRM because CRMs are built for pipelines. Engineering picks GitHub because GitHub is built for code. Marketing picks a content management platform because it's built for campaigns. Nobody coordinated these decisions because they didn't need to: each team was solving a local problem and chose the best local solution.

The silos that result aren't anyone's fault. They're the structural consequence of distributed, rational decision-making in an organisation where specialised tools are abundant and cheap. The same market forces that made excellent specialised software available to every team also ensured that the information those teams create would be scattered across incompatible systems.

Adding another tool to solve the fragmentation problem is the instinct, and it usually makes things worse. The "one platform to rule them all" approach (forcing everyone onto Notion, or Confluence, or SharePoint) fails because no single tool is good enough at everything to replace the specialised tools people have chosen. Engineers won't give up GitHub. Designers won't give up Figma. Sales won't give up their CRM. And any attempt to force consolidation produces resistance, workarounds, and shadow IT.

The connective alternative

The approach that works is a layer that connects existing tools without replacing them.

Each team keeps the tool that works best for their specific job. The connective layer indexes the content across all of them and makes it searchable from one place, by meaning rather than by keyword. An engineer searching for the context behind a feature request finds the CRM entry, the product brief, the design mockup, and the Slack discussion, all from one search bar.

Fabric's connections bring together Google Drive, Slack, GitHub, Gmail, Notion, Figma, HubSpot, Linear, Airtable, Salesforce, and dozens more into one searchable library. The information stays where it was created. The search spans everything.

Through MCP, this unified knowledge layer also becomes the context layer for any AI agent the organisation uses. An AI tool that can search across all your apps, understanding context from every team and every tool, produces dramatically more useful output than one that can only see the data in its own silo.

What changes in practice

Cross-team visibility without cross-team meetings. When anyone can search across all teams' tools, many of the meetings that exist to transfer context between teams become unnecessary. The information is findable without requiring the information holder to be present.

Fewer "does anyone know...?" messages. The Slack message that starts with "does anyone know where to find..." is a symptom of information fragmentation. When the information is searchable from one place, the question doesn't need to be asked and the person who would have answered doesn't get interrupted.

AI tools that actually work for your company. The 86% of companies that say they're not ready for AI (McKinsey 2026) are, in most cases, companies whose knowledge is scattered across disconnected tools. Connecting those tools into one searchable layer is the most direct path to AI readiness.

Reduced duplicate work. When teams can see what other teams have already done, the 14% of work time currently spent recreating information that already exists (Bloomfire) drops significantly.

Frequently asked questions

How many tools should a company have? There's no magic number, and the goal shouldn't be to reduce the tool count. The goal should be to ensure that the knowledge created in each tool is findable from one place. Ten specialised tools connected to a unified search layer is better than one general-purpose tool that nobody likes.

What about security and access controls? The search layer respects the permissions of the underlying tools. Content that's restricted in the source tool remains restricted in the search results. Each connection can be configured to include or exclude specific content.

How does this differ from Slack search or Google Workspace search? Those searches only span their own ecosystem. Slack search finds Slack messages. Google search finds Google documents. Neither finds the relevant information that lives in GitHub, Figma, HubSpot, or your project management tool. A unified search layer spans all of them by meaning, which means it finds the relevant result regardless of which tool it lives in.

Related reading: How to break down information silos, The cost of scattered knowledge, The app sprawl problem, Your company isn't ready for AI. Related pages: Connections, Marketplace connections, One search, Find anything.