Einen PM-Agenten mit Claude API und persistentem Speicher bauen

Mai 2026 · 11 Min. Lesezeit · Fran Olivares, Gründer von OlivaresAI

Ein Projektmanagement-Agent, gebaut auf der Claude API und Alma persistentem Speicher, verfolgt Stakeholder, Entscheidungen, SLAs und Standup-Notizen über Tage und Wochen hinweg, ohne den Kontext zu verlieren. Die Architektur hat vier Teile: eine Claude-Konversationsschleife, einen Speicher, indexiert nach Projekt-Entität, einen Extraktor, der strukturierte Datensätze aus jedem Chat zieht, und einen Kontext-Assembler, der den richtigen Ausschnitt in jeden Prompt einspeist. Persistenter Speicher ist es, was Claude von einem klugen Entwurfstool in einen Agenten verwandelt, der sich daran erinnert, was das Team letzten Dienstag entschieden hat.

Projektmanagement ist überwiegend Gedächtnisarbeit. Wer besitzt diesen Stream? Worauf haben wir uns bezüglich des Migrationsfensters geeinigt? Warum haben wir den Rate Limiter aus dem Scope genommen? Wann blockiert die Rechtsprüfung das Release? Ein Agent, der diese Fragen jeden Morgen neu stellen muss, ist kein Agent — er ist ein etwas schnellerer Praktikant. Sie ändern das, indem Sie dem Modell eine persistente Speicherschicht geben, die es zwischen Zügen lesen und beschreiben kann, automatisch aus der Konversation befüllt. Dieser Leitfaden führt durch die Referenzarchitektur und den Integrationscode, mit der Anthropic Claude API als LLM und Almas REST API als Speicherschicht.

Warum braucht ein PM-Agent speziell persistenten Speicher?

Drei strukturelle Gründe. Erstens sind die Entitäten, die ein PM verfolgt (Personen, Entscheidungen, Liefergegenstände, SLAs, Risiken), selbst langlebig — sie überdauern per Definition jede einzelne Konversation. Zweitens ist der Konversationsstil hochfrequent und gering an Aufwand: kurze Standup-Nachrichten, schnelle Klärungen, „Was haben wir zu X gesagt?"-Fragen. Den richtigen Kontext-Ausschnitt günstig zu laden ist wichtig. Drittens sind die Kosten des Vergessens hoch: eine übersehene Entscheidung wird zu einem verpassten Release, eine vergessene Abhängigkeit zu einem Blocker.

Eine zustandslose Claude-Konversation bewältigt eine einzelne Planungssitzung gut. Sobald der Nutzer Kontinuität möchte („gestern haben wir uns geeinigt…", „Was blockiert das Auth-Team diese Woche?"), muss die Konversation entweder die volle Historie in das Kontextfenster wiedergeben (teuer, irgendwann unmöglich) oder sich auf eine Speicherschicht außerhalb des Modells verlassen.

Wie sieht die Referenzarchitektur aus?

Vier bewegliche Teile:

Wie strukturiere ich Speicher-Kategorien für einen PM-Agenten?

Fünf Kategorien decken die meisten Teams ab: stakeholder (Personen mit Rolle + Verantwortlichkeiten), decision (was wann von wem mit welcher Begründung vereinbart wurde), sla (Zusagen an andere Teams oder Kunden), risk (offene Probleme mit Owner + Mitigation), milestone (Zieltermin + Scope + Status). Jede Erinnerung trägt einen Wichtigkeits-Score, sodass der Assembler hochwichtige Einträge im Retrieval priorisieren kann.

Die Kategorie dient nicht nur der Organisation — sie ist Teil des Retrieval-Signals. Wenn der Nutzer fragt „Was haben wir entschieden?", gewichtet der Assembler Decision-Kategorie-Erinnerungen höher. Wenn er fragt „Wer ist blockiert?", werden Risk-Kategorie-Erinnerungen hochgereiht. Die Alma-Kontext-Assemblierung stellt pro Kategorie Boost-Gewichte genau für diesen Anwendungsfall bereit.

Wie sieht die Integrationsschleife in echtem Code aus?

Drei Phasen pro Nutzernachricht. Der Pseudo-Code unten verwendet Node.js mit dem Alma SDK und dem Anthropic SDK, aber dieselbe Form funktioniert in Python oder einem anderen Stack:

Phase 3 läuft im Hintergrund — der Nutzer sieht die gestreamte Antwort sofort, und die Extraktion geschieht in den nächsten ~1 s ohne Blockierung. Neue Erinnerungen werden dedupliziert, Widersprüche gegen bestehende Einträge erkannt, und der Speicher bleibt automatisch sauber. Vollständige SDK-Referenz: @olivaresai/alma-sdk; HTTP-Äquivalente in der REST-API-Dokumentation.

Wie handhabt der Agent Multi-Projekt-Isolation?

Nutzen Sie Alma-Environments: ein Environment pro Projekt. Jedes Environment hat seine eigenen Memories, Episodes, Procedures und Soul-Blöcke, vollständig isoliert von den anderen. Der Agent übergibt environmentId bei jedem Memory-Aufruf; die API erzwingt die Grenze. Projekt-übergreifende Anfragen sind ohne einen expliziten Environment-Wechsel schlicht nicht möglich — was der richtige Default für ein PM-Tool ist, in dem das Auslaufen von Entscheidungen aus Projekt A in Projekt B ein reales Problem ist.

