Almost every leader we talk to is being asked the same question right now, and very few of them realize it’s a trick question. The question is “what’s our AI strategy.” The trick is that the real answer isn’t a strategy at all. It’s an architecture decision, and most organizations are making it without noticing they’re making it.
Here’s why. The agent is the easy part now. Capable models have become something you buy by the seat, and the gap between the best and the second-best narrows every quarter. What actually separates the companies getting real value from the ones quietly funding a graveyard of pilots is something less visible: where the AI sits relative to the work, and how much of the organization’s real context it can see from that position.
An agent is only ever as good as the context it can reach. So the question that looked like it was about AI turns out to be about architecture, and the architecture is something most companies already have, assembled by accident over years of buying tools one problem at a time.
There are two credible ways to answer it. They lead in different directions. The difference matters more than the marketing on either side suggests.
Answer one: put the intelligence inside the platform
The first approach puts the AI layer inside the platform that already encodes how a domain operates.
The strongest example in the market today is Atlassian’s Teamwork Graph. Two decades of work have accumulated inside Jira and Confluence, and that history is not just a pile of tickets and pages. It’s a map of how an organization actually runs: which projects depend on which others, who owns what, which decisions were made and why, how today’s incident connects to last quarter’s change.
Atlassian has spent the last year turning that map into something its agents can reason over. Rovo gets meaningfully smarter as the graph fills out, because it inherits context no general-purpose model could reconstruct from scratch.
When one platform genuinely owns a domain end to end, this is the right answer. And it isn’t close. Picture a release manager heading into a launch review. The question on their mind is which unresolved dependencies could derail the quarter. Inside a well-tended Atlassian environment, an agent can answer that in seconds, because the dependencies, the owners, the blocked work, and the related incidents already live in one connected structure. The intelligence is useful precisely because it never has to leave the place where the work lives.
The limit is the same as the strength. This approach is powerful inside the domain the platform owns, and it has little to say about everything outside it.
Answer two: put the intelligence across the stack
The second approach starts from a fact every leader knows but few architectures account for: no organization runs everything through one platform.
Engineering may live in Atlassian, but sales lives in the CRM, finance lives somewhere else again, and the executive team lives in mail and calendar. A knowledge worker’s actual day crosses six or eight systems. The work that matters most often happens in the spaces between them, where no single platform has authority and no single graph has visibility.
The across-the-stack approach puts the AI layer there, in the flow of the user’s work rather than inside any one domain’s data model. Superhuman is the platform we’re betting on for this, because it’s built to meet people inside the tools they already use and to carry consistent governance across all of them, rather than asking the organization to re-platform onto one vendor’s world.
Picture an account executive preparing for a renewal. The history they need is scattered: the deal in the CRM, the implementation issues in a support tool, the contract terms in email, the relationship context in three months of meeting notes. No domain platform owns that picture, because the picture isn’t a domain. It’s a person’s job. An across-the-stack layer can assemble it because it follows the user instead of the system.
The limit here is the mirror image of the first approach. This layer goes everywhere, which means it rarely has the deep, structural context that a domain-owning platform accumulates over years.
Where the clean line breaks down
It would be tidy to draw a clean line between these two and tell you which side to stand on. The truth is messier.
The line is moving. Atlassian is building outward, not just inward. Its support for the Model Context Protocol (MCP) and its growing library of connectors are bets that other systems and other agents will increasingly reach into the Teamwork Graph, and that the graph will reach back out. Meanwhile, the across-the-stack platforms are developing real depth inside their own surfaces, so the breadth-versus-depth contrast softens a little every quarter.
What stays distinct, underneath the converging features, is the organizing center of gravity. One approach is built around the data model of a domain and reasons outward from there. The other is built around the user’s flow of work and reasons inward toward whatever systems that work touches. Those are genuinely different design philosophies, and they will stay different even as each one borrows capabilities from the other.
Which is why the question for most leaders was never “which one wins.” Both will be present in any mature environment. The within-the-platform layer will keep getting smarter at the work it captures, and the across-the-stack layer will handle everything that lives in the gaps.
The useful question is narrower and more practical: which of the two is missing in your organization right now.
A way to tell which one you’re missing
You can usually find the answer by asking where the friction actually is.
If the work that matters most runs deeply through a single platform, and the complaint you hear is that your people can’t get good answers out of a system that clearly holds the data, you are probably under-invested in the within-the-platform layer. The context is there. Nothing is reasoning over it.
If the work that matters most crosses many systems, and the complaint you hear is that AI helps in pockets but nobody can see value at the level of a whole role or a whole team, you are probably under-invested in the across-the-stack layer. The intelligence exists inside individual tools. Nothing is following the person between them.
A few questions tend to surface which case you’re in:
- Where does the work that matters most actually live, and is it one platform or many?
- Which of your platforms genuinely own a domain end to end, and which only own part of it?
- Where would AI need to follow a person across tools to be useful?
- And where do governance, audit, and measurement need to be consistent across systems rather than configured one tool at a time?
None of those questions require a finished AI strategy to answer. They require a clear look at how work moves through the organization you already have.
The decision you can’t get wrong by moving
There’s a quiet anxiety underneath the “are we behind” question. The anxiety assumes there’s a single right architecture, that choosing wrong is expensive, and that the safest move is to wait until the picture clears.
The opposite is true. Because both layers will end up mattering, and because the right place to start is almost always one team and one workflow, this is not a decision you can get catastrophically wrong by moving.
It’s one you can only get wrong by waiting. The organizations that will look prescient in two years are not the ones that picked the correct architecture in advance. They’re the ones that put something real into motion early, learned what their environment actually needed, and let the strategy follow the evidence instead of preceding it.
That is the work, and it’s why we sit where we do. As an Atlassian Platinum Solution Partner and a Superhuman Alliance Partner, we work across both sides of this choice. Not because we’ve decided one of them wins, but because the honest answer for most organizations is some of both. The architecture is the question. We help you find the first place to start answering it.
If you’re trying to work out which layer is missing in your environment, and where a sensible first step would be, reach us at contact@e7solutions.com.
