SYSTEM Cited by 1 source
Atlassian Teamwork Graph¶
Wiki status: stub. This page is a placeholder created by the 2026-06-01 Jira-AI-agents ingest. The Teamwork Graph is named as one of the agent context substrates but the source post does not architecturally decompose it. To be expanded when a deeper architectural disclosure ingests.
What it is¶
Atlassian's Teamwork Graph is Atlassian's named cross-product knowledge graph spanning Jira, Confluence, Bitbucket, and other Atlassian products. It surfaces relationships between work items, people, documents, repositories, and decisions — the substrate Atlassian uses to serve cross-product context to AI agents and product features.
Role on this wiki¶
The Teamwork Graph appears at the work-item-as-agent-prompt altitude: it is one of the three context substrates the agent draws on when running on a Jira work item.
"Each work item is a record of the tasks we need to complete and acts as a prompt for agents. All the context an agent needs is shared using the work item, Atlassian's Teamwork Graph, and the explicit instructions we include in our workflow automations." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)
The substrate split (per the same source):
| Substrate | Lifetime | Editor | Carries |
|---|---|---|---|
| Work item | Per task | Cron / human / agent | Task-specific brief (flag name, paths, desired final state) |
| Teamwork Graph | Long-lived org-wide | Atlassian-product-wide | Cross-task context (related work, ownership, prior decisions) |
| Workflow automation prompt | Per procedure | Workflow admin | "How to do this kind of work" instructions |
What the source doesn't disclose¶
- Access protocol. Whether the agent reads the Teamwork Graph via an MCP server, a REST API, or a Jira-side fetch is not named.
- Schema. Entity types, relationship types, query language, and freshness contract are not described.
- Specific data the agent reads. The post lists "the work item, Atlassian's Teamwork Graph, and the explicit instructions" without specifying what cross-product context the agent actually pulls during a flag-cleanup or flaky-test run.
These are deferred to a future ingest if Atlassian publishes a deeper architectural post on Teamwork Graph itself.
Sibling cross-product knowledge graphs¶
The Teamwork Graph is structurally similar to:
- Netflix Service Topology — service-dependency knowledge graph for engineer-facing reasoning + automation. Different domain (service-runtime), same shape (knowledge-graph-as-substrate-for-agents and automation).
- LinkedIn Project ChickenSpot's metadata layer — cross-system metadata graph.
- GitHub's Code Search graph — cross-repo code reference graph.
The unifying architectural shape is knowledge-graph-as-substrate: expose a cross-product / cross-system relationship graph as a queryable substrate that both human-facing UI and agent loops consume.
Seen in¶
- sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in — first wiki naming. Listed as one of three agent context substrates for KTLO work delegation; not architecturally decomposed.
Related¶
- systems/jira — the work-item-tracking surface; Teamwork Graph is the cross-product substrate beneath / alongside it.
- systems/rovo-dev — likely consumer.
- companies/atlassian
- concepts/work-item-as-agent-prompt — the framing this graph supports.
- concepts/agent-context-window — the budget the graph-as-context-source helps populate efficiently.
- concepts/service-dependency-graph — sibling knowledge-graph-as-substrate at the service-runtime altitude (Netflix Service Topology).