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, der Hermes Agent von Nous Research, Pi und DeepSeek Harness stehen für fünf unterschiedliche Agenten-Paradigmen. Entscheidend ist nicht, welche Feature-Liste am längsten ist. Entscheidend ist, welche Ebene der Projektarbeit ein System abdeckt.

OpenClaw und Hermes organisieren operative Arbeit. Pi und DeepSeek Harness stellen die technische Agentenlaufzeit bereit. TensorPM fragt, welche Arbeit das Projekt voranbringt und welche Folgen sie für Termin, Budget und Scope hat.

Kurz: Task Completion, Harness Design und Project Intent. Wer diese Ebenen trennt, vergleicht keine Werkzeuge mehr, die verschiedene Probleme lösen. Ob eine Aufgabe am Ende von einem Menschen, Pi, DeepSeek Harness oder einem anderen Agenten erledigt wird, ist für die Projektsteuerung zweitrangig. Entscheidend ist, dass die Aufgabe zum Projektziel passt und ihr Ergebnis in den Projektkontext zurückkehrt.

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, Agentenlaufzeit oder Projektsteuerung?

Kurz gesagt: OpenClaw und Hermes organisieren konkrete Aufträge und wiederkehrende Abläufe. Pi und DeepSeek Harness geben technischen Agenten Modelle, Werkzeuge, Sessions und Laufzeitlogik. TensorPM ergänzt diese Ebenen um einen lebenden Projektkontext und unterstützt die Bewertung, welche Arbeit das Projekt voranbringt. 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?
Rolle im Projekt	Operative Ausführung	Kontextschicht für die Projektsteuerung, ergänzt um Ausführung
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 hilft zu bewerten, welche Aufgaben überhaupt projektlogisch relevant sind, wer betroffen ist, welche Entscheidung daraus folgen könnte 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 Agent, der nur den jeweiligen Auftrag sieht, könnte alle drei nach derselben Logik bearbeiten: extrahieren, ablegen, vielleicht eine Aufgabe daraus machen. TensorPM prüft die Nachrichten zunächst gegen den bestätigten Projektkontext und schlägt vor, welche davon die Projektintention verändern. Newsletter und Werbeanfrage fallen aus der engeren Projektbetrachtung. 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 Rolle von TensorPM

Aus dieser Zielrichtung folgt die Rolle von TensorPM: Der aktuelle, bestätigte Kontext ist das Fundament; Projektanalyse und Guidance bilden den Kern; konkrete Ausführung erweitert beides dort, wo sie dem Projekt dient. Recherche, Destillation, Vorbereitung und Skill-Ausführung kann die KI übernehmen oder vorschlagen. Verantwortliche Menschen bestätigen Kontextänderungen und entscheiden über folgenreiche Eingriffe in Termin, Budget, Scope und Autorität.

TensorPM: Projektkontext als Intentionsträger

TensorPM verbindet operative Ausführung mit kontextbasierter Guidance für die Projektsteuerung. Der Projektgraph ist sein Gedächtnis, aber nicht sein Zweck. Er soll die Projektintention über Wochen, Monate und mehrere Stakeholder hinweg nachvollziehbar halten und daraus Vorschläge für Arbeit, Entscheidungen, Risiken und Kommunikation ableiten.

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-Recherche, Browser-Sessions, abgeschottete Skills, Kalenderentwürfe sowie die Erstellung und Überarbeitung von Word-Dokumenten, PDF-Berichten und Präsentationen. Technische Action Items kann TensorPM direkt an Codex oder Claude Code delegieren und den Lauf interaktiv oder headless verfolgen. Die Ausführung bleibt in die Projektsicht eingebettet; Tool-Aufrufe, Kontextvorschläge und Entscheidungen erscheinen im Activity Trail.

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 kann aus einer Konversation heraus zukünftige Läufe und Erinnerungen planen. Das macht TensorPM jedoch nicht zu einem permanenten Cloud-Daemon: geplante und interaktive Ausführung bleibt an die lokale Desktop-Laufzeit und ihre Berechtigungsgrenzen gebunden.

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 werden als explizite Fähigkeiten mit Anweisungen und Ressourcen eingebunden. Im Unterschied zu einem automatisch gelernten, still aktivierten Ablauf bleibt sichtbar, welche Fähigkeit verwendet wird und welche Werkzeuge oder Berechtigungen sie benötigt.

