Asana, reviewed for teams running agents alongside it

Asana is a work management tool, which in practice means it is a place where humans agree on what is happening. That is a genuinely useful thing and it is a different thing from a system of record.

The distinction matters here because it decides whether automation around Asana produces value or produces a second place to look. This review is about that decision rather than about the feature list.

What it is good at

Making work visible without imposing a process. Asana’s flexibility is its main strength: a marketing team, an onboarding process and a product backlog can all live in it, structured differently, without anyone building anything.

Getting adoption. It is pleasant to use and low-friction, which sounds soft and is the single biggest predictor of whether a work-tracking tool survives its first quarter.

Coordinating handovers between people. A task with an owner and a date is a small contract, and Asana is good at making that contract visible to everyone who cares about it.

What it is not good at

Being a source of truth an agent can rely on. The same flexibility that drives adoption means fields are optional, naming is inconsistent, and the same concept appears as a task in one project and a subtask in another.

A person reads around inconsistent fields without noticing. An agent cannot.

Enforcing structure. You can add custom fields and rules; you cannot easily make the organisation use them the same way twice. Every automation you build against a loosely structured board is a guess that ages.

This is not a criticism of the product. It is what a work management tool is, as opposed to a database with a schema someone owns.

Where an agent actually adds value

Getting things in. The highest-value automation around Asana is almost always creation, not analysis: an inbound request, a form submission, a signed contract, a support escalation, arriving as a properly titled task in the right project with the right fields already filled and the right owner assigned.

That works because it is the one moment where structure can be imposed at no cost to anyone. Nobody has to change how they work; the task simply arrives correct.

Summarising across projects. A weekly digest of what moved, what did not and what is overdue: read-only, generated, delivered where people already are. Useful precisely because it does not require the underlying data to be perfect.

Where it adds a second place to look

Status updates written into Asana that nobody reads there. If the team lives in chat, a generated status comment inside a task is a message posted into a room with nobody in it.

Agents that make decisions from Asana data. Prioritisation, forecasting, capacity planning, all tempting, all built on fields that are optional and inconsistently used. The output is confident and wrong, which is the worst failure mode an agent has: it does not break, it just quietly stops being right.

Anything that duplicates the CRM. If customer work is tracked in Asana and the customer record lives in the CRM, an agent syncing between them is maintaining a copy. Copies diverge. Decide which one is authoritative and let the other be a view.

What to verify

Which fields are actually mandatory, technically rather than by convention. If the answer is “none”, any automation reading those fields has to treat empty as normal rather than as an error.

Rate limits and whether an integration consumes a seat. The same two questions as any SaaS platform, and the same two surprises in week two.

Hosting region and sub-processors in the DPA. Asana is a US company; where data rests and where it is processed are separate questions with separate answers, and conflating them is the standard mistake.

Whether personal data ends up in task titles. It usually does, customer names, sometimes more. That makes Asana part of your processing landscape and puts it in the Article 30 record, which is the sort of thing discovered during an audit rather than before one.

Who it fits

Fits: teams that need coordination visible across functions and are willing to let structure be loose. Automate the way in, generate the summaries, leave the judgement to people.

Does not fit as a system of record. If a process needs a schema someone owns (quotes, contracts, tickets, deals) that belongs in a system built for it, with Asana as the place people talk about the work rather than the place the work is defined.

Automate into Asana freely, automate out of it carefully. Writing structured data in is safe. Making decisions from what is in there is only as good as the daily discipline of forty people, and that is not a foundation an agent should stand on.

Frequently asked questions