Atlassian opens Teamwork Graph to agents

Atlassian is trying to solve a very specific AI problem. Agents are getting decent at writing code and answering questions, but they still have no idea how a company actually works. They do not know who owns a service, which roadmap matters, what decision got made in a meeting, or why a Jira ticket is blocked. On May 6, Atlassian said it is opening that missing layer — its Teamwork Graph — to outside agents through two new access paths: a Teamwork Graph CLI and the Rovo MCP server. (atlassian.com) ### What is Teamwork Graph, exactly? Teamwork Graph is Atlassian’s internal context layer. It maps relationships across people, teams, goals, tickets, documents, code, incidents, and linked third-party tools, then keeps those links permission-aware. Atlassian says the graph now holds more than 150 billion objects and relationships, up from the(atlassian.com 1)(atlassian.com 2) ### What changed this week? The new part is access. Atlassian is exposing that graph to agents in two ways: Rovo MCP for MCP-capable hosts like web LLMs, IDEs, and sandboxes, and Teamwork Graph CLI for agents that can run terminal commands locally or in CI. Atlassian’s own docs frame them as complementary, not interchangeable. (developer.atla([atlassian.com) matter? Because a lot of coding agents already know how to use a shell. Atlassian is betting that a local CLI is a cleaner way to let those agents ask for work context, inspect graph data, and trigger Atlassian actions without forcing every workflow through a chat interface. The company explicitly pitches the CLI as usable by Cl(developer.atlassian.com) can be more token-efficient than live MCP calls. (developer.atlassian.com) ### Why is MCP still important then? Because not every agent lives in a terminal. MCP is quickly becoming the standard way to let AI tools call outside systems, especially from IDEs and hosted assistants. Atlassian launched its remote MCP server earlier, and this week’s move makes Teamwork Graph context available through that route too, so the same organizational map can travel into more agent environments. (atlassian.com) ### What can an agent actually see? More than just Jira tickets. Atlassian’s docs list coverage across Jira, Confluence, Bitbucket, Jira Service Management, Loom, Trello, Atlas goals and projects, Teams, Customer Service Management, Jira Align, and Talent, plus connected apps like Google Drive, Slack, GitHub, and Salesforce through the graph layer(atlassian.com)ork, not just the artifact in front of them. (developer.atlassian.com) ### So what problem is Atlassian trying to fix? Coordination drag. A human engineer can usually infer that a ticket touches another team, that a doc is stale, or that a roadmap item belongs to a different owner. An agent usually cannot. Teamwork Graph is meant to supply that missing context before the model starts reasoning, so the agent acts more like a teammate with history instead of a smart autocomplete box. (atlassian.com) ### What’s the catch? The same thing that makes this useful makes it risky. Atlassian says the CLI and MCP path respect existing permissions, and the CLI does not store or process customer data outside Atlassian infrastructure. But once agents can traverse org structure, work history, and linked systems, governance matters a lot more. Bad perm(atlassian.com)uched something it should not have.” (developer.atlassian.com) ### Bottom line This is really a bet on context as infrastructure. Plenty of companies are building agents that can do tasks. Atlassian wants to be the layer that tells those agents what the work means, who it affects, and what they are allowed to do next. (atlassian.com)