KI-Backend: Multi-Provider, TensorPM-gehostete KI über Trial/Pro/Business, Business-BYOK sowie lokale Modelle über Ollama, LM Studio oder vLLM. Claude- und ChatGPT-Abos lassen sich über die lokalen Claude-Code- beziehungsweise Codex-Runtimes verbinden.

Stärke: Das Projekt als Memory und Steuerungsmodell. Relevanzfilter, Analyse und Guidance, konkrete Artefakte, direkte Delegation an Coding-Agenten, Multi-Stakeholder-Telegram-Channel, local-first und offen über MCP/A2A.

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. Gut geeignet für Power-User mit vielen Kanälen, die einen permanent online liegenden Daemon für operative Automatisierung 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: Selbstlernende Ausführung wiederkehrender Aufgaben

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.

Pi: Der bewusst minimale Agenten-Harness

Pi bezeichnet sich selbst nicht als Projektmanagement-Agent, sondern als minimalen Terminal-Harness für Coding-Agenten. Diese Selbstbeschreibung ist wichtig. Pi will nicht möglichst viele fertige Funktionen vorgeben. Es stellt einen kleinen, transparenten Kern bereit, den Nutzer mit TypeScript-Extensions, Skills, Prompt-Templates, Themes und installierbaren Paketen an ihren eigenen Workflow anpassen.

Der Kern unterstützt mehr als 15 Provider und Hunderte Modelle. Das Modell lässt sich während einer Session wechseln. Sessions werden als Baum gespeichert, sodass ein Nutzer zu einem früheren Punkt zurückspringen, einen anderen Weg verfolgen und beide Verläufe in einer Datei behalten kann. Während der Agent arbeitet, lassen sich Steuerungsnachrichten nach dem aktuellen Tool-Aufruf einschieben. Alternativ wartet ein Follow-up, bis der Lauf beendet ist.

Pi bietet vier Betriebsarten: eine interaktive Terminaloberfläche, Print oder JSON für Skripte, RPC über stdin und stdout sowie ein SDK zum Einbetten in andere Anwendungen. OpenClaw ist ein reales Beispiel für diese Einbettung. Damit ist Pi weniger ein fertiger Arbeitsplatz als ein Baustein, aus dem andere Agentenprodukte entstehen können.

Die bewusst weggelassenen Funktionen sagen fast mehr über Pi aus als die eingebauten. Im Kern gibt es kein MCP, keine Subagenten, keine Berechtigungsdialoge, keinen Plan-Modus, keine integrierte Todo-Verwaltung und keinen Hintergrund-Bash-Prozess. Alles davon lässt sich über Extensions, Pakete, externe CLI-Werkzeuge oder Container ergänzen. Für erfahrene Entwickler ist das attraktiv, weil der Harness den Workflow nicht diktiert. Für Teams ohne eigene Harness-Kompetenz bedeutet es zusätzliche Architekturarbeit.

Für Projektmanagement ist Pi daher ein möglicher technischer Ausführer. Ein sauber formuliertes Action Item kann in einer Pi-Session umgesetzt werden. Pi hält aber weder Budget, Stakeholder, Risiken noch Projektintention. Auch die Sicherheitsgrenze ist nicht automatisch Teil des Kerns. Wer Freigaben, Pfadschutz oder Sandboxing braucht, muss sie bewusst ergänzen.

Stärke: Kleiner, nachvollziehbarer Kern. Sehr hohe Anpassbarkeit. Modellwechsel innerhalb einer Session. Baumförmige Historie, Laufzeit-Steuerung, SDK und RPC. Gut für Teams, die ihren Agenten-Harness selbst besitzen wollen.

Grenze: Viele Funktionen, die andere Produkte als Standard liefern, müssen gebaut oder installiert werden. Kein eingebauter Projektgraph, kein PM-Modell und kein eigener Mechanismus, der Agentenergebnisse wieder in die Projektsteuerung überführt.

