Asana frames shared memory as the missing layer in enterprise agents
Asana's Chief Product Officer Arnab Bose argues that the missing layer in enterprise AI agents is shared memory, not smarter models. The company frames its Agentic Work Management platform as the procurement-level answer to agents that learn for one user and forget the next. That framing centers a real problem, but it also maps neatly to Asana's product position, and the source does not establish that shared memory is the only or best place to draw that line.
The numbers Asana leans on are its own. According to Asana's research, 75% of knowledge workers use AI on the job, but only 5% of companies have reported productivity gains. That gap is the source's entire justification for treating shared memory as a procurement criterion. The 70-point spread is large, and the 5% figure is striking. Both come from a survey the company itself runs, with no independent methodology described in the source. Treated as a market fact, the spread would justify the procurement framing. The source does not present the methodology behind the survey, so the comparison rests on Asana's own numbers.
The technical problem the source describes is real. Models are stateless by design, and any memory has to be a separate layer outside the context window. For a single user, a personal memory layer is manageable. For a team, every agent acting for an individual creates version drift, repeated work, and the kind of contradictory outputs the source flags. Asana's answer is a context graph that is automatically fed to every agent operating inside its system, so the same correction propagates to every team member. The product claim is that this becomes institutional knowledge rather than individual scaffolding.
The source treats shared memory as a problem with a single shape. It is not. A team-wide memory layer introduces its own questions that the source does not unpack: who writes to it, who controls write access, how stale entries are pruned, how conflicting updates are reconciled, and what happens when an agent reads a correction that was wrong. The third-party quotes in the source, from Collate's Sriharsha Chintalapani and Zeta Global's Neej Gore, lean toward the same shared-memory-is-missing conclusion, but neither quote addresses those write-side questions either. The source frames memory as a retrieval problem; in practice, it is at least as much a consistency and governance problem.
Microsoft's Copilot, named in the source as a contrast, takes the opposite path. It builds a personal memory layer that learns a user's role, tone, and working patterns, then applies them across Microsoft 365 surfaces. The source presents this as an individual-first approach that the market has moved past. That framing is itself a position, not a finding. Microsoft's choice reflects a different theory of the problem: in many enterprise workflows, the unit of useful context is the individual, and team memory creates privacy, access-control, and discoverability surfaces that an individual layer avoids. Neither approach is "correct" on the evidence the source provides. The procurement framing Asana advances is consistent with its architecture, but the source does not benchmark shared memory against personal memory for any specific task.
Asana's shared context graph demonstrates that one team can correct an agent once and have that correction apply everywhere inside the Asana system. That is a deployment claim, not a productivity claim. The source does not provide throughput numbers, error rates, time-saved measurements, or a comparison group. Calling shared memory a procurement criterion implies a level of evidence the source does not produce.
The source leaves one question outside the framing: what shared memory costs. A memory layer that survives schema changes, agent upgrades, and team turnover is a long-running distributed system. The relational-retrieval design Chintalapani describes requires infrastructure the source says few organizations outside the largest model providers can build. The procurement framing in the source assumes that buying a platform with shared memory is the answer. In practice, the operating cost of the memory layer itself, and the question of who maintains it as the team's work changes, may move the bottleneck rather than remove it.