AI Workers deckt den vollständigen Lebenszyklus einer synthetischen Belegschaft ab. Administratoren definieren Worker-Identitäten, jede mit einer Anzeigepersona, einer Rolle, einem System-Prompt, der Tonalität und Fachwissen prägt, sowie Generierungsparametern wie Token-Budget und Temperatur. Jeder Worker verfügt über eine Arbeitswarteschlange, einen dauerhaften Gesprächsfaden und eine Reihe verbundener Assistenten, über die er erreicht werden kann oder über die er selbst nach außen tritt. Worker fragen betriebliche Live-Daten ab, führen Schreibvorgänge und Statusänderungen durch, erledigen geplante Aufgaben unbeaufsichtigt, überwachen auf Ausnahmen, extrahieren strukturierte Informationen aus Dokumenten und agieren als Prüfer und Genehmiger innerhalb von Geschäftsprozessen.

Hinter jedem Worker liegen zwei Antwortpfade, die automatisch gewählt werden. Ist ein externer Assistent verbunden und erreichbar, leitet die Plattform die Anfrage an ihn weiter und erhält die Antwort über einen signierten, authentifizierten Callback. Steht kein externer Assistent zur Verfügung, arbeitet ein integriertes Modell direkt gegen denselben geregelten Werkzeugsatz, sodass ein Worker niemals stumm bleibt und niemals aus veraltetem Kontext antwortet. Beide Pfade greifen auf eine gemeinsame Registry von Unternehmenswerkzeugen zurück, was garantiert, dass sich ein Worker identisch verhält, gleich ob ein externer Assistent oder das integrierte Modell das Denken übernimmt. Gespräch, Warteschlangenverwaltung, Worker-Konfiguration, Einstellungen der Modellanbieter und die Registrierung verbundener Assistenten werden allesamt über eine einzige KI-Verwaltungsoberfläche gesteuert.

Im Zentrum steht der AI Worker: eine dauerhafte Identität mit einem Namen, einer Rolle und einer Erinnerung an alles, worum er gebeten wurde. Ein Worker wird weniger durch Code definiert als durch drei ihn umgebende Dinge. Das erste ist eine Rolle, welche die Berechtigungen des Workers trägt und die alleinige Instanz dafür ist, was er sehen und tun darf; ein Worker kann die von seiner Rolle beschriebene Grenze niemals überschreiten, und eine Änderung dieser Rolle verändert seine Reichweite unmittelbar. Das zweite ist die Arbeitswarteschlange, ein geordneter Rückstand von Aufgaben, die dem Worker gehören, jede mit einer Priorität, einem optionalen Zeitplan, einem Lebenszyklus von in Warteschlange über in Bearbeitung bis zu einem abgeschlossenen Ergebnis und einem festgehaltenen Resultat. Das dritte ist das Gespräch, eine nur ergänzbare Aufzeichnung von Nutzer-, Worker- und Systembeiträgen, die jedem Austausch Kontinuität und eine vollständige Prüfspur verleiht.

Um diese herum liegen zwei unterstützende Konzepte. Ein Modellanbieter beschreibt, welche Denk-Engine einen Worker antreibt, aufgelöst im Moment der Nutzung, sodass ein einzelner Worker den Standard der Organisation übersteuern kann, ohne dass sich am Worker selbst etwas ändert. Verbundene Assistenten beschreiben die externen Werkzeuge, an die ein Worker weitergeleitet werden kann, jedes mit eigenem Endpunkt, eigenen Zugangsdaten und eigenem Zustand. Die Beziehungen sind bewusst einfach: Eine Rolle prägt viele Worker, ein Worker besitzt eine Warteschlange und ein Gespräch und kann mehrere verbundene Assistenten halten, und ein Anbieter kann viele Worker antreiben. Nichts hiervon gehört einem Kunden oder einem Hauptbuch; dies ist Konfiguration und Persona, verankert im Kern der Plattform, damit Identität und Berechtigung an einer einzigen Stelle geregelt werden.