DeepSeek Harness: Alles ist ein Plugin

DeepSeek Harness, kurz dsh, ist DeepSeeks eigener Open-Source-Harness. Er wurde im August 2026 als Developer Preview veröffentlicht und steht unter MIT-Lizenz. DeepSeek warnt ausdrücklich vor noch kommenden Kompatibilitätsbrüchen. Für eine produktive Beschaffungsentscheidung ist das deshalb heute eher eine Architekturwette als ein fertiger Standard.

Seine Leitidee lautet: Jede Fähigkeit ist ein Plugin. Modelle, Tools, Skills, Sessions, Sandboxes, Speicher, Agentenschleifen, Scheduling und die Benutzeroberfläche lassen sich auswählen, austauschen oder neu zusammensetzen. Der Cordis-Kernel kümmert sich nur um das Mounten, Entfernen und die Abhängigkeiten dieser Plugins. Die eigentlichen Agentenfähigkeiten leben außerhalb des Kerns.

DeepSeek Harness liefert mehrere Laufzeitmodi. Standard Mode ist ein vollständiger Coding-Agent mit Datei- und Websuche, Shell, Planung, Zielen, Subagenten und Workflows. Code Mode stellt die Werkzeuge zusätzlich über ein TypeScript-SDK bereit, damit das Modell mehrstufige Tool-Aufrufe in einem Programm orchestrieren kann. Minimal Mode reduziert den Agenten auf persistentes Bash und einen Datei-Editor. Creator Mode dient dazu, neue Presets und Plugin-Kombinationen innerhalb des laufenden Systems zu entwerfen und zu testen.

Die zweite starke Idee ist die Ereignisspur. Alles, was das Modell sieht, landet in einem append-only Session-Log: System-Prompts, Reasoning, Tool-Aufrufe, Ergebnisse, Subagenten-Scheduling und Kontextinjektionen. Suche, Resume, Fork und Replay arbeiten auf demselben Event-Stream. Damit wird der Harness nicht nur anpassbar, sondern auch rekonstruierbar.

Standardmäßig startet dsh als lokale Weboberfläche und arbeitet in einem ausdrücklich ausgewählten Workspace. Laut DeepSeek werden Eingaben, Modellausgaben, Tool-Aufrufe, Pfade und Laufzeitlogs zunächst lokal gespeichert. Externe Modelle, Web-Werkzeuge, MCP-Server und Plugins können Daten jedoch an ihre jeweiligen Anbieter übertragen. DeepSeek empfiehlt wegen der lokalen Codeausführung ausdrücklich eine dedizierte VM oder einen Container, menschliche Freigaben für folgenreiche Aktionen und ausschließlich geprüfte Plugins, Skills und MCP-Server.

Auch DeepSeek Harness ist kein Projektmanagementsystem. Sein Bezugsrahmen ist die technische Agentenlaufzeit. Ein Plugin könnte Projektkontext bereitstellen oder Ergebnisse an ein PM-System zurückschreiben. Diese Verbindung ist aber eine Konfiguration oder Entwicklung, kein eingebautes Projektmodell.

Stärke: Konsequente Plugin-Architektur, mehrere Laufzeitmodi, vollständige Event-Spur, lokale Weboberfläche und ein Creator Mode zum Aufbau eigener Agentenpresets. Interessant für Plattformteams, die eine eigene Agentenlaufzeit zusammensetzen wollen.

Grenze: Developer Preview mit angekündigten Breaking Changes. Breiter lokaler Aktionsradius und Plugin-Supply-Chain erfordern eigene Sicherheitsarchitektur. Kein Projektgraph, keine Stakeholderlogik und keine methodische Projektsteuerung.

Sparse Attention trifft auf ein wachsendes Event-Log

Hier entsteht ein interessanter Architekturkonflikt. DeepSeek V4 erreicht sein Kontextfenster von einer Million Tokens mit tokenweiser Kompression und DeepSeek Sparse Attention. Sparse Attention reduziert Rechenaufwand, indem nicht jeder neue Token detailliert auf jeden alten Token blickt. Ein Indexer wählt die Teile der Historie aus, die für die aktuelle Anfrage wichtig erscheinen.

