Team '25 Europe - some pointers from Atlassian to the next phase of agentic systems of knowledge

There were a couple of interesting milestones in the evolution of enterprise AI bubbling under the surface at Atlassian's recent Team '25 Europe event. One of them was the vendor's move to open up an API to access its Teamwork Graph, which has previously been an entirely closed but crucial element of its platform — the graph's scope also expanded materially to include physical assets. The second was the emergence of a new way of thinking about agentic automation that I've started to hear from other vendors too, which uses the notion of skills as a set of discrete building blocks of automation that AI agents can call on in order to complete a task.

These two developments are important because they speak to a core issue when harnessing generative AI for use at work and in the enterprise, which is how to combine its probabilistic strengths with the deterministic outcomes that characterize many aspects of enterprise operations. Generative AI is great at figuring out meaning and intent, but only if it has all the relevant context to fully understand what it's interpreting, which is where the Teamwork Graph comes in. It's less good at carrying out tried and tested business processes — you don't want it randomly trying out new ways of doing things that have to meet rigorous compliance standards — you want it acting in a pre-determined way when necessary, which is where skills come in.

The art of constraining generative AI's probabilistic guesswork to make sure that the answers conform to what the enterprise needs is known as context engineering. But where does the context come from? This is where I find the concept of systems of knowledge helpful. Enterprise applications and their underlying data models already have much of that context implicit within their structures. It's through constructs like knowledge graphs and agent skills that we're learning how to make that context explicit.

Knowledge graphs

A knowledge graph, for example, maps key points of information and their relationships, providing crucial context about what's important within the organization and how all the various elements are connected to each other. This acts as a foundation for effective context engineering that helps AI's Large Language Models (LLMs) discern what's important and relevant, and lessens the risk of inappropriate responses.

While some vendors have rushed to build out knowledge graphs, others have had a head start. Teamwork and work management vendors have been developing graph databases for the past decade, because they already needed to understand the relationships between people, tasks and goals. They've been quick to adapt this earlier foundation to become a key part of these systems of knowledge that LLMs rely on to make sense of an organization's data and processes. But so far, these knowledge graphs have been proprietary, closed systems within each vendor's architecture, with no means of exchanging their context mappings with other vendors' applications, data stores and graphs.

Atlassian has now taken the first steps towards opening up its Teamwork Graph. It has introduced APIs that allow developers to fetch information from the graph for use within their own custom applications, AI agents or business objects built with Atlassian's Forge app development platform. At the same time, it has made it easier to connect external data into the graph, with pre-built connectors to popular platforms such as HubSpot and Databricks, as well as the ability to build custom connectors to other platforms or data stores. It has also expanded the scope of the graph with the addition of assets, bringing information about the physical world and digital assets into the same realm as the existing knowledge objects. This is a significant development, which means that physical objects can now be linked to knowledge items such as work orders and project status, or included in agent workflows.

The connections to other systems acknowledge the reality that customers are using Atlassian products — and the platform's underlying System of Work — alongside other vendors' products. In effect, every enterprise has their own 'system of work,' as Atlassian calls it — what I'm calling a 'system of knowledge' — that is broader than any individual vendor's platform. Tiffany To, EVP Enterprise & Platform, explains:

When I looked at what [the customer] had built, the system of work that they've created in their company, it was never a closed system of our tools. It was always, 'Here's the Atlassian products I've got, and then I have these dev tools from Microsoft, and then I've got ServiceNow, and then our teams are maintaining these integration points between all these tools.' So they were having to create this system of work themselves...

I think for a platform to be viable, especially with AI and agents orchestrating between the platforms, if you don't open up your system so that you can integrate well with other systems, I don't think customers will accept that, because there's no vendor that's going to provide a complete system for a customer.

Skills

While the graph provides the context and connections between people, knowledge, tasks — and now physical objects — skills contribute the know-how about how work gets done. Whereas most vendors to date have been building out a collection of agents that each fulfil a specific task or role, Atlassian has broken out the individual tasks into a catalog of various skills — automated actions that can be invoked in conversation with an agent, such as summarizing a document, scheduling a meeting, or compiling a project status update.

These skills might be provided by Atlassian, custom built by the customer, or fetched from third-party apps — connections to Canva, Databricks, Figma and Lovable, among others, were shown during the Team Europe event. Initially users will have to invoke skills by name, but in the future it's anticipated that Atlassian's Rovo AI agent will automatically select the relevant skills to complete a task. Sanchan Saxena, Head of Product, Teamwork Collection at Atlassian, explains:

The world is going to get filled with agents. There's going to be hundreds of thousands of agents from Salesforce, and other ones from ServiceNow, and other ones from Microsoft. Basically what we're saying is that the burden of knowing which agent to use in which context now belongs to the end user. Atlassian is taking a very different stance, which is, you don't need to know the agent name, how many types of agents exist, et cetera. We're going to build those as skills inside of Rovo, so you only interact with Rovo... It's your thought partner, and Rovo can figure out what are the right skills.

Right now, the demos you're seeing are skills that you have to manually specify — 'forward slash, status-update.' But you can imagine, very soon as this technology evolves, all you tell Rovo is, 'I just want to send a status update.' It knows which skill to use to create that. But in our competitors' world and the industry's world, here's what the customer will have to know: 'What is the name of the agent? What does it take as an input? Where does it put all that output?' It's crazy. So that's the strategic choice we're making.

My take

There are two important developments here. First of all there's the evolution from task-specific and role-based agents towards a more composable architecture in which the component actions, or skills, are assembled as needed by an orchestration agent that is able to match the user's intent to the skills required to fulfil the desired outcome. Another vendor that's been talking about skills recently is integration and workflow automation specialist Workato, whose CEO, Vijay Tella, sees this model as a way of channeling agent behavior into proven patterns that are less prone to going rogue. He defines a skill as a repeatable, trusted action that is always done in a consistent way:

Instead of re-learning to tie your shoelaces every morning you just know what to do because you’ve learnt the skill. Enterprise skills are like this for agents — as well as guaranteeing consistent outcomes they also build up agent ‘muscle memory'.

This seems like a much more elegant approach than hardwiring agents to emulate specific workforce roles or duties, especially because it enables reuse of the same skills in different contexts rather than building the same functionality in slightly different ways each time. A more composable architecture is also more amenable to iterative evolution over time, since individual skills can be swapped out as new capabilities emerge, rather than having to rebuild the entire agent each time.

The other interesting development is the opening out of proprietary graph databases to allow for easier interchange of these maps of enterprise context. I've always believed that this would become inevitable, with common standards eventually emerging to connect proprietary knowledge graphs, but it's been a long time coming. I'm intrigued to see Atlassian recognizing the need for this, and also realizing that this means it's going to have to compete on intrinsic merits as the marketplace opens out. As To says:

If we at Atlassian are going to build a really effective way for teams that are across the entire company to work together, then we have to have a strong integration story and have some differentiated value in that larger ecosystem. To me, that's very much about us understanding the relationship between the teams and the work.

It's significant also that Atlassian recognizes that its own System of Work is just one element in a broader platform within each enterprise customer. I used to talk about the need for enterprises to consciously create their own Collaborative Canvas for digital teamwork that connects across the various work management and collaboration apps they use. That need is even more pressing in the agentic era, providing a connective fabric for all of the enterprise knowledge and know-how — the systems of knowledge — that guide AI towards the outcomes that make most sense for each enterprise.