Asana doesn't know there's a container stuck in customs.

Yes. The same Tasks component renders in three portals: operator (full visibility), client (the buyer — sees tasks created for them, like "Approve sample" or "Confirm split shipment"), and supplier (the manufacturer — sees tasks created for them, like "Submit SGS report" or "Acknowledge inspection schedule"). Each portal uses the same data model with a different API prefix (operator: /api/tasks · client: /api/portal/client/tasks · supplier: /api/portal/supplier/tasks) and a scoped entity-type whitelist. The operator creates a task, assigns it to a supplier contact, and it appears in the supplier portal's task list — same status enum, same priority, same activity stream. The supplier marks it complete; the operator sees the completion in real time.

Approvals are tasks. Specifically, a task with status pending_approval — one of the six native statuses. When an operator or counterparty submits a deliverable that needs sign-off (a contract redline, a sample evaluation, a budget overrun, a document version), the work moves to pending_approval and surfaces in the approver's task list with everything else they need to act on. Approval, rejection, and "needs changes" are status transitions on the task. The audit trail of who approved what, when, and why lives in the task's activity stream. We deliberately didn't build a separate approvals engine; rolling it into Tasks means one inbox, one workflow, one place to look.

Yes — that's the nervous-system part of the architecture. Events in other sections (order status change, production QC complete, shipment delay, invoice overdue, sample evaluated, claim filed, document uploaded, message flagged with an action item) all emit through the Tasks engine. The platform decides whether the event needs human attention based on configurable rules per category, and when it does, a task is created with the entity link inherited, the category preset, and a suggested assignee pulled from the responsible-party history. Tasks are how the platform talks to humans about work that needs doing — and how it tracks whether the work got done.

Atlas's main action surface IS task creation. When Atlas detects something needing human judgment — a margin slipping below threshold, a counterparty going quiet on a thread, a document expiring, a recurring pattern across orders — it creates a task with the relevant data already attached. A chat message asks a question and scrolls away. A task carries the context, the assignee, the due date, and the audit trail of whether the operator acted on it. That makes Atlas's signal measurable: did the task close on time? Did it close at all? Atlas creating tasks (rather than just posting messages) is how we keep AI accountable for the work it surfaces.