DeepSeek Harness setzt gleichzeitig auf ein append-only Event-Log als dauerhafte Wahrheit einer Session. System-Prompts, Nachrichten, Reasoning, Tool-Aufrufe, Ergebnisse, Subagenten und Kontextinjektionen bleiben erhalten. Die Modellhistorie wird aus diesem Log abgeleitet. Je länger ein Agent arbeitet, desto größer wird also der mögliche Haystack, in dem eine kleine, frühe Information wiedergefunden werden muss.

Die naheliegende Pointe lautet: Ausgerechnet DeepSeek baut einen Harness, der lange Historien fördert, während die eigenen Modelle durch Sparse Attention selektiv entscheiden müssen, welche alten Bereiche sie überhaupt genauer betrachten. Ganz so einfach ist es jedoch nicht.

DeepSeek bewirbt V4 ausdrücklich als Long-Context-Modell. Der aktuelle 0731-Checkpoint wurde außerdem im Minimal Mode von DeepSeek Harness auf Agentenbenchmarks evaluiert. Unabhängige Tests zeigen erfolgreiche Needle-Retrieval bis über eine Million Tokens, wenn der Sparse Indexer korrekt implementiert ist. Ein aktueller vLLM-ROCm-Bug zeigt dagegen das Gegenrisiko: In dieser konkreten Backend-Konfiguration fiel die Retrieval-Rate schon zwischen rund 3.600 und 5.300 Tokens von drei Treffern auf null. Das Issue führt den Fehler auf den Sparse-Indexer-Pfad der Implementierung zurück, nicht auf einen bewiesenen generellen Modellfehler.

Die belastbare Aussage ist deshalb enger. Sparse Attention macht Long Context günstiger, aber die Zuverlässigkeit hängt stärker von Indexer, Backend, Quantisierung und der Form der gesuchten Information ab. Forschung zu Needle-in-a-Haystack zeigt zudem modellübergreifend, dass kurze, feine Fakten zwischen vielen Distraktoren schwerer zu finden sind als große relevante Blöcke.

DeepSeek Harness begegnet dem Problem mit Compaction. Ältere Bereiche können durch eine Zusammenfassung ersetzt werden, während das vollständige Event-Log für Replay und Audit erhalten bleibt. Das ist besser, als die gesamte Rohhistorie blind in jeden Modellaufruf zu kippen. Es verschiebt das Risiko aber auf die Zusammenfassung. Was dort verloren geht, kann das Modell später nur über zusätzliche Suche, Replay oder gezielte Kontextinjektion wiederfinden.

Für lange Projektarbeit folgt daraus eine klare Regel: Das append-only Log ist eine gute Beweisspur, aber kein Ersatz für strukturiertes Gedächtnis. Kritische Ziele, Entscheidungen, Risiken und Zusagen sollten nicht nur irgendwo in einer wachsenden Session liegen. Sie brauchen adressierbare, typisierte Einträge, die ein Harness gezielt in den aktuellen Kontext holen kann.

Wenn ein Modellbenchmark plötzlich den Harness nennt

Die Modellkarte von DeepSeek-V4-Flash-0731 enthält einen bemerkenswerten Methodenhinweis. DeepSeek sagt nicht nur, welches Modell den Score erreicht hat. Für die Code-Agent-Benchmarks nennt das Unternehmen auch den verwendeten Agentenrahmen: Minimal Mode von DeepSeek Harness, max Reasoning Effort, Temperatur 1,0 und Top-p 0,95.

Damit macht DeepSeek sichtbar, was bei Agentenbenchmarks häufig im Kleingedruckten verschwindet. Ein Score gehört nicht nur zu einem Modell. Er gehört zu einer Kombination aus Modell, Harness, Tools, Prompt, Kontextmanagement, Abbruchlogik, Berechtigungen und Testumgebung.

Das ist heute keineswegs normal. Kommerzielle Modellveröffentlichungen zeigen meistens einen Modellnamen und einen Score. Der verwendete Harness bleibt ungenannt, wird nur grob als internes Scaffold beschrieben oder ist außerhalb des Anbieters überhaupt nicht verfügbar. Aktuelle Forschung zum Scaffold Effect kritisiert genau diese Unterbestimmung.

