How Asana Builds Coachable AI Teammates: Feedback and Shared Memory

A salesperson asks an AI writer to make one customer invitation warmer. The next day, another colleague needs a restrained product announcement. Should yesterday’s correction change that announcement too?

A useful AI teammate needs a way to distinguish a request for this task from guidance that should influence future work. The team also needs to know who can make that change and how to correct it later. Those decisions determine whether repeated work builds usable experience or a pile of contradictory preferences.

Anthropic’s September 29, 2026 Asana case study examines agents with defined roles, shared work and controlled feedback. This is an independent analysis of that approach, supported by Asana’s engineering and product documentation. The launch scenario below is fictional and has not been run in an Asana account.

The question we will follow is practical: how can one person improve an AI colleague’s work in a way that helps the next person, while preserving the right facts, access and decision owners?

Asana is a work and project management platform. Its AI Teammates are agents embedded in team workflows, with roles, Skills and connected applications. They use the Work Graph, Asana’s structured relationships between people, tasks, projects, goals and dependencies. Product overview

Consider a launch brief. A document can contain a persuasive paragraph, but the surrounding work needs more information: who owns the release facts, which feature is still pending, who reviews the wording and what happens after approval.

Our reading is that Asana’s advantage here comes from placing the agent inside an existing record of work. A colleague can review the assignment and its output in the same place where the team coordinates delivery. The agent has a role within a process that already has owners and dependencies.

That is a useful direction for enterprise AI: teams can evaluate a contribution against an actual assignment. A fluent answer becomes more valuable when someone can see its sources, correct it and decide whether the work is ready for the next step.

In the September interview, Asana distinguishes feedback on a current task from feedback committed to permanent memory: admins and editors control the latter, including undoing or deleting it. The coaching model

This gives knowledge owners a concrete responsibility. A brand editor can decide whether a requested tone is a reusable convention; a product owner can decide whether a claim is true. The person who needs a draft today may have a useful preference without owning either decision.

Original concept diagram for the feedback path described in the interview. It does not represent every mechanism that can create Asana memory.

For a team introducing AI, an explicit question helps: “Change this output, or change how this kind of work is done next time?” A request can propose both. The long-term part deserves a named owner, an explanation of its scope and a later check on a different assignment.

Coaching also needs a precise meaning. In this article, it means maintaining instructions, examples and reusable working knowledge. It is not evidence that each comment retrains a foundation model. Asana states that it and its AI partners do not train AI models on customer data. AI controls and data safeguards

Asana’s April engineering explanation describes both inferred and explicit memories, linked to relevant work objects. Retrieval happens at the start of execution and as relevant objects are read. Access to a memory depends on the triggering user’s visibility into its source work. Memory architecture

These are separate questions: how a memory was formed, whether it fits this assignment and whether this person may use it. The manual feedback path above is one part of that system; it does not imply that every memory is entered by an editor.

For our fictional invitation, the durable lesson should include its context. “Use a welcoming opening for customer invitations” can be useful. “Always be enthusiastic” is likely to spread into documents where it does not belong.

Teams should therefore inspect the explanation as well as the result. Which instruction influenced this draft? Does it refer to an invitation, a release announcement or an outdated document? If a later task behaves unexpectedly, a specific source or guidance item gives the reviewer something to correct.

Memory is valuable when it carries the right experience forward. More remembered text alone gives no assurance that a future decision will be appropriate.

Imagine Harbor, a fictional product team preparing a customer invitation and a release announcement. All names, product details and sample outputs in this scenario are invented. This is a proposed evaluation, not a report of an Asana trial.

The team starts with three inputs:

The fact paragraph in the first draft might say:

Harbor 0.8 includes CSV export. We invite you to try it and share feedback. Automatic appointment booking remains planned; it is not included in this release. Source: approved release note 0.8.

A salesperson asks: “Make the invitation warmer, and remember to use a more energetic tone next time.”

There are two decisions to make. The current draft can receive a warmer opening. The proposed lasting convention goes to the communications editor, who narrows it to the kind of document it should govern.

A useful decision record could be:

Guidance v2: Customer invitations may open with a welcoming sentence. Release announcements should retain descriptive language. Product claims must come from the approved release note. Owner: communications editor. Reason: invitation tone should not change the release’s factual scope.

This record is our suggested team artifact, not a claim that Asana automatically generates these fields.

