Why context is the biggest unlock for your AI strategy

The company positions connected knowledge as the difference between generic outputs and business-relevant results.

You have probably watched a colleague paste a prompt into ChatGPT, receive a plausible answer and then spend twenty minutes rewriting it to match your company's actual process. The gap between what a foundation model knows and what your organisation does is context, and Atlassian has published a case that context – not model size or parameter count – determines whether AI delivers value or busywork.

The argument rests on a simple claim: general-purpose models trained on the public internet cannot know your customer segmentation, your compliance requirements or the three-year thread of decisions buried in Confluence pages. Without that organisational memory, every AI interaction starts from zero. You get grammatically correct prose that ignores the fact your team retired that workflow in Q2 or that your largest customer negotiated different SLAs. The cost is not just accuracy. It is the hidden tax of editing, clarifying and re-prompting until the output reflects reality.

What connected context means in practice

Atlassian frames context as the connective tissue between people, knowledge and work. In their architecture, that means linking project trackers, documentation repositories, chat transcripts and code commits so an AI agent can answer a question like "Why did we deprioritise feature X?" by surfacing the Jira ticket, the Slack thread where the product manager explained the trade-off and the Confluence page that recorded the customer feedback. The model does not invent a reason. It retrieves the actual decision trail.

This is not a novel idea in information retrieval, but it is still rare in enterprise AI deployments. Most organisations bolt a chatbot onto a single data silo – the HR portal, the CRM, the learning management system – and wonder why adoption stalls. The bot can summarise a policy document but cannot tell you whether anyone followed it, because the follow-up lives in email, the exception lives in a spreadsheet and the outcome lives in a quarterly review deck. Context is fractured, so the AI is blind.

Why this matters for L&D and innovation teams

Learning and development leaders face a version of this problem every time they design a capability programme. A course on prompt engineering teaches syntax, but it cannot teach someone how to write a prompt that pulls the right context from your company's knowledge graph. That skill requires understanding where your organisation stores decisions, how teams label work and which systems talk to each other. It is domain knowledge dressed up as technical skill.

Innovation teams hit the same wall when they try to scale experiments. A pilot succeeds in one business unit because the team manually curated the context – they knew which documents mattered, which stakeholders to loop in, which legacy systems to avoid. When you try to replicate that pilot elsewhere, the context does not travel. The AI works in the lab and fails in the wild, not because the model changed but because the knowledge graph did not extend.

Atlassian's framing suggests that the next frontier for AI enablement is not teaching people to write better prompts. It is teaching them to build and maintain the context layer that makes any prompt useful. That means data governance, metadata hygiene, cross-system integration and a culture that treats documentation as infrastructure, not overhead. It also means rethinking how you measure AI literacy. Fluency is not knowing which model to call. It is knowing which context to feed it.

The organisational design question

If context is the unlock, then someone has to own it. In most companies, no single team is responsible for connecting Jira to Confluence to Slack to the CRM. IT owns the pipes, product owns the roadmap, operations owns the process docs and everyone owns their own corner of the knowledge graph. The result is a fragmented context layer that no AI can navigate without constant human translation.

Atlassian's pitch is that their toolchain solves this by design, because the same vendor built the project tracker, the wiki and the chat layer. That is a product argument, but it points to a structural truth: connected context requires either a platform that integrates by default or a deliberate effort to integrate platforms that do not. Most organisations are trying the latter without the governance, the metadata standards or the cross-functional ownership to make it work.

For L&D and digital transformation leaders, this is a capability gap that no amount of prompt-writing workshops will close. If your AI strategy assumes people will manually gather context every time they need an answer, you have built a system that does not scale. If your AI strategy assumes the context layer already exists, you are probably wrong. The work is not teaching people to use AI. The work is building the organisational infrastructure that lets AI use your knowledge.

What to do Monday

Start by auditing where your organisation's context lives. Map the systems that store decisions, the tools that track work and the repositories that hold institutional knowledge. Identify the gaps – the handoffs where context gets lost, the silos where it never connects, the formats that no system can parse. Then ask whether your AI pilots are succeeding because the model is good or because someone manually stitched the context together. If it is the latter, you have found the bottleneck.

The next step is governance. Decide who owns the context layer, what metadata standards you will enforce and how you will measure whether context is actually connected. This is not a technology project. It is an organisational design project that happens to involve technology. The companies that get this right will have AI that knows their business. The companies that do not will have AI that knows the internet and a workforce that spends half its day translating between the two.

Sources:

• Atlassian Inside blog