What this agent does
Asana inboxes accumulate. A user on a healthy team sees 60 to 120 inbox notifications a day: comments, mentions, status updates, task assignments, automation pings, due-date reminders. Less than 10% of these actually require a response. The other 90% need to either be glanced at (FYI) or archived (automation, status changes, completed-by-someone-else notifications).
The agent classifies the stream and acts on the low-stakes categories so the user only sees the items that need them. The user retains the final word: the agent posts a daily summary the user can audit, and any item can be restored from archive.
For a parallel pattern in a different surface, see AI agent for Slack triage. For email-side triage, see AI agent for inbox triage. For cluster context, see what an AI agent can actually do.
Asana access and limits
Asana exposes an HTTP REST API and a small set of webhook events. The agent uses both.
Authentication. Personal Access Tokens are the simplest option for internal use. OAuth is available for SaaS distribution. Either way, the token grants the same scopes the human user has; Asana does not provide granular API-only scopes.
Endpoints used. The Inbox endpoint (/users/me/notifications), the Webhook endpoint to subscribe to user-stream events, and the Stories endpoint to fetch comment text on demand. The agent does not read full project lists, full task lists, or any data outside the notification stream.
Rate limits. Asana publishes a rate limit of approximately 1,500 requests per minute per token for free-tier orgs and higher for paid tiers. A triage agent runs well under this; the design uses webhook delivery for new notifications and on-demand fetch for story content, so the agent never polls.
Five-bucket taxonomy
Closed label set. The classifier never invents a new bucket.
- Needs response. Direct @-mention, or the user is the assignee and the comment ends in a question mark, or the user has configured a project-specific "manual escalation" rule. Stays in the inbox until the user dismisses it.
- FYI. Comment on a task the user follows but is not assigned to. Collapses into the daily digest.
- Low-signal. Routine status changes ("marked complete," "moved to done"). Collapses into the digest count without enumeration.
- Automation. Notifications generated by Asana Rules, Zapier, or other integrations. Archived directly after digest count.
- Status update. Project-level status posts. Stay in the inbox for 24 hours, then collapse.
The user can re-classify any item from the digest. Re-classifications feed the user-specific model, so the agent gradually learns this user's particular threshold for "needs response."
The daily digest
Once a day at the user's configured time (default 17:00 user-local), the agent posts a single digest in a private location: a Notion page, a Slack DM with the agent's bot user, or an email to the user's own inbox, depending on configuration.
The digest has four sections:
- Still needs response. Open items in the "needs response" bucket from prior days. The agent never closes these; it only reminds.
- FYI worth noting. Up to 10 items the classifier scored just below the "needs response" threshold. The user can pull any of them up to the inbox if the classifier was wrong.
- Counts by project. "Project Alpha: 12 status updates, 4 automation pings, 6 FYIs." Hyperlinks to the project's inbox view.
- Drift signals. If a project has more than 50 notifications in a day, or if the user has not touched a "needs response" item in over 72 hours, the digest surfaces it.
The digest is short. One screen. Most days, the user reads it in 30 seconds and the inbox is already at zero.
Shadow mode for two weeks
The agent does not auto-archive on day one. For two weeks it labels each notification in a private metadata field but leaves the inbox state alone. The user proceeds as normal and the agent records every dismissal, every archive, and every reply.
At the end of week one and week two, the agent produces a calibration report: per-bucket agreement, false-positive rate (items the agent would have archived that the user replied to), false-negative rate (items the agent would have kept in inbox that the user immediately archived).
Graduation rule: an agent reaches auto-archive on the automation bucket when its false-positive rate is below 1% for that bucket across two weeks. The other buckets graduate similarly, lowest-stakes first.
Guardrails
Five guardrails are non-negotiable for an inbox-zero agent.
- Never modify tasks. No comments, no status changes, no assignments. The agent's permission is metadata-only on notifications.
- Restore window. Every auto-archived notification stays restorable for 30 days. Restoration is a one-click action from the digest.
- Mention is sacred. Any notification containing the user's at-mention is never archived, never digested, never modified. It stays in the inbox until the user touches it.
- Daily digest is the only push. The agent does not Slack the user, does not email the user mid-day, does not generate any other surface. One push per day.
- VIP override. A configurable list of users (manager, key partner, CEO) whose comments are always "needs response" regardless of other signals. The user controls this list.
Common mistakes
Letting the agent comment in tasks. A bot comment in an Asana task is a small permanent piece of clutter that other people see and react to. Restrict the agent to metadata only.
One taxonomy for everyone. "Needs response" for an engineering manager is not the same as for a designer. The classifier should support per-user thresholds and per-user VIP lists, not a single org-wide rule.
Archiving without restore. An agent that archives notifications irreversibly will eventually mis-classify something that mattered. The 30-day restore window is the safety net that makes the agent trustworthy enough to use.
Confusing inbox with my-tasks. Inbox is the notification stream. My Tasks is the assignment list. They have different APIs, different semantics, and different agents. Do not run inbox triage logic on My Tasks.
Surface fragmentation. Posting digests to Slack, email, and Notion simultaneously creates the fragmentation the agent was supposed to fix. Pick one surface per user.
Frequently asked questions
What does an Asana inbox zero agent actually do?
It polls the Asana Inbox notification stream, classifies each notification into one of five buckets (needs response, FYI, low-signal, automation, status update), and routes them. Needs-response items stay in the inbox. FYI and status updates collapse into a daily digest. Low-signal automation pings are archived. The agent never modifies the underlying task.
Which Asana API capabilities does the agent need?
A Personal Access Token from the user, plus read access to the inbox endpoint and write access only to dismiss notifications. Asana's API does not expose granular per-resource scopes the way Slack does, so the agent runs with the user's full permission set and the operator must trust the agent not to write to tasks. The agent is configured to refuse non-dismiss writes at the application layer.
How does the agent decide what counts as 'needs response'?
A notification needs response when at least one of three conditions holds: the user is explicitly mentioned with an at-sign, the user is the task assignee and the comment ends with a question mark, or the user is on a project where they have configured 'manual escalation' for that project. Everything else is FYI. The thresholds are configurable per user.
Does the agent auto-respond to comments?
No. The agent only triages. Auto-responding in Asana threads creates social-noise problems much faster than it creates wins. Drafting a suggested reply for the user to send in a side panel is acceptable; sending it as the user is not.
How long does the agent run before being trusted to archive?
Two weeks of shadow operation. During this period the agent labels notifications but does not archive anything. The user reviews and confirms a sample of 30 daily classifications. When agreement is above 90% for two consecutive weeks, the agent graduates to auto-archive for the lowest-confidence-required category (automation pings) and adds categories as agreement allows.
Three takeaways before you close this tab
- Triage, never modify. The task is sacred. The notification is metadata.
- One push per day. The digest is the only proactive surface.
- Restore is the trust contract. 30 days, one click, undoable.
Sources
- Asana Developers, "API reference and authentication", retrieved 2026-05-11, developers.asana.com/docs/quick-start
- Asana Developers, "Webhooks and event stream", retrieved 2026-05-11, developers.asana.com/docs/webhooks
- Asana Developers, "Rate limits", retrieved 2026-05-11, developers.asana.com/docs/rate-limits
- NIST, "SP 800-53 AC-6 Least Privilege", retrieved 2026-05-11, csrc.nist.gov/sp800-53/AC-6
- Aryan Agarwal, "Gravity Asana-agent guardrails", internal v1, May 2026, About
Related agent patterns
The same shape, applied to other tools and surfaces:
- AI agent for Slack triage, the chat-platform analogue of inbox triage.
- AI agent for inbox triage, the email parallel to this workflow.
- AI agent for Linear sprint summary, summarising the work the notifications describe.
- AI agent for Notion daily rollup, daily-cadence parallel for workspace activity.
- AI agent safety and guardrails, the principles every triage agent respects.
- AI agent tool use explained, how an agent gets connected to a task-management API.
- How we test AI agents with 80 tests per capability, the calibration methodology.