KI-Agenten im Projektmanagement 2026: Der große Vergleich

„KI-Agent" ist 2026 eines der meistgenutzten und missverständlichsten Wörter im Projektmanagement. Viele Tools verwenden das Label inzwischen sehr breit, von Kanban-Erweiterungen bis zu Meeting-Notizen-Bots. Vergleichsartikel bleiben oft bei der Feature-Liste stehen: Chat, Skills, Browser-Steuerung, Integrationen. Für eine echte Entscheidung reicht das nicht.

TensorPM, OpenClaw und der Hermes Agent von Nous Research stehen für unterschiedliche Agenten-Paradigmen. Entscheidend ist nicht, welche Features sie anbieten, sondern worauf sie optimieren:

OpenClaw und Hermes fragen: „Wie erledige ich diese Aufgabe?" TensorPM fragt: „Welche Aufgabe bringt das Projekt voran, ohne Termin, Budget oder Scope zu gefährden?"

Kurz: Task Completion vs. Project Intent. Wer entlang dieser Achse entscheidet, vergleicht keine Feature-Listen mehr, sondern wählt nach dem, was tatsächlich getan werden soll. Ob die Aufgabe am Ende von einem Menschen oder einem Agenten erledigt wird, ist bei TensorPM zweitrangig. Hauptsache, sie passt zum Projektziel.

Nicht verwechseln, HERMES: Wer im DACH-Raum „Hermes Projektmanagement" sucht, meint häufig die Schweizer HERMES-Methode (eCH-0054) der Bundesverwaltung. Das ist eine etablierte PM-Methodik mit Szenarien, Rollen und Zertifizierung, keine Software und kein KI-Agent. In diesem Artikel geht es ausschließlich um den Hermes Agent von Nous Research.

Aufgabenerledigung oder Projektsteuerung?

Kurz gesagt: OpenClaw und Hermes sind Aufgaben-Agenten. Sie optimieren, wie eine einzelne Aufgabe erledigt wird. TensorPM ist ein Projektsteuerungs-Agent. Er entscheidet, welche Aufgabe das Projekt voranbringt und ob sie in Termin, Budget und Scope bleibt. Der Unterschied ist der Zweck, nicht die Funktionsliste.

Alle drei Werkzeuge bieten ein Chat-Interface als Standard-Oberfläche. Alle drei können Aufgaben ausführen: Webseiten lesen, Skills ausführen, Dateien anlegen, externe APIs ansprechen. Der Vergleich wird erst belastbar, wenn man nach dem Zweck des Agenten fragt:

Frage	OpenClaw / Hermes Agent	TensorPM
Leitfrage	„Wie erledige ich diese Aufgabe?"	„Welche Aufgabe bringt das Projekt voran?"
Erfolgsmaß	Task abgeschlossen, Workflow lief	Projekt bleibt innerhalb von Termin, Budget und Scope
Wer erledigt?	Der Agent	Mensch oder Agent, zweitrangig: Hauptsache projektrichtig erledigt
Kontext	Hilft bei der Ausführung	Trägt die Projektintention
Memory	Was hat funktioniert, was ist bekannt?	Warum machen wir das Projekt, wo stehen wir, was folgt daraus?
Agentenrolle	Operativer Assistent	Projektsteuernder Agent
Projektgraph	Nicht zentral	Mittel zur dauerhaften Intentionshaltung, nicht Selbstzweck

TensorPM unterscheidet sich nicht einfach durch mehr Kontext. Kontext und Projektgraph sind Mittel. Der Unterschied liegt in der Zielrichtung. OpenClaw und Hermes können Aufgaben in einem Projekt erledigen. TensorPM versucht zu entscheiden, welche Aufgaben überhaupt projektlogisch relevant sind, wer betroffen ist, welche Entscheidung daraus folgt und ob das Projekt damit näher ans Ziel kommt.

Ein Beispiel: Drei Mails kommen rein. Eine ist ein Newsletter, eine ist ein Nachtrag des Bauherrn zum Stahlbeton-Pauschalpreis, eine ist eine Werbeanfrage. Ein Aufgaben-Agent bearbeitet alle drei nach derselben Logik: extrahieren, ablegen, vielleicht eine Aufgabe daraus machen. Ein Projektsteuerungs-Agent fragt zuerst, welche dieser Nachrichten die Projektintention verändert. Newsletter und Werbeanfrage fallen raus. Der Nachtrag wird zur Entscheidungsvorlage mit Verweis auf das betroffene Gewerk, die Budgetposition und die Frist, plus einer abgeleiteten Aufgabe, die je nach Inhalt beim Projektsteuerer, beim Architekten, beim Subunternehmer oder beim Agenten selbst landet. Die Aktion folgt nicht der technischen Möglichkeit, sondern der Projektlogik. Wer sie ausführt, hängt davon ab, wer es am besten kann.

