Asana weiß nicht, dass ein Container im Zoll feststeckt.

Ja. Dieselbe Aufgaben-Komponente wird in drei Portalen gerendert: Operator (volle Sichtbarkeit), Kunde (der Käufer — sieht die für ihn erstellten Aufgaben, z. B. „Muster genehmigen” oder „Geteilte Sendung bestätigen”) und Lieferant (der Hersteller — sieht die für ihn erstellten Aufgaben, z. B. „SGS-Bericht einreichen” oder „Inspektionsplan bestätigen”). Jedes Portal verwendet dasselbe Datenmodell mit einem unterschiedlichen API-Präfix (Operator: /api/tasks · Kunde: /api/portal/client/tasks · Lieferant: /api/portal/supplier/tasks) und einer eingegrenzten Entitätstyp-Whitelist. Der Operator erstellt eine Aufgabe, weist sie einem Lieferantenkontakt zu, und sie erscheint in der Aufgabenliste des Lieferantenportals — gleicher Status-Enum, gleiche Priorität, gleicher Aktivitätsstrom. Der Lieferant markiert sie als abgeschlossen; der Operator sieht die Erledigung in Echtzeit.

Genehmigungen sind Aufgaben. Konkret: eine Aufgabe mit dem Status pending_approval — einem der sechs nativen Status. Wenn ein Operator oder eine Gegenpartei ein Ergebnis zur Freigabe einreicht (ein überarbeiteter Vertrag, eine Musterbewertung, eine Budgetüberschreitung, eine Dokumentversion), wechselt der Vorgang zu pending_approval und erscheint in der Aufgabenliste des Genehmigenden zusammen mit allem anderen, das Handlung erfordert. Genehmigung, Ablehnung und „Änderungen erforderlich” sind Statusübergänge der Aufgabe. Das Prüfprotokoll — wer was wann und warum genehmigt hat — liegt im Aktivitätsstrom der Aufgabe. Wir haben bewusst keine separate Genehmigungsmaschine gebaut; die Integration in Aufgaben bedeutet einen Posteingang, einen Workflow, eine Anlaufstelle.

Ja — das ist der Nervensystem-Teil der Architektur. Ereignisse in anderen Bereichen (Auftragsstatusänderung, Produktions-QC abgeschlossen, Sendungsverzögerung, überfällige Rechnung, Muster bewertet, Reklamation eingereicht, Dokument hochgeladen, Nachricht mit einem Aktionspunkt markiert) werden alle über die Aufgaben-Engine ausgegeben. Die Plattform entscheidet anhand konfigurierbarer Regeln je Kategorie, ob ein Ereignis menschliche Aufmerksamkeit erfordert — und wenn ja, wird eine Aufgabe mit dem übernommenen Entitätslink, der voreingestellten Kategorie und einem vorgeschlagenen Beauftragten aus dem Verantwortlichen-Verlauf erstellt. Aufgaben sind die Art, wie die Plattform mit Menschen über zu erledigende Arbeit kommuniziert — und wie sie verfolgt, ob die Arbeit erledigt wurde.

Die wichtigste Aktionsoberfläche von Atlas IST die Aufgabenerstellung. Wenn Atlas etwas erkennt, das menschliches Urteilsvermögen erfordert — eine Marge, die unter einen Schwellenwert sinkt, eine Gegenpartei, die in einem Thread verstummt, ein ablaufendes Dokument, ein wiederkehrendes Muster über Aufträge hinweg — erstellt es eine Aufgabe mit den bereits beigefügten relevanten Daten. Eine Chat-Nachricht stellt eine Frage und scrollt vorbei. Eine Aufgabe trägt den Kontext, den Beauftragten, das Fälligkeitsdatum und das Prüfprotokoll, ob der Operator gehandelt hat. Das macht das Signal von Atlas messbar: Wurde die Aufgabe rechtzeitig geschlossen? Wurde sie überhaupt geschlossen? Dass Atlas Aufgaben erstellt (anstatt nur Nachrichten zu senden) ist die Art, wie wir KI für die Arbeit, die sie aufzeigt, verantwortlich halten.