Asana no sabe que hay un contenedor atascado en aduanas.

Sí. El mismo componente de Tareas se renderiza en tres portales: operador (visibilidad total), cliente (el comprador, que ve las tareas creadas para él, como «Aprobar muestra» o «Confirmar envío dividido») y proveedor (el fabricante, que ve las tareas creadas para él, como «Presentar informe de SGS» o «Acusar recibo del calendario de inspección»). Cada portal usa el mismo modelo de datos con un prefijo de API distinto (operador: /api/tasks · cliente: /api/portal/client/tasks · proveedor: /api/portal/supplier/tasks) y una lista blanca de tipos de entidad acotada. El operador crea una tarea, la asigna a un contacto del proveedor, y aparece en la lista de tareas del portal del proveedor: mismo enum de estado, misma prioridad, mismo flujo de actividad. El proveedor la marca como completada; el operador ve la finalización en tiempo real.

Las aprobaciones son tareas. En concreto, una tarea con estado pending_approval, uno de los seis estados nativos. Cuando un operador o una contraparte presenta un entregable que necesita visto bueno (una corrección de contrato, una evaluación de muestra, un sobrecoste de presupuesto, una versión de documento), el trabajo pasa a pending_approval y aparece en la lista de tareas del aprobador junto con todo lo demás sobre lo que tiene que actuar. Aprobar, rechazar y «necesita cambios» son transiciones de estado de la tarea. El rastro de auditoría de quién aprobó qué, cuándo y por qué vive en el flujo de actividad de la tarea. Deliberadamente no construimos un motor de aprobaciones aparte; integrarlo en Tareas significa una sola bandeja, un solo flujo de trabajo, un solo sitio donde mirar.

Sí: esa es la parte de sistema nervioso de la arquitectura. Los eventos de otras secciones (cambio de estado de pedido, CC de producción completado, retraso de envío, factura vencida, muestra evaluada, reclamación presentada, documento subido, mensaje señalado con una acción) emiten todos a través del motor de Tareas. La plataforma decide si el evento necesita atención humana según reglas configurables por categoría, y cuando es así, se crea una tarea con el enlace de entidad heredado, la categoría preestablecida y un responsable sugerido extraído del historial de la parte responsable. Las tareas son la forma en que la plataforma habla con los humanos sobre el trabajo que hay que hacer, y cómo rastrea si el trabajo se hizo.

La principal superficie de acción de Atlas ES la creación de tareas. Cuando Atlas detecta algo que necesita juicio humano —un margen que cae por debajo del umbral, una contraparte que se queda en silencio en un hilo, un documento que caduca, un patrón recurrente entre pedidos—, crea una tarea con los datos relevantes ya adjuntos. Un mensaje de chat hace una pregunta y se desplaza y desaparece. Una tarea lleva el contexto, el responsable, la fecha de vencimiento y el rastro de auditoría de si el operador actuó sobre ella. Eso hace que la señal de Atlas sea medible: ¿se cerró la tarea a tiempo? ¿Se cerró siquiera? Que Atlas cree tareas (en lugar de solo publicar mensajes) es como mantenemos a la IA responsable del trabajo que saca a la luz.