Die feste Rolle des Agenten

Aus dieser Zielrichtung folgt die feste Rolle des TensorPM-Agenten. Er soll nicht möglichst viele Aufgaben selbst erledigen, sondern das Projekt zum Erfolg bringen. Manche Aufgaben übernimmt er selbst: Recherche, Distillation, Vorbereitung, Skill-Ausführung. Andere weist er Menschen zu. Die Trennlinie zwischen Mensch und Agent ist pragmatisch: Wer es besser, schneller oder verantwortbarer kann, macht es. Das Erfolgsmaß bleibt Termin, Budget und Scope.

TensorPM: Projektsteuerungs-Agent mit dem Projekt als Intentionsträger

TensorPM ist ein Projektsteuerungs-Agent. Der Projektgraph ist sein Gedächtnis, aber nicht sein Zweck. Der Zweck ist, eine Projektintention über Wochen, Monate und mehrere Stakeholder hinweg stabil zu halten und daraus Arbeit, Entscheidungen, Risiken und Kommunikation zu steuern.

Im Zentrum steht ein lokal-first gespeicherter Projektgraph mit Zielen, Anforderungen, Erfolgskriterien, Risiken, Meilensteinen, Entscheidungen, Verantwortlichen, Budgets, Action Items und Audit-Trail. Diese Struktur ist mehr als eine Datenbank. Sie hält Ziele, Entscheidungen und Risiken so zusammen, dass der Agent die Projektintention über Zeit verfolgen kann.

Der TensorPM-Agent kann ausführen (Web-Suche, Browser-Sessions, abgeschottete Skills, Mail-Konnektoren, Code-Assistenz), tut das aber immer aus Projektsicht. Eine Recherche im Web ist nie nur „finde mir X", sondern „finde mir X im Kontext dieses Projekts, mit diesen Zielen, diesen Erfolgskriterien". Skill-Artefakte landen im Projektordner. Jede Agentenaktion wird im Trail des Projekts protokolliert.

Die Oberflächen sind drei:

Erstens eine Desktop-App für Menschen mit klassischer PM-UI: Listen, Kanban-Board, Gantt-Timeline, wiederkehrende Aufgaben, Abhängigkeiten, Budget, Files mit AI-Zusammenfassungen, plus ein Chat-Interface zum eingebauten Agenten. Der Chat ist Standard, wie überall sonst auch. Der Unterschied: Jede Konversation ist in den Projektgraphen eingebettet.

Zweitens eine offene Agentenschnittstelle über MCP und A2A. Externe Agenten wie Claude Code, Codex, OpenClaw oder Hermes dürfen denselben Projektgraphen lesen und schreiben, statt sich den Kontext bei jeder Session neu erklären zu lassen. TensorPM liefert damit den Projektkontext, auf den andere Agenten zugreifen können, und tritt nicht in Konkurrenz zu ihnen.

Drittens ein Messenger-Channel über Telegram (WhatsApp wird aktuell nicht unterstützt) mit klaren Rollen und Sichtbarkeiten pro Teilnehmer. Bauherr, Architekt, Subunternehmer, Projektsteuerer: alle, die Zugriff auf den Channel haben, dürfen unterschiedliche Teile des Projektgraphen sehen und unterschiedliche Aktionen auslösen. Eingehende Nachrichten laufen durch denselben Projekt-Relevanzfilter wie alle anderen Signale. Damit wird der TensorPM-Agent zum Multi-Stakeholder-Projektkanal statt zum Workspace-Daemon für einen einzelnen Nutzer. Der Agent ist erreichbar, solange die TensorPM-App auf dem PC des Projektverantwortlichen läuft. Always-on-Hosting in einem Rechenzentrum ist nicht Teil der Architektur, weil die Projektdaten lokal bleiben sollen.

Local-first und ohne permanenten Agenten-Gateway: TensorPM ist keine 24/7-Bot-Infrastruktur im Rechenzentrum. Alle Projektdaten leben in einer lokalen Datenbank auf der Maschine des Nutzers. Der Agent öffnet keine externen Integrationen von sich aus. Telegram ist die einzige eingehende Messenger-Anbindung; nach außen bleiben nur Web-Suche und Browser-Steuerung. Alles andere muss der Nutzer über MCP- oder A2A-Verbindungen explizit freischalten. Optionaler Cloud-Sync repliziert Projekte zwischen berechtigten Geräten und Workspace-Mitgliedern; im Netz liegen dabei verschlüsselte Projektinhalte, während für Sync, Rollen, Einladungen und Billing notwendige Metadaten sichtbar bleiben (Workspace-Namen, Mitglieder, IDs, Timestamps).