Now give the same AI teammate a second task: “Write a release announcement for Harbor 0.8.” The expected result is a restrained announcement about CSV export, with no promise of released appointment booking or unmeasured savings. The first invitation should remain warmer.

That second assignment tests whether coaching generalized to the right context. A good first revision only demonstrates that the current request was understood. It does not establish that a durable lesson was scoped correctly.

Another salesperson might suggest “Say it saves 50% of everyone’s time.” The editor should reject that as an unsupported claim. Positive feedback about writing style cannot supply missing product evidence.

A Skill packages guidance and reference material for a kind of work. Asana’s documentation says library Skills become independent copies on individual teammates; editing one copy does not update the others. Editors and admins manage those Skills. Skill behavior

That matters if Harbor creates separate invitation and announcement agents. Correcting the same brand convention on one does not demonstrate that the other has changed. Keep a short list of agents that depend on the guidance and check their copies when it changes.

Connected applications introduce a different boundary. Asana uses each triggering person’s own authorized connection. Write and delete actions require approval by default, but action settings can be changed. Connected apps and actions

For the launch team, use three distinct questions:

• May this person read the source? A private finance forecast and an approved release note have different audiences.
• May these details appear in this output? A person who can read finance information may still be drafting in a task visible to a broader marketing group.
• May this action run? Producing a draft, posting it to a task and sending an email affect different audiences and systems.

The second question is our recommended review criterion. We have not observed an Asana disclosure failure or tested its sharing safeguards. Source permission is a reason to check the destination audience, not a substitute for that check.

Before a sending step, review the intended recipients, final content and the current action setting. Removing a connection also should not be treated as proof that previously created drafts or messages have disappeared; inspect those artifacts separately.

As of October 1, Asana’s allocation document lists 5 included monthly requests per user, capped at 50 for Starter/Advanced organizations and 250 for Enterprise/Enterprise+. Dash and AI Teammates share the organization’s pool. Paid-plan inclusion is not unlimited free use. Current allocation

The cap changes a simple purchase calculation. With 20 Starter users, 20 × 5 suggests 100, but the documented organization maximum makes the included pool 50. This is an illustration of the published formula; the admin console is the authority for an account’s actual balance.

Completed work and substantive post-completion revisions can consume requests; short coaching notes and context added during active work are among the documented exceptions. Extra capacity and opt-in on-demand billing are available. Request accounting

For Harbor, track completed drafts, revisions that require another execution, accepted results and requests consumed. A completed AI task can still need human correction. Billing completion and business acceptance answer different questions.

Our commercial interpretation: including a limited pool lowers the cost of trying AI inside an existing paid workflow. Repeated useful work can encourage usage purchases beyond the subscription. Guidance that improves the first acceptable draft can benefit the customer; a large number of generated drafts can increase consumption without delivering the same benefit.

The team should measure the whole loop: briefing, review, correction, approved output and maintenance of reusable guidance. We have not measured savings in this scenario, and we are not assigning a dollar cost to a request without an account-specific price.

Start with one repeated document type, two people and a named knowledge owner. Use non-sensitive test material and confirm the account’s current feature access and settings before trying it.

Run the Harbor scenario with deliberately different assignments:

This table defines expected evidence. It does not claim those tests have already passed in Asana.

If a new result uses an obsolete rule, inspect its other sources and Skill copies before assuming memory deletion failed. If a request stalls, distinguish an access problem, missing input, approval wait and exhausted shared allowance. Those causes need different fixes.

Teams using Onevium can apply the same discipline when reviewing project memory and maintaining Skills: decide whether a change belongs to the current task, a project convention or a reusable procedure, then check a later task. This is a transferable working method; we are not asserting that Onevium implements Asana’s memory permission model.

A shared AI teammate creates a new maintenance responsibility. Someone needs to keep product facts current, decide which feedback becomes lasting guidance, and check whether that guidance reaches the right assignments. The team needs a visible way to resolve disagreement.

That work can be distributed sensibly. Sales supplies customer context. Communications owns tone. Product owns release facts. The person preparing an external action checks its destination and authorization. The AI contribution becomes one part of that coordination.

Our conclusion is that coachable AI teams become useful when expertise can travel between assignments with its scope, evidence and owner still attached. The next colleague benefits from what was learned, while retaining a way to question it.

Asana’s approach gives readers concrete criteria for evaluating an AI teammate: can we explain what influenced it, correct the relevant guidance and see whether the next assignment improves? Those questions remain useful across products, even when their interfaces, permissions and billing differ.