Es gibt frühere Gegenbeispiele. OpenAI hat in System Cards interne Tool-Scaffolds für Agentenevaluationen beschrieben. Google erläuterte im Gemini-2.5-Pro-Model-Card ein eigenes Multi-Attempt-Scaffolding für SWE-bench und warnte ausdrücklich davor, Anbieterzahlen mit unterschiedlichen Scaffolds und Infrastrukturen direkt zu vergleichen. Diese Angaben bleiben aber häufig auf einer abstrakten Ebene. Der konkret verwendete Harness ist oft intern, nicht installierbar und nicht als eigenständige Laufzeit nachvollziehbar.

DeepSeeks Schritt ist deshalb mehr als eine weitere Fußnote. Das Unternehmen veröffentlicht Modell und eigenen Open-Source-Harness gemeinsam, nennt den konkreten Harness-Modus direkt in der Modellkarte und ergänzt wesentliche Inference-Einstellungen. Andere Entwickler können die Laufzeit untersuchen, die Konfiguration nachvollziehen und Teile des Versuchs reproduzieren.

Es ist nicht belastbar als weltweit allererste Harness-Nennung in einem KI-Benchmark zu bezeichnen. Es ist aber ein echtes Novum in der heutigen Praxis großer Modellveröffentlichungen: Ein Anbieter macht den eigenen öffentlich verfügbaren Harness samt Modus zur sichtbaren Komponente des Modellresultats. Das bleibt im Markt sehr selten.

Harness-Bench und Arbeiten zum Scaffold Effect behandeln Modell-Harness-Paare inzwischen ausdrücklich als eigentliche Bewertungseinheit. Sie zeigen, dass der Harness Passrate, Tokenverbrauch, Laufzeit und Fehlerbild erheblich verändern kann. Ein Modellranking ohne Harness-Angabe ist bei agentischer Arbeit deshalb methodisch unvollständig.

ProjectBench folgt diesem Prinzip von Anfang an. Wir messen nicht, wie ein Modell auf einen isolierten Prompt antwortet. Wir messen, wie es im echten TensorPM arbeitet, mit Projektgraph, Tools, Freigaben, Replanning und Blindbewertung. Der Harness bleibt für die Modellvergleiche konstant. Damit lässt sich besser erkennen, welcher Anteil der Planqualität vom Modell kommt und welcher aus strukturiertem Projektkontext und Produktworkflow entsteht.

Die Parallele ist wichtig. DeepSeek macht den Harness bei Coding-Benchmarks sichtbar. ProjectBench macht den Projektkontext und das reale PM-System sichtbar. Beide Ansätze verschieben die Frage von „Welches Modell ist das beste?" zu „Welches Modell-Harness-System erzeugt unter diesen Bedingungen den größten Wert?"

Claude Code und Codex als optionale Produktruntimes

DeepSeek Harness kann Claude Code und Codex als Subagenten einbinden. Technisch geschieht das nicht durch einen losen Aufruf eines bereits installierten Host-Programms. Die optionalen Provider-Bundles bringen jeweils eine private, fest gepinnte Produktruntime mit.

Das Claude-Bundle hängt am offiziellen @anthropic-ai/claude-agent-sdk und dessen nativen Plattformpaketen. Der SDK wählt das mitgelieferte Claude-Code-Binary aus. Es gibt keinen Fallback auf ein claude im normalen PATH. Das Codex-Bundle hängt am offiziellen @openai/codex-Paket und startet dessen fest gepinnten Wrapper samt Plattformpayload. Auch hier wird nicht auf ein vorhandenes Host-codex zurückgegriffen.

Wichtig ist die Installationsgrenze. Die normale @deepseek-ai/dsh-Installation enthält weder Provider noch Produktruntime. Erst wenn ein Nutzer eines der optionalen Profile-Bundles installiert, wird das zugehörige Binary-Payload geladen. Das Bundle registriert danach einen zunächst ruhenden Provider. Claude Code oder Codex startet erst bei der ersten tatsächlichen Delegation.

