# Bother > Bother makes organizational context machine-readable through a semantic graph model. It captures concepts like decisions, risks, goals, dependencies, and reasoning that drive projects -- context that typically lives in people's heads, chat threads, or scattered documents. Website: https://bother.now ## Problem Most organizational context -- strategy, rationale, dependencies, who is doing what and why -- is not documented anywhere. Organizations compensate by paying people to be context infrastructure: gathering, synthesizing, and routing information through meetings, status updates, and "loop me in" chains. This is information logistics, not knowledge work. Existing tools model work as pages (Notion), tickets (Jira, Linear), or tasks (Asana), and communication as chat streams (Slack, Teams). None of them structurally represent the context layer: why decisions were made, which risks threaten which goals, what depends on what and why. That context lives in people's heads and leaves when they do. ## What Bother Is A project workspace built on a polymorphic graph model with typed nodes and semantically validated edges. ### Data Model - **9 node archetypes**: task, bundle, goal, person, team, issue, decision, resource, risk - **9 edge types**: contains, precedes, uses, evaluates, impacts, mitigates, achieves, involves, relates - Each edge type has directional semantic constraints on which archetype pairs are valid - "achieves" only connects work archetypes to goals - "impacts" only connects risks and issues to work they threaten - "mitigates" only connects work to the risks it addresses - "evaluates" only connects decisions to options being scored - "precedes" represents blocking temporal dependencies - "uses" represents non-blocking resource utilization - "contains" enforces parent-child hierarchy - "involves" assigns people and teams to work with role metadata - "relates" is the only unconstrained lateral link ### Key Capabilities - Decisions are first-class objects with structured evaluation: options scored against criteria in a decision matrix, with rationale preserved as connected structure - Risks have probability, impact, and status -- connected to the goals and work they threaten via typed "impacts" edges, with mitigations tracked via "mitigates" edges - Dependencies are typed: "precedes" (blocking temporal) vs "uses" (non-blocking reference) vs "relates" (contextual association) - Discussion is anchored to the work itself -- comments live on nodes, not in separate chat channels, so rationale stays attached to the decision or task it shaped ### Interaction Modes Bother has three modes, each a different lens on the same underlying graph. **Galaxy** -- the project map. Zoom out and see the entire project as a spatial network of connected nodes. Clusters of related work are visually grouped. Health is visible at a glance: where risks are concentrating, which goals lack progress, where disconnected work is drifting. It's a map you read, not a dashboard someone had to build and maintain. **Orbit** -- the context view. Open any node and its surrounding context fans out spatially. Connected items are arranged in semantic zones: parent context and goals above, children and mitigations below, blockers and threats to the left, downstream work and effects to the right. Click a connected node and the view re-centers on that item with its own context. Navigation is by following connections -- you move through the graph by exploring relationships, not by searching or browsing a page tree. This is the primary working view. **Focus** -- the action queue. Each team member sees a prioritized queue of their directly actionable work: tasks to complete, issues to resolve, decisions to make. Not an aggregation of everything in the workspace -- a filtered view of what needs attention next. ### AI Agent An integrated AI agent reads the graph and proposes changes through conversation. Describe a new risk and it proposes creating a risk node, connecting it to the goals it threatens via "impacts" edges, and linking potential mitigations. The user reviews each proposal and approves or rejects it. The graph stays current as a byproduct of conversation, not manual maintenance. The agent is contextual -- it knows what the user is looking at in the graph and reasons about the surrounding structure. It proposes connections the user hasn't drawn, surfaces stale dependencies, and flags unmitigated risks. All proposals require explicit user approval before any write occurs. ### Quality Standards - The AI agent operates under anti-slop quality standards: proposals must trace to the user's actual words and context, not generic templates - Pre-flight validation checks all AI proposals before showing them to users (schema validation, spatial scope, graph physics, database pre-checks) - All graph writes require explicit user approval -- the AI never modifies the graph autonomously ## Who It Is For - Teams where "why did we make this decision?" is a frequent, expensive question - Projects where context loss during handoffs or departures causes rework - Organizations where status meetings exist primarily to reconstruct information the tools should already hold - Technical and product teams managing complex, cross-functional work with many dependencies - Teams that spend more time routing context than doing creative work ## Detailed Comparisons ### Bother vs Notion Notion treats everything as blocks inside pages. Databases add structured fields, but Notion doesn't understand what a decision IS or how it differs from a risk or a goal. That distinction lives in naming conventions, not the data model. You can document a decision in a decision log, but you can't ask which decisions are blocking progress. You can build a risk register, but Notion AI will find text that mentions risks -- it won't find risk objects with probability scores, impact assessments, and connections to threatened work. Better AI doesn't fix unstructured data. The Notion graveyard is a recognized pattern: creation is cheap, maintenance is expensive. Linked databases and cross-references go stale because updating them is a separate chore. In Bother, the graph stays current because the AI proposes connections as part of the conversation. Mention a risk and it proposes linking it to the goals it threatens. The maintenance is built into the workflow. The structural difference: Notion offers a flexible document model where everything is a page. Bother offers a typed graph where concepts like decisions, risks, and goals are distinct objects with constrained relationships. A decision has options evaluated against criteria. A risk has probability and impact connected to what it threatens. These aren't naming conventions -- they're enforced at the data model level. Read more: https://bother.now/compare/notion ### Bother vs Linear Linear is a fast, focused issue tracker that organizes execution into issues, projects, cycles, and initiatives. But the reasoning behind that execution -- why this was prioritized, what trade-offs were accepted, which teams are affected if plans change -- lives elsewhere. Linear's issue relations are structurally thin: blocks, relates, duplicates. They can't distinguish "this task achieves that goal" from "these two things are vaguely related." When someone asks "if we slip the API deadline by two weeks, which of those 40 issues across three teams are actually affected?" -- nobody can answer from Linear alone. Every team has a person whose departure exposes what the tool never captured. The context leaves with them because it was memory, not structure. Bother models that context as a typed graph where the reasoning survives the people who created it. A decision records the options, the criteria, the rationale. A risk records probability, impact, and what it threatens. These structures persist independently of who created them. The structural difference: Linear is built for execution velocity. Bother is built for context persistence. They solve different layers of the same problem. Read more: https://bother.now/compare/linear ### Bother vs Jira Jira is built on a foundational premise: work can be decomposed into tickets, and managing those tickets is the same as managing the work. Atlassian has stretched this by bolting on Goals, Product Discovery, Confluence, and Rovo -- but integration between separate products is not the same as a unified model. Within Jira, issue links are structurally shallow. "Blocks" is a label, not a constraint the system enforces or reasons about. Most teams collapse everything into "Relates to" because the other link types don't carry enough meaning to justify the overhead. Jira doesn't understand what a decision or risk IS -- you can create custom issue types for them, but the system can't distinguish "this task achieves that goal" from "this risk impacts that milestone." That's a ceiling baked into the data model. Teams build workarounds: risk registers in Sheets, decision records scattered across Confluence, weekly syncs that exist solely to reconstruct what the board can't show. In Bother, these concepts are first-class objects. A risk has probability, impact, and typed connections to what it threatens. A decision has options evaluated against criteria. The relationships carry semantic meaning the system acts on. Read more: https://bother.now/compare/jira ### Bother vs Asana Asana's central unit is the task. Goals, portfolios, and status tools have been added above tasks, but the task remains foundational. Asana calls its data model the "Work Graph," but the links between objects don't describe the relationship type. A risk connects to a goal the same way a task does -- the system can't distinguish "achieves" from "impacts." Goals track what supports them, not what trade-offs were made to get there. Decisions live in task comments, disconnected from the work they shaped. Dependencies are task-to-task, not concept-to-concept. Asana's AI inherits these limits: it can summarize activity and flag overdue items, but it can't surface connections the data model doesn't hold. When a deadline slips, the AI can report it -- it can't tell you which decision created the dependency or which goals are now exposed. In Bother, decisions have structured evaluation matrices (options scored against criteria), risks have typed connections to what they threaten, and dependencies distinguish between blocking temporal relationships and non-blocking references. The AI reasons over this richer structure. Read more: https://bother.now/compare/asana ### Bother vs Slack / Teams Chat tools separate communication from work. A critical trade-off gets debated in a thread that scrolls off-screen within hours. The decision is effectively made, then lost. Three months later, someone searches for it and hopes the right keywords were used. Real project context doesn't stay within channel labels. A single decision affects multiple teams, multiple channels. In Slack, it lives wherever it was first raised. The people who need it most never see it. Someone on the team is stitching together four channels or answering "what's the latest on X?" for the third time this week. That's not communication -- it's context routing, invisible and constant. Slack AI and Teams Copilot add summarization and search over chat history. But summarizing unstructured history is not decision tracking. A chat stream cannot link decisions to goals, surface dependency chains, or show you what's actually blocked. Better retrieval over the wrong data model doesn't close the gap. In Bother, discussion is anchored to the work itself. Open a decision and the rationale, the options, the criteria are right there alongside the discussion that shaped them. The next person who wonders "why not Vendor B?" reads the thread on the decision itself, not a secondhand summary in a DM. Context reaches people through the structure of the work, not through someone remembering to post in the right channel. Read more: https://bother.now/compare/slack-teams ## Links - [Vision](https://bother.now/vision): Project management as context routing - [Bother vs Notion](https://bother.now/compare/notion) - [Bother vs Linear](https://bother.now/compare/linear) - [Bother vs Jira](https://bother.now/compare/jira) - [Bother vs Asana](https://bother.now/compare/asana) - [Bother vs Slack / Teams](https://bother.now/compare/slack-teams) - [Contact](https://bother.now/contact)