Die alltägliche Interaktion ist dialogorientiert. Ein Nutzer öffnet das Worker-Panel, wählt einen Worker nach Name und Rolle aus und tippt eine Anfrage. Die Nachricht wird augenblicklich erfasst und bestätigt und anschließend weitergeleitet, ohne die Oberfläche zu blockieren. Antwortet ein verbundener Assistent, trifft seine Antwort über den Callback ein und ersetzt die Wartekennung; tut dies keiner, verfasst das integrierte Modell die Antwort direkt, ruft dabei alle geregelten Werkzeuge auf, die die Anfrage erfordert, und liefert fundierten, datengestützten Text zurück. Das Panel hält sich durch adaptives Polling aktuell, das sich bei aktivem Austausch beschleunigt und entspannt, wenn der Faden ruhig ist.

Der zweite Ablauf ist autonom. Ein Nutzer plant eine Arbeit, und das Element reiht sich in die Warteschlange des Workers ein, mit einer Priorität und, sofern gesetzt, einem künftigen Ausführungszeitpunkt. Der Scheduler nimmt Elemente aus der Warteschlange auf, führt sie durch das Modell gegen den Live-Werkzeugsatz mit einer begrenzten Anzahl von Denkschritten aus und hält das Ergebnis fest. Eine sauber abgeschlossene Aufgabe wird als solche gekennzeichnet; eine, bei der jede Aktion erfolgreich war, einige jedoch abgelehnt wurden oder fehlschlugen, wird ehrlich als Teilergebnis mit einem klaren Hinweis zur menschlichen Prüfung ausgewiesen; eine, die vollständig scheitert, wird als fehlgeschlagen erfasst. Der dritte Ablauf ist eingehend: Externe Assistenten verbinden sich mit dem plattformeigenen Protokoll-Endpunkt und bedienen dieselben geregelten Werkzeuge unter Durchsetzung des Berechtigungsumfangs, sodass die Fähigkeiten eines Workers auch innerhalb der Werkzeuge verfügbar sind, die Menschen anderswo bereits nutzen.

Was das Modul vertrauenswürdig macht, ist der Umstand, dass Fähigkeit und Befugnis niemals voneinander getrennt sind. Berechtigungen werden im Moment der Werkzeugausführung durchgesetzt, nicht bloß beim Einreihen einer Aufgabe, sodass ein Rollenwechsel oder eine Worker-Sperrung bereits bei der nächsten Aktion greift. Jedes Werkzeug deklariert einen Berechtigungsumfang, und dieser Umfang bildet auf ein konkretes Berechtigungspaar ab, das gegen die Rolle des Workers geprüft wird, bevor das Werkzeug überhaupt tätig wird; ein Worker, dem das Recht fehlt, liefert ein sauberes Ergebnis mit Zugriffsverweigerung, anstatt zu handeln. Können die Berechtigungen eines Workers aus irgendeinem Grund nicht geladen werden, löst das System zu Alles-verweigern auf und schlägt konstruktionsbedingt sicher fehl.

Die Sicherheitsarchitektur ist entsprechend geschichtet. Interaktiver Zugriff läuft unter authentifizierten Sitzungen mit Berechtigungsprüfungen auf jeder Route. Ausgehende Weiterleitungen an externe Assistenten werden mit einem schlüsselbasierten Message Authentication Code signiert, damit Empfänger den Ursprung verifizieren können, und jede Weiterleitung trägt den Worker-Kontext, einen begrenzten Ausschnitt des Gesprächsverlaufs und eine einmalig verwendbare Callback-Adresse. Eingehende Callbacks authentifizieren sich mit einem Bearer-Token, das gegen einen gespeicherten Hash geprüft wird, sind pro Worker ratenbegrenzt, größenbegrenzt und idempotent, sodass eine erneut zugestellte Übermittlung niemals eine Antwort dupliziert. Veraltete Austausche verfallen über einen Timer, nicht erreichbare Assistenten werden zustandsüberwacht und automatisch stillgelegt, und jede Nachrichtenerstellung wird mit der handelnden Identität und der Ursprungsadresse protokolliert. Das Ergebnis ist Autonomie mit Papierspur: Worker handeln schnell, aber stets innerhalb einer Grenze, die sich im Nachhinein prüfen lässt.