Bei Codex ist die Lizenzlage vergleichsweise klar, weil das offizielle Paket unter Apache 2.0 steht. Beim Claude Agent SDK und den nativen Claude-Code-Payloads gelten keine einfachen MIT-Bedingungen, sondern Anthropics Commercial beziehungsweise Consumer Terms und die jeweilige Paketlizenz. Anthropic erlaubt ausdrücklich, Claude Code unverändert in einem Produkt vorzuinstallieren oder dort auszuführen. Dabei dürfen Authentifizierungsmethoden nicht entfernt oder eingeschränkt werden. Jeder Endnutzer muss mit eigenen Anthropic-, Cloud- oder API-Zugangsdaten arbeiten und direkt unter dem eigenen Vertrag abgerechnet werden. Auch das Branding darf keine Partnerschaft oder Unterstützung durch Anthropic suggerieren.

DeepSeek Harness dokumentiert diese Trennung in den Third-Party Notices und führt die Claude-Code-Plattformpakete samt Version und Lizenzfeld auf. Die Notices erklären außerdem, dass die Projektverantwortlichen die Distribution der offiziellen Payloads autorisieren. Das ist eine Compliance-Erklärung des Projekts, aber kein unabhängiger Nachweis über eine individuell ausgehandelte Lizenz mit Anthropic.

Damit ist die Einbindung nicht automatisch ein Rechtsverstoß. Sie erzeugt aber eine laufende Compliance-Pflicht. DeepSeek muss bei jedem Update prüfen, ob Binary, Wrapper, Paketbedingungen, Authentifizierung, Markenverwendung und Lizenzhinweise weiterhin zusammenpassen. Für Unternehmen, die DeepSeek Harness weiterverteilen oder als Managed Service anbieten, gehört diese Prüfung vor den produktiven Einsatz. Das ist keine Rechtsberatung, sondern ein klarer Due-Diligence-Punkt.

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.

Pi läuft standardmäßig als Terminalprozess im aktuellen Projektverzeichnis. Für Dauerläufe verweist das Projekt bewusst auf tmux statt auf einen eingebauten Hintergrunddienst. Über RPC und SDK kann Pi aber in andere Anwendungen oder eigene Daemons eingebettet werden.

DeepSeek Harness startet standardmäßig eine lokale Weboberfläche. Vor dem ersten Task muss der Nutzer einen Workspace auswählen. Scheduling ist als Plugin-Fähigkeit vorgesehen, doch dsh ist im Kern eine lokale Agentenlaufzeit und kein fertig gehosteter 24/7-Messenger-Dienst.

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: fünf unterschiedliche Sicherheitsmodelle

Kurz gesagt: TensorPM begrenzt den Aktionsraum im Produkt. Hermes liefert Freigaben und Container-Backends. OpenClaw vertraut im Default stark auf den Operator. Pi überlässt Permission Gates und Sandboxing bewusst Extensions oder Containern. DeepSeek Harness bringt Approval Policies und Sandboxes als Plugins mit, empfiehlt für reale Nutzung aber zusätzlich eine dedizierte VM oder einen Container.

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.

Pi hat im Kern keine Permission Popups. Das ist keine vergessene Funktion, sondern Teil der Philosophie. Nutzer sollen den passenden Schutz selbst über Extensions, Pfadschutz, Gondolin, Docker, OpenShell oder eine andere Containergrenze wählen. Pi bleibt dadurch klein und flexibel. Die Verantwortung, ob der Agent auf dem Host, in einem Projektcontainer oder hinter eigenen Freigaberegeln läuft, liegt aber beim Betreiber.

DeepSeek Harness kann Dateien bearbeiten, Shell-Befehle ausführen, Subagenten delegieren und über Plugins weitere Systeme anbinden. Die Weboberfläche fragt bei Aktionen nach, die unter der aktiven Permission Policy eine Freigabe benötigen. DeepSeek empfiehlt trotzdem eine dedizierte VM oder einen Container, kleine isolierte Arbeitspakete, menschliche Zustimmung bei erheblichen Folgen und ausschließlich geprüfte Plugins, Skills, Hooks und MCP-Server. Die vollständige Event-Spur erhöht die Nachvollziehbarkeit, ersetzt aber keine Isolation.

