The Promise of the Teamwork Graph
Atlassian announced its Teamwork Graph in May 2026, promising to solve the “context gap” for agents. According to the announcement, “The Teamwork Graph connects those dots, stitching together people, goals, code, and content across Atlassian and other connected SaaS apps. It becomes your enterprise’s living map of how work actually happens. That graph now holds over 150 billion objects and relationships, and every Jira update, every pasted link, and every connected tool compounds the context your AI can reach. By mapping these connections before AI starts reasoning, the Teamwork Graph gives your agents the precision of a teammate who’s been there since day one. This provides a rich work context for AI agents, helping them understand who is working on what and how tasks are connected in the execution layer. It is a significant step forward in making organizational data accessible and connected.”
… But Critical Elements are Missing When It Comes to Your Product Operating Model
While the Teamwork Graph is excellent at connecting people, goals, work, and code, as its name suggests, there are still critical gaps for agentic product organizations.
- Graph is not ontology. A reliable agentic operating model at scale relies on an ontology-based operating foundation where data, meaning (unified semantics), and interactions come together. A graph tells an agent that two things are connected. An ontology tells it what each thing is, what the connection means, and what should happen when one of them changes. Many tools, including Jira, are highly decentralized: a “goal” field in one project could mean something different from a “Goal” in another, and a Jira project can represent a team in one place and an initiative in another. The graph links these records without resolving what they mean, so it lacks the granular semantic context of a product operating ontology to ensure data means the same thing across teams and workflows. Without it, every agent infers meaning on its own, and across hundreds of teams and agents those inferences drift apart.
- Jira core reflects team work ontology. Jira holds work the way Salesforce holds customers. It enables the scope of team work: issues, epics, sprints, workflows, and the people doing them. But Jira’s work ontology does not reflect product operating ontology, where strategy, insights, investment, business unit, funding entity, intakes, segments, capacity allocation, product catalog, portfolio, and outcomes each carry their own objects, relationships, and rules, and those sit outside the work domain. Connectors can bring more of that data into the graph, but data in a graph isn’t a domain model with rules. When a delayed epic threatens a customer commitment funded by a strategic goal, the work ontology sees the epic. The product operating ontology sees the commitment, the investment behind it, and the trade-off a leader needs to make.
- Adding collections of products does not make a unified operating plane. Each collection brings its own data model and its own view of strategy and product, so the same goal can sit in different fields across Jira Product Discovery, Jira, and the Strategy Collection. The graph connects them but doesn’t unify their meanings. And connectivity of a graph is passive. Agents can act on the graph, but nothing in it tells them what should change. The graph can show that work is linked, but it doesn’t evaluate ripple effects, dependencies, and consequences against domain rules, before a decision is made or after a change lands. An ontology with unified semantics and a domain model makes those visible. Without one, teams pairing a graph with agents end up building their own logic for every workflow, every time. That approach doesn’t scale, breaks as the operating model changes, and leaves each agent reasoning from a different version of reality.
The Complement: Bring Teamwork into Product Portfolio Ontology
Agentic product enterprises don’t need to replace Jira’s work ontology. They need to connect it to a product operating ontology built to turn work into outcomes. Dragonboat connects Jira’s work into its Product Portfolio Ontology and adds three things the graph lacks:
- A more complete graph with native interconnection. Work is not product. Work ends, but product persists after. In Dragonboat, product is a native object, alongside strategy, insights, investment, funding, intakes, capacity allocation, product catalog, portfolio, customers, outcomes, and other operating objects, connected to the work in Jira and the other tools cross-functional teams use, so upstream intent and downstream impact are traceable in both directions.
- Unified semantics. Dragonboat maps differing fields and project types across tools into the same objects, so a goal means the same thing in every team, tool, and agent interaction.
- Domain intelligence. Encoded product-domain rules evaluate progress against intent, surface risks and ripple effects, and write decisions back to Jira and other connected systems.
With an operating ontology, the model is elastic. When objects or logic change or shift, there’s no need for a major rebuild of the workflows and agents running on it. And instead of passive connections, ambient agents, powered by ontological data, context, and domain intelligence, run on your product operating model for continuous eval of intent vs. reality across all aspects of the operating graph. They detect drift and risks and recommend fixes. People and agents work from the same operating reality, so the organization can run at scale and drive outcomes, not just output.
Product Portfolio Ontology is the Critical Foundation for the Agentic Organization
To operate an agentic organization, you need to connect team and work with product portfolio context — with active, ontology-powered, semantically unified context, connected with the broader enterprise OS — to continuously calibrate intent and reality across strategy, investment, customers, revenue, PDLC execution, and outcomes. That’s Dragonboat, the Product Portfolio OS for the agentic enterprise. (view Dragonboat Platform)
“Dragonboat gave us what Jira and slides alone couldn’t: one place where OKRs, roadmaps, and capacity connect, so leadership, teams, and stakeholders see the same picture. We went from scattered plans and misaligned priorities to a single source of truth — and could finally have the real conversations about what to stop and what to bet on. That’s when strategy-to-execution actually started to work.”
– Michael Haizmann, Product & Operations Lead, Consultant, and Coach, Blacklane
Want to learn how leading companies accelerate outcomes with Dragonboat? Check out Blacklane’s success story.
Get started quickly. No migration required. Book a call with one of our product experts.
