Was ist AWR

AWR ist eine Open-Source-Plattform für Projektlieferung für Menschen und KI. Sie verbindet Ziele, Workstreams, Abhängigkeiten, Kontext und Abnahme zu einem einzigen Projektlieferungs-Workflow, sodass ein Projekt von einem vereinbarten Ziel bis zu einer verifizierten Lieferung gelangen kann — selbst wenn die Arbeit auf mehrere Agents, Sessions und Mitarbeitende verteilt ist.

AWR ist für zwei Situationen gebaut, die dasselbe zugrunde liegende Problem teilen:

Eine Person, die mehrere Agents koordiniert an einem komplexen Projekt.
Ein Team, das ein gemeinsames Projekt liefert, beginnend mit komplexen Softwareprojekten.

In beiden Fällen geben Menschen die Richtung vor und prüfen die Ergebnisse; Agents erledigen die Arbeit. AWR verbindet ihre Arbeit über seine CLI und seinen MCP-Dienst mit demselben Projektstatus.

Das Problem, das AWR löst

Wenn du mit KI-Coding-Agents arbeitest, lebt das Wissen über das Projekt meist in der privaten Konversation des Agents. Wenn die Session endet, das Modell wechselt oder eine andere Person oder ein anderer Agent die Arbeit übernimmt, ist dieser Kontext weg. Parallele Arbeiten driften auseinander, und „fertig" bedeutet, was auch immer der letzte Agent behauptet hat.

AWR ist um das herum konzipiert, was stattdessen gelten sollte:

Der Wechsel von Sessions, Modellen oder Mitarbeitenden bewahrt das Projekt. Ziele, Einschränkungen und verifizierter Fortschritt überleben die Übergabe. Ein Nachfolger erhält den erforderlichen Kontext der aktuellen Aufgabe und ihren Checkpoint, sodass das Projekt über Sessions und Agents hinweg fortgesetzt werden kann.
Parallele Arbeit hat klare Zuständigkeit und Übergaben. Unabhängige Workstreams (zum Beispiel Frontend, Backend und Testing) behalten ihre eigenen Aufgaben, ihren Kontext und ihre Zuständigkeit, während sie Projekt-Einschränkungen teilen.
„Fertig" ist verifizierbar. Abschlussmeldungen sind mit versionsgebundenen Nachweisen verbunden. Implementierung, Verifizierung, Merge und Release werden als getrennte Fakten verfolgt, nicht zu einer einzigen Behauptung zusammengefasst.
Der Aufwand ist sichtbar. In jeder Phase kannst du erkennen, was bereit ist, was wartet, was verifiziert wurde und wohin der Aufwand geflossen ist.

Kurz gesagt: AWR bewahrt Projektkontinuität über endliche Kontextfenster hinweg. Das Kontextfenster eines Agents ist begrenzt, und Kompaktierung (wenn ein Host die Konversation kürzt, damit sie passt) ist Aufgabe des Hosts — die Checkpoints von AWR tragen stattdessen die aufgezeichneten Projektfakten weiter.

So funktioniert es: Deine Dateien bleiben die maßgebliche Quelle

Die Architektur von AWR hat drei Teile:

Deine Dateien enthalten die Absicht. Markdown- und YAML-Dateien in deinem Projekt beschreiben Ziele, Pläne, Arbeit, Einschränkungen und Entscheidungen. AWR indiziert diese Quellen, ohne sie stillschweigend zu ersetzen.
AWR hält die Kontinuität aufrecht. Ein lokaler Zustand (ein SQLite-Projekt) enthält Projektionen dieser Quellen sowie Sessions, Claims, Checkpoints und Nachweise. Die Kontextkompilierung — das Zusammenstellen der relevanten Ziele, Regeln, Abhängigkeiten und Nachweise für die aktuelle Aufgabe — läuft lokal und macht keine Modellaufrufe. Revisionsprüfungen schützen Schreibvorgänge vor veraltetem Zustand.
Menschen und Agents erledigen die Arbeit. Die CLI und der MCP-Dienst verbinden Projektfakten mit dem Host, den du verwendest. Agents bringen ihre eigenen Modelle, Werkzeuge und Konversationen mit; geprüfte Änderungen und Fortschritt fließen in die Projektquellen zurück.

Weil aufgezeichnete Checkpoints nur aufgezeichnete Fakten tragen, rekonstruieren sie nicht den nicht aufgezeichneten Konversationsverlauf eines Agents — das bleibt Aufgabe des Hosts.

Die Bestandteile und wie sie zusammenwirken

Du arbeitest mit AWR über zwei Einstiegspunkte, beide aus demselben Paket installiert:

Die awr CLI — initialisiert ein Projekt, zeigt den Status und steuert den expliziten Session-Workflow: eine Arbeit claimen, ihren fokussierten Kontext abrufen und vor dem Anhalten einen Checkpoint speichern. Jeder Agent, der Shell-Befehle ausführen kann, kann sie nutzen.
Der awr-mcp MCP-Dienst — stellt denselben Projektstatus als MCP-Tools bereit (MCP, das Model Context Protocol, ist die Art, wie KI-Clients externe Tools aufrufen). Ein Client verbindet sich entweder über stdio mit einem einzelnen Projekt oder mit einem gemeinsam genutzten HTTP-MCP-Dienst, der mehrere Clients und Projekte bedient.