Der Agent läuft nicht im Hintergrund auf einem Cron-Scheduler, sondern wird durch Tasks aufgerufen, mit Begründung im Projektkontext. Wenn er aktiv wird, dann weil eine Projektsituation es verlangt, nicht weil ein Intervall abgelaufen ist.

Distillation läuft mit Bestätigung des Nutzers. Der Agent bereitet Vorschläge vor (Action Items aus einem Dokument, Entscheidungsvorlagen aus einer Mail, Kontext-Updates aus einem Meeting), präsentiert sie im Distiller und wartet auf die Freigabe. Damit wird autonome Drift deutlich schwerer, weil der Projektgraph nicht ohne Freigabe verändert wird.

Skills und Workflows sind so simpel anzulegen, dass der Mensch sie selbst schreibt: eine kleine Manifest-Datei, ein Skript, deklarierte Berechtigungen, fertig. Workflows lassen sich jederzeit als Skills definieren und einem Projekt hinzufügen. Bei Hermes erzeugt der Agent nach mehreren ähnlichen Tool-Aufrufen selbstständig ein Skill. Bei TensorPM bleibt diese Entscheidung beim Menschen. Auto-Vorschlag durch den TensorPM-Agenten ist auf der Roadmap, aber bewusst als Vorschlag, nicht als Auto-Apply.

KI-Backend: Multi-Provider von Haus aus, vom großen Closed-Source-Modell bis zum lokal laufenden Ollama. Eigene Keys oder TensorPM-Proxy.

Stärke: Das Projekt als Memory. Methodischer Relevanzfilter. Multi-Stakeholder-Telegram-Channel mit Rollen. Local-first. Offen für externe Agenten.

Grenze: Kein 24/7-Server-Daemon. Der Agent ist nur erreichbar, solange die Desktop-App läuft. Wer einen permanent online liegenden Bot über mehrere Messenger-Plattformen will, kombiniert TensorPM als Kontext-Schicht mit OpenClaw oder Hermes als Frontend.

OpenClaw: Allzweck-Personal-Agent mit Session-Gedächtnis

OpenClaw ist ein MIT-lizenziertes Personal-Agent-Framework von Peter Steinberger (zuvor PSPDFKit). Der Bezugsrahmen sind Sessions und Workspaces, nicht ein methodischer Projektgraph.

Architektonisch ist OpenClaw ein dauerhaft laufender Agent-Daemon, der sich an die Messenger andockt, die der Nutzer ohnehin verwendet: WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Microsoft Teams, Matrix und weitere. Mehrere Agenten können parallel pro Workspace laufen, mit eigenen Sessions und Skills.

Das Memory liegt als editierbare Notizdateien im Workspace und erinnert sich an Nutzer, verfügbare Tools und gelernte Vorlieben, aber nicht an ein konkretes Projekt mit Zielen, Risiken und Stakeholdern. Das ist Workspace-Memory, nicht Projekt-Memory.

Die Multi-Channel-Reichweite ist groß, aber konzeptuell ein einzelner Vertrauensraum: ein Agent pro Workspace, gebunden an einen Operator und seine Konten. Mehrere Personen können über denselben Gateway reden, aber projektgebundene Rollen und feingranulare Sichtbarkeiten gibt es nicht; jede Nachricht wird im Trust-Modell des Operators bedient.

Für Projektmanagement gibt es das Template Clawdbot, einen vorkonfigurierten Agenten für Task-Koordination, der über das ClawHub-Registry auf Tausende von Skills zugreifen kann (Integrationen für Linear, GitHub Issues, Jira, beliebige REST-APIs). Ein Projektgraph entsteht dadurch nicht; OpenClaw delegiert die Strukturierung an die externen Tools.

Stärke: Sehr breites Integrations-Ökosystem und starke Messenger-Abdeckung, darunter WhatsApp, Telegram, Discord, Slack, Signal und iMessage. Native Multi-Agent-Orchestrierung. Idealer Aufgaben-Agent für Power-User mit vielen Kanälen, die einen permanent online liegenden Daemon brauchen.

Grenze: Sicherheitsdisziplin ist Pflicht. Anfang 2026 hat Koi Security das damalige ClawHub-Skill-Verzeichnis auditiert und Hunderte schadhafte Einträge gefunden, die meisten aus einer einzigen koordinierten Kampagne. Microsoft empfiehlt im hauseigenen Security-Blog, OpenClaw als „untrusted code execution with persistent credentials" zu behandeln und nicht auf normalen Arbeitsrechnern laufen zu lassen. Strukturell: kein Projektgraph, kein methodischer Relevanzfilter, kein PM-UI.

Hermes Agent: Selbstlernender Aufgaben-Agent

Hermes Agent von Nous Research ist im Februar 2026 erschienen und gehört zu den am schnellsten wachsenden Open-Source-Agentenprojekten 2026 (sechsstellige Sterne-Zahl auf GitHub Stand Frühsommer 2026). Lizenz ist Open Source, Deployment auf eigener Infrastruktur.