Praktisch heißt das: Bei TensorPM ist der Aktionsradius enger in die Produktarchitektur eingebaut. Bei OpenClaw, Hermes, Pi und DeepSeek Harness prägt der Betreiber die reale Sicherheitsgrenze stärker durch Gateway, Plugins, Zugangsdaten, Freigaben und Betriebssystem-Isolation. Für routinierte Plattformteams ist das beherrschbar. In regulierten Branchen wird es zu einem eigenen Architekturthema.

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

Kurz gesagt: Bei den selbst betriebenen Harnesses hängt Datenschutz nicht nur vom lokalen Prozess ab, sondern auch vom gewählten Modell, den Plugins und verbundenen Diensten. Pi und DeepSeek Harness können lokal laufen, doch externe Provider sehen weiterhin die Daten, die an sie gesendet werden. TensorPM koppelt die Datenhoheit zusätzlich an einen projektbezogenen, bestätigten Kontext.

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 breiter operativer Ausführung und einem bewusst begrenzten, projektgebundenen Kontext 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.

Pi speichert seine Session-Historie lokal als Baum und kann lokale oder selbst gehostete Modelle ansprechen. Seine Multi-Provider-Architektur bedeutet zugleich, dass die Datenschutzbedingungen des jeweils ausgewählten Providers gelten. Long-Term-Memory, RAG und externe Werkzeuge kommen über Extensions und bringen ihre eigenen Datenflüsse mit.

DeepSeek Harness speichert laut eigener Data Processing Statement Eingaben, Modellantworten, Tool-Aufrufe, Pfade und Laufzeitlogs standardmäßig lokal. Telemetrie lässt sich deaktivieren oder umleiten. Sobald ein externer Modellanbieter, ein Web-Tool, MCP oder Plugin aktiviert wird, kann dieser Dienst Daten übertragen. Local-first beschreibt also den Harness, nicht automatisch die gesamte Verarbeitungskette.

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 dauerhaft Teil des Projektgedächtnisses und wer darf sie verändern? OpenClaw, Hermes, Pi und DeepSeek Harness optimieren unterschiedliche Formen der Ausführung. TensorPM ist darauf ausgelegt, nur bestätigte, projektrelevante Informationen in den gemeinsamen Graphen zu übernehmen. Auch dort bleiben Modellwahl, Konnektoren und Endpoint-Sicherheit relevant. Projektinhalt, Freigabe und Datenminimierung sind jedoch enger gekoppelt.

Direkter Vergleich

Rolle im Projekt

System	Primärer Bezugsrahmen	Was es besonders gut kann	Was für Projektsteuerung fehlt
TensorPM	Projekt und Projektintention	Kontext, Analyse, Guidance, Governance, PM-Oberfläche	Kein permanenter 24/7-Cloud-Daemon
OpenClaw	Nutzer, Workspace und Kanäle	Messenger, Integrationen, dauerhafte Allzweck-Automation	Kein methodischer Projektgraph
Hermes Agent	Session und Workflow	Wiederkehrende Tasks, selbstlernende Skills, Kanban	Kein vollwertiges Modell für Ziele, Budget und Risiken
Pi	Terminalsession und Codebasis	Minimaler, anpassbarer Multi-Model-Harness	PM-Kontext und Governance müssen ergänzt werden
DeepSeek Harness	Workspace und Agentenlaufzeit	Plugin-Laufzeit, Subagenten, Modi, Event-Replay	PM-Modell und Produktionsreife fehlen

Architektur und Betrieb

System	Standardoberfläche	Erweiterungsmodell	Sicherheitsgrenze	Lizenz / Reife
TensorPM	Desktop-PM-App	Skills, MCP, A2A, Konnektoren	Produktgrenzen, Freigaben, projektbezogene Sichtbarkeit	Proprietär, produktiv
OpenClaw	Messenger und Gateway	Community-Skills und Integrationen	Betreiber härtet Host, Credentials und Skills	MIT, produktiv einsetzbar
Hermes Agent	CLI, Messenger, Dashboard	Skills, Plugins, Container-Backends	Approval-System und gewähltes Terminal-Backend	Open Source
Pi	Terminal	Extensions, Skills, Pakete, RPC, SDK	Vom Betreiber gewählte Extensions und Container	MIT
DeepSeek Harness	Lokale Weboberfläche	Alles als Cordis-Plugin	Permission Policy, Plugins, VM oder Container empfohlen	MIT, Developer Preview