Für teamweite PM-Agenten (mehrere Menschen interagieren mit demselben Agenten) nutzen Sie die Alma-teams-Ressource: Jedes Team hat geteilte Erinnerungen, die für alle Mitglieder sichtbar sind, plus benutzerspezifische Erinnerungen für persönliche Präferenzen. Rollenbasierter Zugriff kontrolliert, wer was schreiben kann.

Wie sieht ein täglicher Standup-Zug end-to-end aus?

Nutzernachricht: „Standup: Backend-Team, Maria entblockt heute die Migration, José ist am Rate Limiter; wir haben entschieden, das GA-Release auf Freitag zu verschieben, weil die Rechtsabteilung das DPA noch prüft". Der Ablauf des Agenten:

Gängige Workflows zum Mitdenken

Entscheidungs-Archäologie. „Warum haben wir den Rate Limiter aus dem Scope genommen?" — der Agent ruft die Entscheidungs-Erinnerung plus die umgebende Episode und die referenzierte Risiko-Erinnerung ab. Liefert die Antwort mit Zitaten auf die Einträge, sodass der Nutzer bei Bedarf in die Konversation eintauchen kann.

Stakeholder-Lookup. „Wer besitzt die Migration?" — direkte Memory-Anfrage gegen die stakeholder-Kategorie, liefert den Eintrag. Falls die Antwort veraltet ist (die Rolle hat sich letzte Woche geändert), erkennt die Widerspruchserkennung dies in der nächsten Konversation, die den neuen Owner erwähnt.

Wiederkehrende Reportgenerierung. „Erzeuge einen Statusbericht für den Auth-Stream diese Woche" — der Agent assembliert ein Kontextfenster aus Episodes, Entscheidungen und Risiken, die für diesen Stream getaggt sind, und entwirft den Bericht dann aus dieser kuratierten Auswahl. Das ist deutlich günstiger und genauer, als Claude zu bitten, rohe Chat-Historie zusammenzufassen.

Wie halte ich den System-Prompt klein und bleibe dennoch fundiert?

Standard-Token-Budgets im Assembler: ~2 K Tokens für Memories, ~1 K für Episodes, ~500 für Procedures, ~500 für Soul-Blöcke. Insgesamt ~4 K — gut unter dem Kontextbudget jedes Modells, und die Cache-Treffer amortisieren sich über die Konversation. Wenn Ihr Projekt klein ist (<100 aktive Erinnerungen), können Sie das Budget weiter senken. Wenn es groß ist (10 K+ Erinnerungen), bleibt der Assembler bei ~4 K, weil das Retrieval die Anzahl der einbezogenen Einträge auch dann begrenzt, wenn der Speicher groß ist.

Zwei Dinge sind operativ wichtig: Die Soul-Blöcke (die Identität des Agenten) sollten als stabiles System-Prompt-Präfix gecacht werden, damit wiederholte Aufrufe die Input-Tokens nicht erneut bezahlen; und der dynamische Kontext (Memories + Episodes) sollte nach dem Cache-Breakpoint sitzen, damit jeder Aufruf nur den geänderten Teil neu hochlädt. Anthropics Prompt-Caching-Dokumentation behandelt die Platzierung des Breakpoints.

Was kostet das in der Praxis?

In einem typischen PM-Team-Flow (~20 Nachrichten/Tag pro Nutzer, überwiegend Standups + Klärungen) werden die Grenzkosten von den LLM-Aufrufen selbst dominiert. Die Speicherschicht ergänzt: einen Assemble-Aufruf (ein paar KB Read + Retrieval, ~30 ms), einen Extract-Aufruf (Haiku, ~$0,001 pro Zug). Gesamter Memory-Overhead pro Tag pro aktivem Nutzer: weit unter einem Cent. Vergleichen Sie das mit dem Wert, dass das PM-Team keine Entscheidungen verliert — und die Rechnung ist offensichtlich.

Wie fange ich mit dem Prototyping an?

Almas Starter-Tarif ($14/Monat) ist die Einstiegsstufe und enthält die persistente Speicherschicht. Registrieren Sie sich unter alma.olivares.ai, generieren Sie einen API-Schlüssel in den Einstellungen und klonen Sie den SDK-Starter von der Entwickler-Seite. Verkabeln Sie die Drei-Phasen-Schleife in Ihrem Agenten-Code, richten Sie ihn auf ein einzelnes Testprojekt aus und lassen Sie ihn eine Woche laufen. Der Speicher wird sich aus den Konversationen natürlich befüllen; Sie werden sehen, wie Entscheidungen, Stakeholder und Risiken sich ohne manuelle Dateneingabe ansammeln. Von dort ist es nur noch ein Aufdrehen der Kategorien und ein Tuning des Assemblers.

Verwandte Lektüre: Persistenter Speicher für KI: Vollständiger Leitfaden 2026 · Wie man KI persistenten Speicher gibt · Dreistufige Speicherarchitektur · Kontext-Assemblierungs-Dokumentation · Environments.

See plans