Darauf aufbauend unterstützt AWR den Agent, mit dem du bereits arbeitest. Integrationen gibt es in Schichten:

Generischer Vertrag (Standard, vollständig unterstützt). Jeder Host, der eine CLI ausführen oder MCP sprechen kann, nutzt denselben Projektstatus über den gemeinsamen Session-Workflow. Dazu gehören Claude Code, Cursor, Windsurf und ähnliche Hosts — kein spezielles Installationsprogramm nötig.
Host-Hinweise. Für einige Hosts (Cursor, Kimi Code, Grok Build) dokumentiert AWR die exakten Pfade zum Zusammenführen der Konfiguration und die nativen Session-Flags, geprüft gegen eine datierte Host-Version. Diese Hinweise fügen keine Laufzeitfunktionen hinzu.
Optionaler Lebenszyklus-Adapter. Wo die nativen Lebenszyklus-Hooks eines Hosts stabil sind, kann ein Adapter AWR-Checkpoints aus Host-Ereignissen auslösen. Heute existiert das für Codex. Ein Adapter macht AWR niemals zur Laufzeit dieses Hosts.

Für eine Person, die mehrere Agents koordiniert, gilt dieselbe Disziplin bei Abhängigkeiten, Reviews und Abrechnung wie für ein größeres Team — es ist ein Projektmodell, nicht zwei Produkte.

Was AWR NICHT ist

AWR ist bewusst begrenzt. Es ist eine host-unabhängige Arbeitslaufzeit, und seine Produktgrenze ist der gemeinsame CLI/MCP-Vertrag — nicht ein bestimmter Editor oder Agent.

AWR ist kein KI-Agent. Es wählt keinen Coding-Agent aus, startet oder konfiguriert ihn nicht. Agents bringen ihre eigenen Modelle, Werkzeuge und Konversationen mit; die von AWR gespeicherten Provider- und Modell-Strings sind nur Anzeigelabels.
AWR ist kein Editor, keine Chat-UI und kein Modellanbieter. Die UI des Agents, native Konversations-IDs und die Kompaktierung gehören zum Host.
AWR ersetzt nicht deine Projektdateien. Markdown-/YAML-Quellen bleiben maßgeblich; der lokale Zustand von AWR ist ein Index plus Kontinuitätsaufzeichnungen und darf deine Quellen niemals stillschweigend ersetzen.
AWR ist nicht an einen Transport gebunden. Ob MCP über stdio oder HTTP läuft oder fehlt, ist die Entscheidung des Hosts; wenn ein Host keine nativen Hooks hat, speicherst du Checkpoints manuell über die CLI.
AWR isoliert Workstreams nicht physisch. Die Workstream-Isolierung deckt den Projektstatus und unterstützte Operationen ab; physische Prozessisolation hängt vom Ausführungshost ab.

Aktueller Umfang: Veröffentlichtes Release vs. Entwicklung

AWR ist ehrlich darüber, was ausgeliefert wird und was gebaut wird. Die veröffentlichten 0.5.1 CLI/MCP-Pakete bieten:

Quellengestützte Ziele und Aufgaben mit Abhängigkeitsnavigation
Fokussierte Kontextkompilierung für die aktuelle Aufgabe
Session-Claims und Checkpoints
Versionsgebundene Nachweise
Einen gemeinsamen HTTP-MCP-Dienst für mehrere Clients und Projekte
Dateiaustausch im Personal Workspace
Eine Grundlage für persönliche Workstreams: explizite Quellen-Zuständigkeit, Session-Zuordnung und eingegrenzter Kontext in einem lokalen SQLite-Projekt

Dieses Release bietet keinen authentifizierten Team-Dienst und keine vollständige Multi-Client-Isolierung. Noch in Entwicklung auf main:

Versionierte workstream-übergreifende Übernahme von Lieferungen (Downstream-Arbeit an ein abgenommenes Artefakt und eine Vertragsversion binden; Konsumenten bei Änderungen erneut prüfen)
Team-Zusammenarbeit und Lieferungs-Review (explizite Reviewer- und Genehmigungsaufzeichnungen)
Workstream-Nutzungs-, Zeit- und ETA-Abrechnung

Die Release-Notes jeder veröffentlichten Version definieren die tatsächliche Paketgrenze.

Was das für dich bedeutet

Wenn du AWR evaluierst: Du behältst deinen aktuellen Agent und deine aktuellen Dateien. Du initialisierst AWR in deinem Projekt, gibst deinem Agent eine Arbeitsvereinbarung, und von da an beginnt jede Session aus aufgezeichneten Zielen, Regeln, Abhängigkeiten und Checkpoints statt von null. Du kannst den Fortschritt jederzeit einsehen.

Wenn du es in einem Team einführst: Dieselbe CLI/MCP-Grundlage wächst in Richtung gemeinsamer Lieferung und Review, sobald diese Fähigkeiten ausgeliefert werden — das veröffentlichte Release gibt dir bereits den Single-User- und Multi-Agent-Kern.

Wie es weitergeht

Schnellstart — installiere AWR, verbinde ein Projekt und führe deine erste Session aus.
Konzepte — das Projektmodell im Detail: Ziele, Workstreams, Sessions, Claims, Checkpoints und Nachweise.
CLI und MCP-Dienst — die zwei Einstiegspunkte in der Tiefe.
Agent-Integrationen — verbinde den Agent, den du bereits nutzt.