Der definierende Mechanismus ist der Closed Learning Loop. Wenn der Agent eine Aufgabe abschließt, analysiert er seine Schritte, erkennt wiederkehrende Muster und erzeugt nach mehreren ähnlichen Tool-Aufrufen automatisch ein Skill. Diese werden direkt als Slash-Commands verfügbar. Das ist der Aufgaben-Lern-Mechanismus, den OpenClaw nicht hat.

Ob das eine Stärke oder ein Risiko ist, hängt vom Einsatz ab. Wer Vorhersagbarkeit und Auditierbarkeit im Skill-Bestand will, muss bei Hermes mehr Disziplin investieren als bei TensorPM, wo Skills bewusst menschengetrieben sind.

Persistentes Memory ist das zweite definierende Merkmal: ein kuratiertes Erinnerungs-Set, das beim Session-Start in den System-Prompt geladen wird, ergänzt um Plugin-Anbindungen für semantische Suche. Auch hier gilt: Es ist ein Memory über Workflows und Präferenzen, kein Memory über ein konkretes Projekt mit Zielen, Risiken, Budget und Stakeholdern.

Für PM-nahe Workflows bringt Hermes ein eigenes Kanban-Board mit, persistent und über CLI, Slash-Command oder Dashboard bedienbar. „Digital Twins" sind benannte Spezial-Agenten (etwa für Inbox-Triage oder Ops-Review), die über die Zeit Memory akkumulieren. Im Multi-Agent-Modus zerlegt ein Orchestrator Aufgaben automatisch, ein Schwarm zieht sie vom Board. Vendor-nahe Reviews berichten 40 Prozent schnellere Task-Completion; die Zahl sollte mit Vorsicht zitiert werden.

Hermes läuft als Daemon auf eigener Infrastruktur und ist über mehrere Messenger-Plattformen erreichbar, auch wenn am Arbeitsplatz des Nutzers nichts geöffnet ist.

Stärke: Selbstlernende Skills, die mit der Nutzung besser werden. Klare Kanban-Mechanik mit Multi-Agent-Erweiterung. Approval-System und mehrere Container-Backends werden mitgeliefert.

Grenze: Der Agent erinnert sich an Workflows, nicht an Projekte. Kein vollwertiger Projektgraph mit Zielen, Erfolgskriterien, Risiken, Entscheidungen, Budget. Das Kanban-Board ist eine Task-Sammlung, kein methodischer Projektkontext. Für klassische PM-Disziplin (Reference-Class-Forecasting, Decision-Logs, Budget-Tracking, Stakeholder-Management) muss zusätzliches Tooling daneben laufen.

Wo der Agent läuft: Desktop-App vs. Cloud-Daemon

Kurz gesagt: TensorPM läuft als Desktop-App auf dem PC des Projektverantwortlichen, erreichbar, solange die App offen ist. Dafür bleiben die Projektdaten lokal. OpenClaw und Hermes laufen als Daemon (eigener Rechner, VPS oder Cloud) und sind rund um die Uhr erreichbar. Schon die Hosting-Form entscheidet, wofür der Agent taugt.

Eine Achse, die in den meisten Vergleichen fehlt, weil sie als Detail durchgeht: Wo lebt der Agent eigentlich?

TensorPM ist eine Desktop-App auf dem PC des Projektverantwortlichen. Das ist bewusst gewählt, keine Lücke. Es gibt eine gemeinsame Arbeitsfläche: Kanban, Gantt, Budget, Files, Trail. Diese UI gehört zum Agenten, nicht als aufgesetztes Dashboard, sondern als Ort, an dem Mensch und Agent dieselben Objekte sehen und bearbeiten. Eine reine Server-Architektur ohne lokale UI würde dieses Zusammenspiel auflösen. Der Agent ist nur erreichbar, solange die App läuft; dafür bleibt der Arbeitskontext lokal, ein optionaler Cloud-Sync ist Ende-zu-Ende verschlüsselt.

OpenClaw und Hermes sind Daemons, die überall laufen können: auf einem zweiten Rechner zu Hause, auf einem VPS, in der Cloud oder in einem Docker-Container neben anderen Diensten. Sie sind dafür gebaut, rund um die Uhr erreichbar zu sein, ohne menschliches Endgerät als Voraussetzung. Wer einen permanent online liegenden Telegram-, WhatsApp- oder Slack-Bot braucht, wählt diese Architektur, nicht eine Desktop-App.

Das ist nicht der gleiche Markt. Wer einen Bot rund um die Uhr im Messenger braucht, braucht eine andere Architektur als jemand, der ein Projekt in einer gemeinsamen Arbeitsfläche steuert. Mit der Hosting-Form fällt also schon die Entscheidung für das Einsatzfeld.

