Agents need more than access to your tools. They need connected context that shows how work fits together, and where the boundaries are.
An account team is preparing a customer renewal, and the customer is asking for a discount beyond standard policy. The contract and the discount policy sit in different systems. A recent support escalation has changed the tone of the conversation, a similar case came up in Slack last quarter, and someone approved a different arrangement for this account.
An experienced teammate knows what to check: which approval applies, who owns the next action, and whether that Slack precedent is relevant. Now ask an agent to recommend the renewal terms: can we renew at a 15% discount? It needs the same operating context. You might expect a connector to solve this. In reality, connecting an agent to 5, 50, or 500 systems doesn’t automatically give it the context it needs.
Earlier in this series, we explained why context is the biggest unlock for an AI strategy, and how completeness, connectedness, and relevance drive context quality. This installment goes a level deeper: how does a context graph turn connected data into something an agent can act on, and how does the agent know when to stop and check with a person?
Finding information is not understanding the decision
Every document in the renewal may be relevant, but only some establish what the team is authorized to do. A policy defines standard terms. A contract defines this customer’s commitments. An approval may change those terms, but only under specific conditions.
Take a question like: “Can we renew Acme’s contract at a 15% discount?” Answering it means pulling the contract from the CRM, the discount policy from a wiki, and the approval from a ticket. Most agent setups combine two techniques for this.
Retrieval-augmented generation (RAG) gives the model relevant information before it responds, usually through vector search, which returns the content that looks most similar to the question. Model Context Protocol (MCP) is the access layer: it gives the agent a standard way to call tools, so it can fetch the contract, the policy, and the approval from each system. In short, MCP gets the agent to the data, and vector search helps it find the relevant passages within it.
Both are useful. But similarity is not authority.
Vector search can surface the discount policy and the approval side by side because both address discounts, yet neither result says which applies to Acme, in this region, for this contract period. MCP has the same blind spot from the other direction: it returns what each tool holds, but not which result matters most or how the results relate to each other and to the question.
So the agent has to work out those connections during the task. Without relationships mapped in advance, it must search repeatedly, resolve references (which “Acme”? which version of the policy?), compare dates, and guess at authority, on every question, from scratch.
The risk is not that models cannot infer relationships. It is that what they find may be incomplete, conflicting, or expensive to assemble again for every request.
That is the gap a context graph fills.
What is a context graph?
A context graph maps the recorded relationships around work: this escalation belongs to this account, this approval governs this exception, and this person owns the next step. With those relationships mapped, an agent can reason over a connected picture of the work instead of a pile of similar-looking results.
Unlike a general knowledge graph, which models what things are, a context graph models how work operates: who owns what, what was decided, and what applies now.
In Teamwork Graph, those relationships are maintained and evolve as work happens, captured from the tools teams already use, so agents do not have to rebuild them for every task. That is why connecting more tools is not enough on its own. Tool access gets the agent to each record; maintained relationships tell it how those records fit together.
Connected context changes the answer
Let’s go back to the renewal from earlier and add one connected source at a time. Each one changes what the agent can conclude.
Start with the policy and contract. The agent can see that the requested discount needs an exception. That is useful, but it can’t yet say why an exception deserves consideration or who can authorize one.
Add the support escalation linked to the account. Now the agent can see why urgency and commercial risk have changed. The recommendation gains business context, but urgency alone is not approval.
Add the Slack discussion of a similar case. It may reveal precedent or conditions worth investigating. But a recent message about another account should not silently become authorization for this one, or outrank an older, approved policy.
Finally, connect the recorded approval and the account owner. The agent can check whether an authorized exception applies to this customer, region, and period, and identify who owns the next action. If the approval is missing or conflicts with other sources, the right next step is review, not an assumed override.
The value comes from the relationships, not the number of sources retrieved. Adding one more connected source can surface the constraint that changes the answer: an expiration date, a dependency, an owner, or a condition on the approval that the other sources do not show.
This is what compounding context looks like in practice. The team does not just get a more detailed summary. It gets a recommendation grounded in how its work actually fits together, with any uncertainty made visible.
The figure below shows the same renewal side by side. With tool access only, the sources arrive disconnected and the agent has no clear path. With Teamwork Graph, maintained relationships give it a path forward, and a clear point at which to stop and check with the owner.
What happens between the question and the answer
Connected context does more than help an agent find the right records. It also shows where connections are missing or in conflict, and where a person needs to check. Teamwork Graph connects context across people, work, knowledge, communications, code, assets, and data, so agents can retrieve the relationships around a task rather than a set of isolated records.
One way to picture how this shows up for an agent is a bounded journey, where the agent takes only the steps the task needs. The steps illustrate the work involved.
Teamwork Graph handles the connected parts, resolving records and following relationships within the user’s access, so the agent doesn’t have to rebuild them each time.
- Establish the user and task. Who is asking, what they need, and what they are allowed to request.
- Find the starting records. Resolve the customer, project, or service. If the match is ambiguous, ask rather than guess.
- Follow relevant relationships. Retrieve only the connected context the task needs, within the user’s access.
- Read the necessary detail. A title can locate an approval; its conditions decide whether it applies.
- Recommend with context. Show what supports the recommendation, flag what is unresolved, and leave any action to its own permission check.
In the renewal example, the agent ends with a context packet: the specific context that supports its recommendation, and nothing more. Because that context is connected, the packet can show what was recorded, what was only inferred, and where sources conflict.
“A similar customer received a discount” is a lead to verify. “This account’s recorded approval covers these terms until this date” is a claim the team can act on. When the agent can only reach the first kind of claim, it says so and routes the question to the account owner. Stopping with a well-supported question beats completing an unsupported action.
That raises a bigger question for leaders: where should this context live, and who should be able to use it?
Where does context fit in your AI strategy?
Make your context high quality, governed, and available to the models and tools your teams choose.
Use your context wherever your teams work. Teamwork Graph is native to Rovo, so Rovo Search, Chat, and agents work from it by default. Teams building elsewhere can bring the same context into the agent or coding tool they already use, through Teamwork Graph context tools in Atlassian MCP or the Teamwork Graph CLI.
Atlassian’s MCP server does more than expose Atlassian data. Its Teamwork Graph tools connect agents to context from Atlassian apps and connected tools, already mapped with relationships and permissions. What an agent can retrieve or change still depends on the permissions of the identity it acts as, whether that’s a person or an agent account.
Invest in the graph, not a single model. With models and agent clients changing all the time, your most durable investment is your operating context. Because agents reach context through consistent paths (MCP and CLI), you can bring that context with you across models and agents without getting locked into a single AI vendor.
Layer context to better enable your agents. Few organizations will rely on a single source of context. Just as a team draws on people with different expertise, an agentic system may draw on more than one source of context. Teamwork Graph’s role is the context of cross-team and cross-tool work: who owns what, how work connects, and what was decided. Connecting more sources enriches that picture, and agents can use it alongside systems that hold other kinds of context.
Richer context still needs boundaries. The goal is not to give an agent “all the context,” but the context appropriate to the user and task. Retrieved content should remain evidence, not become instructions that override the application’s controls, and a recommendation is not permission to act. Context engineering for better AI outcomes covers how to scope, govern, and maintain that context in practice.
The architecture serves the team
The most important part of a context graph is the team behind it: the people who establish ownership, record decisions, maintain sources, and recognize when an exception needs review. A graph cannot recover knowledge that was never recorded, or settle a disputed policy by adding another relationship.
The goal is not to create a new divide between teams with AI expertise and teams without it. It is to make the context already created through teamwork usable by every team.
So what should teams take from this?
- Access is not connection. Connecting an agent to more systems doesn’t connect the work inside them; the relationships between records are what turn search results into an answer.
- Maintain relationships once. Kept as shared context, they serve every model and agent instead of being rebuilt task by task.
- Keep the boundaries. Good context is scoped to the user and task, treated as evidence rather than instructions, and kept separate from permission to act.
That work starts with building quality context. Teams run on context. Keep it connected and governed, and the agents working alongside them can run on it too.
See it work. Join our upcoming webinar to learn how better context delivers AI outcomes that drive org-wide transformation.
Register: Driving AI transformation with Teamwork Graph
