Consolidate overlapping tools by integration quality, not feature count — in compound workflows, how a tool connects matters more than what it does alone

Why This Is a Rule

A tool doesn't exist in isolation — it operates within a stack where data flows between tools (Map tool stack as a graph: tools = nodes, data transfers = edges labeled manual/automated + frequency — reveals bottlenecks narrative inventory misses). A tool with superior standalone features but poor integration creates friction at every boundary: manual data transfer, format conversion, copy-paste between windows. A tool with adequate standalone features but excellent integration produces smooth data flow that eliminates boundary friction entirely.

In compound workflows (where output from one tool feeds into the next), the total time is dominated by boundary costs, not processing costs. If Tool A processes data in 5 minutes but requires 10 minutes of manual transfer to Tool B, while Tool C processes the same data in 8 minutes but auto-transfers to Tool B, Tool C is faster despite being slower at the processing step. The 3-minute processing penalty is more than offset by the 10-minute boundary elimination.

This is why the "best" tool in isolation is often the wrong choice for a stack: "best" is measured standalone, but value is realized in the compound workflow where integration quality determines throughput. The tool that connects seamlessly at 80% capability beats the tool that excels at 100% capability but creates integration bottlenecks.

When This Fires

• When two tools in your stack serve the same function and you need to eliminate one
• When Map tool stack as a graph: tools = nodes, data transfers = edges labeled manual/automated + frequency — reveals bottlenecks narrative inventory misses's visual mapping reveals redundant nodes
• When choosing between a feature-rich tool with poor integration and an adequate tool with excellent integration
• Complements When two tools hold the same data, designate one canonical source of truth — demote the other to capture-point or read-replica to prevent sync drift (single source of truth) and One tool as hub for thinking/synthesis, others as spokes — hub-and-spoke gives N connections instead of N², preserving single source of truth (hub-and-spoke) with the consolidation criterion

Common Failure Mode

Feature-first consolidation: keeping the tool with more features regardless of integration quality. The superior features are used 20% of the time; the integration friction is experienced 100% of the time. Net result: the "better" tool produces a worse daily experience.

The Protocol

(1) When two tools overlap, evaluate each on two dimensions: Standalone capability (how well does it perform the overlapping function?) and Stack integration (how smoothly does data flow to/from this tool within your overall stack?). (2) If one tool wins on both → easy choice. (3) If there's a trade-off (Tool A has better features, Tool B has better integration) → choose Tool B unless Tool A's feature advantage is critical (you literally cannot accomplish a necessary task without it). (4) "Critical" means you've identified specific tasks that require the feature, not that the feature "might be useful." (5) After consolidation, verify: has the integration friction decreased? Is data flowing more smoothly? If yes, the consolidation succeeded regardless of the feature trade-off.