AI Workers ist das Bindegewebe von Nashua 360, keine Insel. Über die gemeinsame Werkzeug-Registry greift ein Worker direkt in Business Relations, um Unternehmen, Kontakte und Standorte zu lesen und zu pflegen; in Accounting and Control, um Debitoren- und Kreditorenrechnungen sowie das weitere Finanzbild abzufragen; in Catalog Management, um den mehrschichtigen Produkt- und Dienstleistungskatalog zu durchsuchen; und in Test Management sowie das zentrale Modul System für Plattformmetadaten und Diagnosen. Jeder dieser Zugriffe ist durch dieselbe Zuordnung von Rolle zu Berechtigungsumfang abgesichert, sodass ein für die Finanzen gebauter Worker das Hauptbuch sieht, aber nicht den Katalog, sofern seine Rolle nichts anderes bestimmt.

Da das Modul im Plattformkern neben Rollen und Modulregistrierung liegt, erbt es das Identitäts- und Berechtigungsmodell der Suite vollständig, anstatt es neu zu erfinden. Die Rolle eines Workers wird in derselben Berechtigungsgrammatik ausgedrückt wie die eines menschlichen Nutzers, was bedeutet, dass Governance, Prüfung und Least-Privilege-Design eine einzige Disziplin über Menschen und synthetische Worker hinweg sind. Neue Funktionalität, die einem beliebigen Modul hinzugefügt wird, steht Workern in dem Moment zur Verfügung, in dem ihr Werkzeug registriert wird, sodass die dialogorientierte und autonome Oberfläche im Gleichschritt mit dem übrigen Nashua 360 wächst, ohne maßgeschneiderte Integrationsarbeit.

Innerhalb des Moduls sind die Worker die Handelnden, und ihr Spektrum ist breit. Sie beantworten Fragen, indem sie Live-Moduldaten abfragen und fundierte Zusammenfassungen zurückgeben, sodass ein Nutzer nach einem offenen Kreditorensaldo oder der jüngsten Aktivität eines Kunden fragen und eine Antwort erhalten kann, die aus dem aktuellen Zustand des Hauptbuchs und den Beziehungsdatensätzen gewonnen wird, statt aus einem gespeicherten Bericht. Sie führen Aktionen auf Anfrage oder nach Zeitplan aus, legen Datensätze an und aktualisieren sie, erzeugen Arbeitselemente und treiben mehrstufige Prozesse durch eine begrenzte Denkschleife voran. Sie überwachen auf Anomalien und Ausnahmen, und wenn eine geplante Aufgabe mit abgelehnten oder fehlgeschlagenen Aktionen endet, lösen sie eine Warnbenachrichtigung und eine klare Systemmeldung aus, anstatt ein Teilergebnis stillschweigend durchgehen zu lassen.

Sie verarbeiten Dokumente und unstrukturierte Eingaben, extrahieren strukturierte Felder für die nachgelagerte Nutzung, und sie unterstützen Entscheidungen, indem sie die einer Wahl zugrunde liegenden Daten zusammenstellen und erläutern. Entscheidend ist, dass ein Worker als Genehmigungs- oder Prüfungsknoten innerhalb eines Workflows fungieren kann: Wird ihm eine Anfrage unter seiner eigenen berechtigten Identität zugeleitet, bewertet er das Element anhand seiner Rolle und Anweisungen, hält seine Entscheidung in der Gesprächsspur fest und treibt den Prozess entweder voran oder gibt ihn zur menschlichen Aufmerksamkeit zurück. Da alles, was ein Worker tut, durch dieselben geregelten Werkzeuge, dieselben Berechtigungsprüfungen und dieselbe Audit-Protokollierung läuft wie jeder andere Handelnde in der Suite, ist ein AI Worker ein echter Kollege im Prozess, rechenschaftspflichtig und begrenzt, keine undurchsichtige Automatisierung, die abseits davon läuft.