Skip to content

ATLASSIAN 2026-10-16 Tier 3

Read original ↗

How a context graph makes enterprise AI more accurate and less expensive

Summary

Atlassian argues that enterprise AI underperforms not because the models are weak but because the context is disconnected: documents, tickets, repositories, chat, and customer systems each hold a fragment, and an agent that inspects them separately must infer how they relate — producing answers that sound plausible but miss the decision, dependency, or owner that actually matters. The proposed fix is a context graph (Atlassian's is the Teamwork Graph): a pre-curated data structure where the relationships between entities (people, goals, projects, decisions, work items, code, services, customers) carry as much meaning as the entities themselves, so an agent can traverse dependencies and impact paths instead of re-deriving them per query. The post frames three complementary retrieval approaches — API orchestration, RAG, and graph-grounded retrieval — and reports internal benchmarks where graph-grounded context (via a Teamwork Graph CLI) delivered higher answer quality at lower token cost. It is a largely strategic/marketing piece, but it is the first Atlassian post to describe the Teamwork Graph's role architecturally (previous mentions were a one-line name), so it upgrades the Teamwork Graph wiki page from stub.

Key takeaways

  1. A context graph is a knowledge graph where the edges are the point. "A data structure that connects pieces of information and their relationships… where the connections carry as much meaning as the things being connected." This is the wiki's concepts/knowledge-graph concept under Atlassian's "context graph" name — the Teamwork Graph connects people, goals, projects, decisions, work items, code, services, and customers so AI uses the relationships as context rather than isolated records.

  2. The failure mode is "technically plausible but incomplete." The post's worked example: asking "Why is the 'payments migration' behind schedule?" Without connected context the agent returns Jira metadata ("Epic PAY-204 has four overdue issues, no blocker recorded"). With connected context it traces the path to a Confluence decision record (DEC-88), a pending pull request (PR-412) awaiting Identity-team review, and the dependent Payments Core service — identifying the root cause and the exact team needed to unblock.

  3. Context design beats model selection at the margin. Teams "over-invest in model selection while under-investing in context design," paying for more expensive reasoning models to compensate for disorganized context. The recommended inversion: resolve the relevant context up front, then pick the model appropriate to the task — "with a connected context ready up front, lower-tier models can perform well across many workflows." This is the wiki's match-the-model-to-the-task / efficiency-frontier argument, applied to context rather than routing.

  4. Agent-ready knowledge rests on source-level hygiene, expressed as three qualities. For a knowledge base to be usable by agents and MCP clients, each document/work item must be trustworthy, current, structured, permission-safe, and independently retrievable. The three qualities that emerge: trustworthiness (clear ownership + lifecycle signals: current / draft / superseded; contributors and recency feed ranking), discoverability (meaningful titles, consistent structure, enough substance to tell a source-of-truth from a stub), and actionability (useful links + consistent, well-documented interfaces, with MCP parity so people and agents get comparable access).

  5. Permission-aware context is a hard requirement, enforced at retrieval time. An agent or MCP client "should retrieve, summarize, and act only on information the requesting user is authorized to access, not merely information that is technically discoverable." That means preserving page-, space-, project-, and system-level permissions across connected sources, enforcing identity/access checks at retrieval time, and carrying authorization metadata "through indexing, ranking, citations, and tool calls." This is the wiki's concepts/governed-agent-data-access / concepts/least-privileged-access stance (the permission-at-retrieval idea), stated as a scaling-safety prerequisite rather than a compliance bolt-on.

  6. MCP is the access interface; the graph is the context source. "MCP provides a standard way for clients to request context and invoke tools through approved interfaces, while Teamwork Graph supplies graph-grounded relationships through Atlassian experiences and APIs without requiring clients to access the raw graph directly." The emphasis is on parity between the experiences people use and the approved context/actions agents can reach via MCP, Atlassian tools, and APIs — not on exposing the graph itself.

  7. Three retrieval approaches are complementary, not competing. The post's own table assigns each a role:

Approach Role Best fit
API orchestration Coordinates actions across systems Creating or updating work
RAG Retrieves source content to ground answers Knowledge and policy questions
Graph-grounded retrieval Uses relationships to connect evidence Multi-hop questions and impact analysis

Graph relationships find and connect relevant evidence, RAG grounds answers in source content, APIs turn grounded answers into action, and MCP gives consistent tool/context access — a model-agnostic architecture across Claude, Cursor, Codex, ChatGPT, and Gemini. This is the wiki's parallel-retrieval-fusion shape: fuse several retrieval modes rather than pick one.

  1. Graph-grounded context can be cheaper and better. It reduces the "discovery tax" — the effort an agent spends searching systems independently, following links, inferring relationships, and carrying noisy intermediate context forward (see concepts/token-overhead).

Operational numbers

  • Atlassian survey of 1,000 knowledge workers: 45% compare their enterprise AI's understanding of their organization to that of a new hire or very junior employee.
  • Internal benchmark across 10 tested scenarios on Atlassian data: workflows using context via the Teamwork Graph CLI (rather than individual MCP connections) produced on average up to 44% higher-quality answers while using up to 48% fewer tokens than the comparison setup.
  • ML Studio context (from the company page, not this post): Teamwork Graph is one of the systems backed by Atlassian's ML platform, which serves ~120k monthly workflow runs across 100+ ML teams.

Caveats

  • Marketing-leaning strategy post. This is a "context" / AI-strategy blog entry, not an engineering deep-dive. It ends with a product CTA (Teamwork Collection). It does not disclose the Teamwork Graph's schema, entity/edge model, query language, freshness contract, or the CLI's internals.
  • Benchmark is self-reported and narrow. "Up to 44% / up to 48%" are averages across 10 Atlassian-internal scenarios on Atlassian data; the post explicitly cautions results "vary by workflow, source quality, permissions, model, and task complexity, and should not be assumed to apply to MCP workflows or AI tasks in general." The comparison baseline ("individual MCP connections") is not precisely specified. Treat as directional, not a reproducible benchmark (cf. concepts/benchmark-methodology-bias).
  • "Context graph" is Atlassian's branding for a knowledge graph. No new concept is minted on the wiki — it canonicalizes into concepts/knowledge-graph.

Source

Last updated · 854 distilled / 2,448 read