Wann welcher Agent?

Kurz gesagt: OpenClaw passt zu kanalübergreifender 24/7-Automation. Hermes passt zu wiederkehrenden Workflows mit selbstlernenden Skills. Pi passt zu einem kleinen, selbst gestalteten Terminal-Harness. DeepSeek Harness passt zu Plattformteams, die eine Plugin-Laufzeit zusammensetzen wollen. TensorPM passt zur methodischen Steuerung eines übergeordneten Projekts.

OpenClaw und Hermes optimieren Aufgabenerledigung. Pi und DeepSeek Harness optimieren die technische Laufzeit, in der ein Modell solche Aufgaben bearbeitet. TensorPM optimiert Projektsteuerung: welche Arbeit ist relevant, in welcher Reihenfolge, mit welchem Risiko und unter wessen Verantwortung.

Sieben 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 einen transparenten Terminal-Agenten, dessen Workflow und Modellwahl wir selbst kontrollieren." Pi. Der kleine Kern, die baumförmige Historie und Extensions passen zu Teams, die ihren Harness selbst formen wollen. Sandboxing, MCP, Subagenten und Permission Gates müssen sie aber bewusst ergänzen.

„Wir bauen eine interne Agentenplattform mit austauschbaren Tools, Sandboxes, Modellen, Subagenten und eigener UI." DeepSeek Harness. Cordis und die Plugin-Seams sind genau für diese Komposition gedacht. Wegen Developer Preview, Breaking Changes, lokaler Codeausführung und optional gebündelter Fremdruntimes braucht der produktive Einsatz eine eigene Security-, Lizenz- und Upgrade-Governance.

„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. Pi bringt kein MCP im Kern mit, kann aber über eine Extension, ein CLI-Werkzeug oder sein SDK angebunden werden. DeepSeek Harness kann eine solche Verbindung als Plugin oder MCP-Integration zusammensetzen. Für Pi und DeepSeek Harness ist das aktuell Integrationsarbeit, keine fertige TensorPM-Delegation.

In einer solchen Architektur hält TensorPM den bestätigten Projektkontext. OpenClaw und Hermes organisieren Kanäle und wiederkehrende Abläufe. Pi oder DeepSeek Harness können spezialisierte technische Arbeit ausführen. Kein einzelnes System muss alle Rollen übernehmen.

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, Hermes, Pi und DeepSeek Harness hängt davon ab, welche Ebene fehlt.

Wer Aufgabenerledigung über viele Kanäle sucht, ist bei OpenClaw. Wer wiederkehrende Abläufe mit selbstlernenden Skills will, schaut auf Hermes. Wer einen kleinen und selbst kontrollierten Terminal-Harness möchte, prüft Pi. Wer eine vollständige, pluginbasierte Agentenplattform bauen will und eine Developer Preview tragen kann, prüft DeepSeek Harness.

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. Kontextänderungen bleiben freigabepflichtig; ausführende Werkzeuge arbeiten innerhalb definierter Berechtigungen und ihre Aktionen bleiben nachvollziehbar.

In vielen Projektorganisationen wird die produktive Antwort eine Kombination sein: TensorPM als Kontext- und Steuerungsschicht, OpenClaw oder Hermes für Kanäle und wiederkehrende Workflows, Pi oder DeepSeek Harness für spezialisierte technische Ausführung. Die Schnittstellen sind nicht in jeder Kombination fertig vorhanden. Die Schichten lassen sich aber sauber trennen.

Wer den Unterschied an einem echten Projekt testen möchte: TensorPM ist als Desktop-App für Windows, macOS und Linux verfügbar. Der zeitlich unbegrenzte Trial enthält Cloud Sync und 2.000.000 Lifetime-Credits; alternativ kann die App lokal ohne Account und mit lokalen Modellen betrieben werden. BYOK/API-Key-Verwaltung ist Teil von Business.