Zugriff und Transparenz: drei unterschiedliche Sicherheitsmodelle

Kurz gesagt: TensorPM begrenzt den Zugriff über die Architektur: kein Bash-Zugriff, Sichtfeld nur im Projektordner, jede Aktion im Trail. OpenClaw führt im Standard mit vollem Host-Zugriff aus, hier ist Disziplin Pflicht. Hermes verbindet Shell-Zugriff mit einem Freigabe- und Isolations-Modell. Bei OpenClaw und Hermes hängt die echte Sicherheitsgrenze stärker vom Betreiber ab.

Ein Aspekt, der in Vergleichen oft fehlt, weil er unsichtbar bleibt, solange nichts schiefgeht: Welchen Zugriff hat der Agent auf das System, und sieht der Nutzer im Nachhinein, was er getan hat?

TensorPM begrenzt den Zugriff architektonisch stärker als klassische Daemon-Agenten. Der Agent hat keinen Bash-Zugriff auf das System. Sein Sichtfeld endet am Projektordner. Erlaubte Aktionen sind Web-Suche, Browser-Interaktionen über ein gesteuertes Profil, Skills in einer Sandbox mit standardmäßig deaktiviertem Netzwerk, und das, was über konfigurierte MCP- oder A2A-Verbindungen freigeschaltet wurde. Der Agent öffnet keine externen Integrationen von sich aus; angebundene Quellen und Schnittstellen müssen explizit konfiguriert werden. Nicht konfigurierte Quellen werden nicht automatisch in den Kontext aufgenommen. Jede Agentenaktion landet im Trail des Projekts: was wurde wann gemacht, mit welcher Begründung, mit welchem Ergebnis. Der Nutzer kann nachvollziehen, welche Aktion warum ausgelöst wurde.

OpenClaw ist auf das Trust-Modell „ein vertrauenswürdiger Operator" ausgelegt. Die offizielle Dokumentation beschreibt den Default als Host-Ausführung mit voller Sicherheitsstufe und ohne Rückfrage, gedacht für einen einzelnen Operator, der seinem Agenten vertraut. Damit kann der Agent in dieser Standardeinstellung beliebige Shell-Befehle ausführen, Dateien lesen und schreiben, Netzwerkdienste nutzen, Nachrichten verschicken. Multi-Mandanten- oder feindselige Multi-User-Szenarien sind explizit nicht das Designziel. Microsoft hat im Februar 2026 einen Security-Blog veröffentlicht, der OpenClaw als „untrusted code execution with persistent credentials" einstuft und vom Betrieb auf normalen Arbeitsrechnern abrät. Im Frühjahr 2026 wurde OpenClaw intensiv sicherheitlich untersucht; neben öffentlich diskutierten Schwachstellen rückte vor allem die Skill-Supply-Chain in den Fokus. Koi Security fand in einem ClawHub-Audit 341 schadhafte Skills, davon 335 aus einer koordinierten Kampagne. Wer OpenClaw produktiv einsetzt, baut die Sicherheitsdisziplin selbst auf: Skill-Whitelisting, Sandbox-Wrapper, getrennte Identitäten, Container-Isolation.

Hermes Agent kombiniert Shell-Zugriff mit einem expliziten Freigabe- und Isolations-Modell. Per Design hat der Agent ebenfalls Shell-Zugriff über das Terminal-Tool, aber Nous Research liefert ein Approval-System mit, das Terminal-Befehle, Dateioperationen und destruktive Aktionen hinter eine explizite Nutzerbestätigung legt. Mehrere Terminal-Backends erlauben, die Ausführung in Container zu verlagern. Die Dokumentation nennt allerdings ehrlich Konfigurationsschalter, mit denen sich diese Sicherheitsgrenze für Produktivumgebungen ausschalten lässt. Ab April/Mai 2026 wurden erste CVEs für Hermes öffentlich gelistet, unter anderem zu Path-Traversal, Symlinks und Injection-Themen. Das macht Hermes nicht automatisch unsicherer als OpenClaw. Es zeigt nur, dass auch Hermes wie jedes toolfähige Agentensystem ein echtes Security-Modell braucht. Die offizielle Security Policy stellt ehrlich klar, dass die einzige wirksame Grenze gegen ein adversariales LLM die Isolation auf Betriebssystemebene ist, nicht Approval-Gates, Tool-Allowlisten oder Muster-Scanner.

Praktisch heißt das: Bei TensorPM ist der Aktionsradius enger in die Produktarchitektur eingebaut. Bei OpenClaw und Hermes hängt die reale Sicherheitsgrenze stärker davon ab, ob der Betreiber Gateway, Zugangsdaten, Shell-Zugriff und Betriebssystem-Isolation sauber trennt. Für routinierte Power-User auf isolierten Maschinen ist das gut handhabbar. In regulierten Branchen oder auf geteilten Geräten wird daraus ein Aufwand, der den Betrieb mitprägt.

