Asana runs AI agents as role-scoped teammates with shared memory and public activity feeds, and details three deployments in sales Q&A, renewal-risk digests, and engineering loops

Asana has agents operate within its existing Work Graph rather than adding new context structures for AI: agents have defined roles, are assigned tasks, read and write messages, and appear in activity feeds alongside human collaborators. Compared with treating AI as a standalone chat tool, this places agents inside the existing web of tasks, projects, goals, and conversations, with additional safeguards around what agents can access and share. Based on an interview with Asana Chief Product Officer Arnab Bose; it is a company's own account of practice, with no quantitative comparison or controlled experiment reported.

Each agent has a profile page listing its name and purpose, the people who can use it, administrators, instructions, skills, integrations, and permissions; its effective access is bounded by the permissions of the person who triggers it. On top of explicit access controls like those applied to human users, this adds a triggerer-permission ceiling, allowing agents broad access to public content while minimizing the risk of anyone accessing information the agent learned in a private context. Presented as Asana's stated design ("Asana says") and supported by Arnab's description of Asana as "a contained work surface"; no security testing or audit data is provided.

Shared memory lets an agent retain information from previous instructions so multiple users can reuse it to complete tasks faster; only admins and editors can commit feedback to permanent memory, undo, or delete from it, while everyone else's feedback applies only to the current task. It makes "who can change agent behavior" a role-based permission rather than open to all; the piece illustrates this with the communications team holding the pen on voice and tone as editors and admins of a writing agent, while Arnab can draft with it but cannot modify its behavior. A mechanism description plus one concrete role-division example from the interview; it is a statement of design intent, with no measurement of efficiency gains from memory reuse.

Three deployments show concrete agent work: Slack channel questions become Asana tasks handled by an agent (replying with source links when approved guidance exists, creating a product-team intake task when there is no approved answer, and creating an enablement task when the same question keeps recurring); the At-Risk Renewal agent reads every at-risk renewal task across the global portfolio, including each CSM's updates, status notes, and comments, and generates a structured daily digest in three buckets—positive momentum, negative momentum, and recommended follow-ups—running a global view first and then cutting by region, pushed automatically each morning to the Chief Customer Officer, the Chief Revenue Officer, and every regional customer success leader; on the engineering side, Command by Asana manages the automated coding loop, with a team space holding 10 to 12 engineers, agents populating the unplanned board with tickets pulled from customer feedback and Slack feedback-channel comments, and Command predicting cycle completion with optimistic, balanced, and conservative estimates. Compared with an individual generating a report with Claude alone, these cases emphasize standardized reports, a shared workspace, and a report that "keeps getting better with every single run"; the piece also notes that automated coding loops made cycle times and releases slip because cycles were bloated by automatically generated changes, and quotes "Code generation is now no longer the bottleneck. The bottleneck is around planning, decision-making, and refinement." All are internal practice narratives and interview quotes with specific roles, flows, and recipients, but no public metrics, sample sizes, or comparison results.

This article is aimed at product, engineering, and operations leaders bringing AI agents into team workflows, especially teams already using Asana or a similar collaboration platform. It applies where work is already structured into tasks, projects, and goals, and where the organization is willing to define roles, permissions, and memory-write rules for agents. The three cases—Slack question routing, the renewal-risk digest, and Command managing the coding loop—offer reusable process templates: who designs the team, who serves as agent admin and editor, and how agents push results into a shared space where people can follow up and coach.

The article reports no quantitative results on efficiency, quality, or risk, so statements such as freeing up enablement team time, the report improving each morning, and cycle times and releases slipping should be read as the company's own observations rather than reproducible measurements. The long-term effects of shared memory, how the triggerer-permission ceiling behaves under complex permission combinations, and the practical collaboration impact of agents publicly posting research plans and steps all still need more independent evidence. In addition, this is the third post in a series, and some concepts (persistent memory, their own credentials, shared context) are developed in the earlier post, so readers of this piece alone may have a limited view of the full definitions of those three capabilities.