Projektgeheimnisse und Datenhoheit: Wer darf das Projektgedächtnis halten?

Kurz gesagt: Bei OpenClaw und Hermes liegt die DSGVO-Verantwortung beim Betreiber, denn beide geben keine eigene EU-Zusage und hängen an der Wahl von Gateway und Provider. TensorPM hält das Projektgedächtnis lokal-first und projektbezogen: Der Agent sieht standardmäßig nur den Projektordner und die aktiv angebundenen Quellen. Entscheidend ist, wer die Daten überhaupt dauerhaft sehen darf, nicht nur, wo der Server steht.

Bei Projektmanagement-Agenten ist Datenschutz nicht nur eine Hosting-Frage. In der Praxis geht es darum, welcher Agent Projektkommunikation, Budgetstände, Vertragsänderungen und offene Entscheidungen dauerhaft sehen und speichern darf. Hier wird der Unterschied zwischen Aufgaben-Agenten und Projektsteuerungs-Agenten praktisch relevant.

OpenClaw lässt sich datenschutzbewusst betreiben, aber die DSGVO-Architektur liegt beim Betreiber. Die offizielle Privacy-Dokumentation stellt klar, dass App-Daten an den vom Nutzer gewählten Gateway gehen und dass die Praktiken dieses Gateways, des LLM-Providers und angeschlossener Dienste nicht abgedeckt sind. Wer einen sauberen EU-Betrieb mit Azure OpenAI oder vergleichbarem Routing aufsetzt, kann das produktiv lösen; Datenschutz ist hier Betreiberdisziplin, nicht Produktversprechen.

Hermes Agent ist ebenfalls self-hosted und damit kontrollierbar. Eine explizite DSGVO- oder EU-Residency-Zusage gibt es nicht. Was es gibt, sind technische Bausteine: opt-in PII-Redaktion (nicht für alle Plattformen), Retention-Konfiguration, Container-Isolation, Approval-Modi. Standardmäßig wird die Session-Historie nicht automatisch gelöscht, denn der Self-Learning-Loop braucht Memory. Aus DSGVO-Sicht ist genau das die Stelle, an der Zweckbindung und Löschstrategie sauber definiert sein müssen.

TensorPM hält das Projektgedächtnis lokal-first und projektbezogen. Der Agent sieht standardmäßig nicht den ganzen PC, sondern nur den Projektordner, der destilliert wird, plus die Quellen, die der Nutzer aktiv angebunden hat (Mail-Konten, MCP-/A2A-Verbindungen). Alles andere gelangt erst durch bewusste Interaktion oder Konfiguration in den Kontext. Nach außen bleiben nur Web-Suche und Browser-Steuerung. Optionaler Cloud-Sync verschlüsselt Projektinhalte Ende-zu-Ende; die sichtbaren Metadaten (Workspace, Mitglieder, IDs, Timestamps) wurden oben benannt.

Entscheidend ist die Kontext-Hoheit: Welche Informationen werden überhaupt dauerhaft Teil des Projektgedächtnisses? OpenClaw und Hermes sind so gebaut, dass sie viel sehen können, weil sie Aufgaben in vielen Kanälen erledigen sollen. TensorPM ist so gebaut, dass nicht alles automatisch Teil des Projektgedächtnisses wird, sondern nur das, was für die Projektintention relevant ist. Das heißt nicht, dass TensorPM ohne externen Datenfluss arbeitet: BYOK- oder Proxy-Inferenz, die Wahl der Konnektoren und die Endpoint-Sicherheit bleiben in der Verantwortung des Betreibers. Es heißt aber, dass Projektinhalt und Datenminimierung enger gekoppelt sind.

Direkter Vergleich

Kriterium	TensorPM	OpenClaw	Hermes Agent
Bezugsrahmen	Projekt	Session/Workspace	Session/Workflow
Memory	Projektgraph: Ziele, Risiken, Entscheidungen, Action Items, Historie	Workspace-Notizen, Tool-Konfiguration, Präferenzen	Kuratiertes Erinnerungs-Set, Workflows, Präferenzen
Relevanzfilter	Methodisch, strikt projektbezogen	Manuell	Manuell, plus Auto-Skill-Generierung
Agentenrolle	Fest: das Projekt zum Erfolg bringen	Aufgabenbezogen, vom Nutzer gesetzt	Aufgabenbezogen, vom Nutzer gesetzt
Hosting	Lokale Desktop-App auf dem PC des Projektverantwortlichen	Daemon, beliebig (eigener Rechner, VPS, Cloud)	Daemon, beliebig (eigener Rechner, VPS, Cloud)
Gateway nach draußen	Telegram eingehend, Web-Suche und Browser ausgehend, sonst nur über konfigurierte MCP/A2A	Breite Host- und Tool-Ausführung; Host-Exec im trusted-single-operator-Default weit geöffnet, sofern nicht gehärtet	Shell und Tools, mit Approval-System abgesichert
Eigene Ausführung	Web, Browser, Skills (sandboxed), Mail, Git	Shell, Files, Browser, REST-APIs	Tools, Code, Web, Skills, geplante Aufgaben
Transparenz	Vollständiger Trail aller Agent-Aktionen im Projekt	Logs/History pro Session	Logs pro Session
Trigger-Modell	Rekursiv durch Tasks, kein blinder Cron	Always-on-Gateway/Daemon, event- und integrationsgetrieben	Always-on plus built-in Cron/Scheduler
Messenger	Telegram (kein WhatsApp) mit projektbezogenen Rollen und Sichtbarkeiten	Mehrere Plattformen inkl. WhatsApp, Telegram, Discord, Slack, Signal, iMessage; single trust boundary	Mehrere Plattformen inkl. Telegram, Discord, Slack, WhatsApp, Signal; personal-agent-zentriertes Trust-Modell, keine projektbezogenen Rollen/Sichtbarkeiten
Verfügbarkeit	Solange die Desktop-App auf dem PC läuft	24/7 als Daemon	24/7 als Daemon
Skill-Erstellung	Menschengetrieben; Auto-Vorschlag in Roadmap	Community- und Workspace-Skills, Skill-Erstellung möglich, aber kein Hermes-artiger Closed-Learning-Loop	Vom Agent autonom aus wiederkehrenden Mustern generiert
PM-UI	Listen, Kanban, Gantt, Budget, Files, Trail	Keines (Messaging-First)	Kanban-Dashboard
Externes Agenten-Interface	MCP und A2A	MCP-Server + Messenger-Channels	Slash-Commands, Dashboard, API
Verschlüsselung	E2E (Cloud-Sync)	Self-Hosting-abhängig	Self-Hosting-abhängig
Sicherheits-Track	Sandbox, Skill-Approval, kein Bash laut Produktarchitektur	Breites Host-Exec-Trust-Modell, Skill-Supply-Chain-Risiken öffentlich dokumentiert (Koi-Audit: 341 schadhafte Skills)	Erste CVEs seit Frühjahr 2026, Approval-System und OS-Isolation als empfohlene Grenze
Lizenz	Proprietär	Open Source (MIT)	Open Source (MIT)
Sweet Spot	Übergeordnete Projekte mit hoher Kontextdichte und mehreren Stakeholdern	Allzweck-Automation über viele Messaging-Kanäle	Wiederkehrende Workflows, die mit der Zeit besser werden sollen

Wann welcher Agent?

Kurz gesagt: Für Aufgaben über viele Kanäle, rund um die Uhr: OpenClaw. Für wiederkehrende Routinen, die mit der Zeit besser werden sollen: Hermes Agent. Für die Steuerung eines übergeordneten Projekts mit mehreren Beteiligten, methodisch und mit Audit-Trail: TensorPM. Wer ausführt, Mensch oder Agent, richtet sich danach, wer das Projekt am zuverlässigsten in Termin, Budget und Scope hält.

OpenClaw und Hermes optimieren Aufgabenerledigung: einen Workflow anstoßen, einen Bot antworten lassen, eine Datei verarbeiten, einen geplanten Job auslösen. In dieser Disziplin sind sie sehr gut.

TensorPM optimiert Projektsteuerung: welche Aufgaben sind überhaupt projektrelevant, in welcher Reihenfolge, mit welchem Risiko, an wen verteilt. Ob am Ende ein Mensch oder ein Agent ausführt, richtet sich danach, wer das Projekt am zuverlässigsten innerhalb von Termin, Budget und Scope hält.

Fünf typische Konstellationen:

„Wir managen ein zehn-Millionen-Euro-Bauprojekt mit 60 Beteiligten über zwei Jahre." TensorPM. Auf dieser Größenordnung ist die Frage nicht „wer erledigt die nächste Mail?", sondern „wo stehen wir, was steht im Risiko, welche Entscheidung steht an?". Diese Fragen verlangen einen Projektgraphen, der über Wochen und Monate hinweg verlässlich fortgeschrieben wird, mit Audit-Trail und methodischer Relevanzfilterung. Hermes und OpenClaw sind hier nicht falsch, aber sie sind eine Ebene zu niedrig angesiedelt.

„Wir wollen, dass Bauherr, Architekt, Subunternehmer und Projektsteuerer den Agenten über Telegram ansprechen, jeder mit eigener Rolle und Sichtbarkeit." TensorPM. Der Telegram-Channel ist genau für diesen Multi-Stakeholder-Modus ausgelegt: jede Person mit eigener Rolle, eigenen Schreib- und Leserechten auf Teile des Projektgraphen, eigenen erlaubten Aktionen. Voraussetzung ist, dass die TensorPM-Desktop-App beim Projektverantwortlichen läuft; ein Always-on-Bot im Rechenzentrum ist nicht Teil der Architektur. OpenClaw und Hermes decken zwar mehr Channels ab (inklusive WhatsApp), sind aber im Kern Single-User-Agenten: Der Agent gehört dem Kontoinhaber, eine projektgebundene Rollenverteilung gibt es nicht.

„Wir wollen einen 24/7-Allzweck-Daemon, der unabhängig vom Arbeitsplatz auf WhatsApp oder Signal reagiert." OpenClaw. Der Always-on-Gateway-Ansatz, die Vielzahl an Messenger-Channels und die Self-Hosted-Architektur sind dafür gebaut. Sicherheitsdisziplin (Skill-Whitelisting, Berechtigungen, Container-Isolation) ist Pflicht.

„Wir haben einen Wochenrhythmus aus Standups, Reports und Retros, der mit der Zeit besser laufen soll, und uns ist egal, dass der Agent autonom Skills generiert." Hermes Agent. Der Self-Learning-Loop generiert reproduzierbare Slash-Commands aus Mustern, der Cron-Scheduler triggert, das Kanban hält Tasks persistent. Wer dagegen will, dass jeder neue Skill bewusst von einem Menschen geschrieben und genehmigt wird, ist mit TensorPM besser beraten.

„Wir wollen, dass ein Agent aus eingehenden Mails strukturierte Action Items und Entscheidungsvorlagen macht, projektrichtig zugeordnet, mit menschlicher Bestätigung." TensorPM. Das ist exakt der Distillation-Workflow, für den die Plattform gebaut ist: Mail-Konnektor, Relevanzfilter gegen den Projektgraphen, Vorschlagsstruktur, Human-in-the-Loop-Freigabe, Änderung des Graphen mit Audit-Eintrag.

Es ist kein Entweder-oder

Weil TensorPM ein MCP- und A2A-Endpunkt ist, kann ein OpenClaw-Agent im WhatsApp-Kanal oder ein Hermes-Agent im Cron-Job über die Standardschnittstelle den TensorPM-Projektgraphen lesen und Vorschläge dort einreichen. Der Allzweck-Agent erledigt die operative Aufgabe; der Projekt-Agent hält den methodischen Kontext. Beide sehen dasselbe Projekt.

Das ist die Idee hinter Context-Driven Project Management (CDPM): nicht der eine Agent, der alles ersetzt, sondern ein gemeinsamer, sauber strukturierter Projektkontext, auf den jeder Agent und jeder Mensch zugreift. Die Methode liefert das „Wie", der Kontext-Layer das gemeinsame Gedächtnis.

Fazit: Task Completion oder Project Intent?

Die Wahl zwischen TensorPM, OpenClaw und Hermes hängt davon ab, was der Agent tun soll.

Wer Aufgabenerledigung sucht, also viele Kanäle, viele wiederkehrende Routinen, viel operative Arbeit, idealerweise rund um die Uhr, ist mit OpenClaw oder Hermes Agent richtig bedient. OpenClaw, wenn Integrationsbreite und Messaging dominieren; Hermes, wenn der Wert in Wiederholbarkeit und Self-Learning liegt. Beide sind exzellente operative Assistenten.

Wer Projektsteuerung sucht, also ein übergeordnetes Projekt mit mehreren Stakeholdern in klaren Rollen, methodisch fortgeschrieben, in dem die Projektintention dauerhaft verfolgt werden muss, ist mit TensorPM richtig bedient. Die Leitfrage verschiebt sich von „wie erledige ich diese Aufgabe?" zu „welche Aufgabe bringt das Projekt voran, ohne Termin, Budget oder Scope zu gefährden?". Wer die Aufgabe ausführt, Mensch oder Agent, richtet sich danach, wer es am besten kann. Skills bleiben menschengetrieben, der Agent wird durch Tasks aufgerufen statt durch einen Cron-Heartbeat, und der Systemzugriff ist über die Architektur begrenzt: kein Bash-Zugriff, kein Zugriff außerhalb des Projektordners, jede Aktion im Trail nachvollziehbar.

In vielen mittelständischen Projektorganisationen wird die produktive Antwort eine Kombination sein: TensorPM als Projekt-Agent und Kontext-Schicht, OpenClaw oder Hermes als spezialisierter Aufgaben-Agent davor. Die offene Agentenschnittstelle von TensorPM macht das technisch sauber möglich.

Wer den Unterschied an einem echten Projekt testen möchte: TensorPM ist als Desktop-App für Windows, macOS und Linux kostenlos verfügbar und lässt sich mit eigenen LLM-Keys oder vollständig lokal über Ollama betreiben.