muench.dev Articles

magento.watch MCP: Magento- und Adobe-Commerce-Wissen direkt abfragen

2026-10-06T11:00:00+00:00

Mit dem magento.watch MCP lassen sich wichtige Informationen rund um Magento Open Source und Adobe Commerce direkt aus einem KI-Assistenten abfragen. Ich nutze den MCP schon länger, vor allem um Abhängigkeiten zu prüfen. Praktisch ist auch die Möglichkeit, schnell zu kontrollieren, ob ein Shop die offiziellen Patches verwendet.

MCP ohne Zugangsdaten einbinden

Der MCP ist unter magento.watch/mcp dokumentiert. Für Claude lässt er sich beispielsweise so hinzufügen:

claude mcp add magento-watch --transport http https://magento.watch/mcp/api

In VSCode / CoPilot geht das z.B. so per Konfiguration:

{
  "servers": {
    "magento-watch": {
      "type": "http",
      "url": "https://magento.watch/mcp/api"
    }
  }
}

Dafür sind weder Passwort noch Token erforderlich. Das macht den Einstieg unkompliziert: Nach dem Hinzufügen kann Claude die bereitgestellten Werkzeuge verwenden, um konkrete Fragen zu Releases, Support-Zeiträumen, Abhängigkeiten, Security Bulletins und Patches zu beantworten.

Und hier seht ihr den MCP in Aktion:

Release- und Abhängigkeitsinformationen

Für den Überblick über Versionen gibt es unter anderem get_all_versions, get_supported_versions und get_eol_versions. Damit lassen sich alle erfassten Versionen einer Distribution, aktuell unterstützte Releases und Versionen mit erreichtem End-of-Life abfragen. get_version liefert Details zu einer einzelnen Version, einschließlich Lifecycle und Systemanforderungen. Wer nur die jüngste stabile Version benötigt, kann get_latest_version verwenden.

Bei Upgrade- und Wartungsarbeiten ist check_compatibility besonders nützlich. Das Werkzeug prüft, ob eine bestimmte PHP-, MySQL- oder andere Abhängigkeitsversion mit einem Release kompatibel ist. So kann ich Anforderungen gezielt gegen die eingesetzte Shop-Version abgleichen, statt Informationen aus mehreren Dokumentationsseiten manuell zusammenzutragen.

Security Bulletins und Schwachstellen

Auch Sicherheitsinformationen sind über eigene Werkzeuge erreichbar. get_security_bulletins listet Adobe- und Magento-Security-Bulletins, optional gefiltert nach Schweregrad oder Veröffentlichungsdatum. Mit get_security_bulletin lassen sich ein konkretes Bulletin, dessen CVEs, Schweregrad und die Releases mit enthaltenem Fix abrufen.

Für eine konkrete Shop-Version gibt es check_version_security. Damit kann geprüft werden, ob bekannte Bulletins die Version betreffen und welche Version den Fix enthält. Das ist hilfreich, um eine Patch-Frage konkreter zu beantworten: Ist die installierte Version betroffen, und auf welches Release sollte aktualisiert werden?

Quality Patches prüfen

Für Quality Patches bietet find_patch eine Liste der auf eine Magento-Version anwendbaren Patches. Die Suche kann außerdem nach einem beschriebenen Fehler priorisieren. get_patch liefert Details zu einem einzelnen Patch, beispielsweise Varianten, Einschränkungen, geänderte Dateien und Dokumentation.

Damit lässt sich auch praktisch prüfen, welche offiziellen Patches für einen Shop relevant sind und ob sie bereits berücksichtigt wurden. Das ist eine sinnvolle Ergänzung zu Release- und Security-Abfragen, gerade bei der laufenden Wartung einer Installation.

REST API und n98-magerun2

Neben dem MCP stellt magento.watch auch eine REST API bereit. Diese API wird in der nächsten Version von n98-magerun2 in einem Kommando zur Prüfung der Datenbank-Kompatibilität zum Einsatz kommen. So stehen die Informationen nicht nur KI-Assistenten zur Verfügung, sondern können auch direkt in bestehende Kommandozeilen-Workflows einfließen.

Ein Community-Projekt mit praktischem Nutzen

magento.watch wird von Łukasz Bajsarowicz entwickelt. Er hat bereits viele wertvolle Beiträge für die Magento-Community geleistet und ist Core Contributor. Ich schätze seine Arbeit sehr.

Für mich ist magento.watch ein überzeugendes Projekt, weil es Release-, Kompatibilitäts-, Sicherheits- und Patch-Informationen über eine klare Schnittstelle zugänglich macht. Der MCP spart beim Prüfen von Abhängigkeiten Zeit und hilft, gezielte Fragen zum Zustand eines Shops zu beantworten. Wer Claude nutzt, kann die Anbindung mit einem einzelnen Kommando ausprobieren, ganz ohne Passwort oder Token.

herdr: Terminal-Multiplexer für Server und AI-Agenten

2026-10-05T09:00:00+00:00

Ein Terminal-Multiplexer ist für mich ein Werkzeug, um mehrere Arbeitskontexte parallel im Blick zu behalten. Das können lokale Shells sein, SSH-Verbindungen zu Servern oder Sessions mit Coding-Agenten.

Dafür nutze ich herdr. Es lässt sich als normaler Terminal-Multiplexer verwenden und unterstützt verschiedene Coding-Agenten out-of-the-box. Dazu kommen persistente Sessions und die Möglichkeit, Remote-Maschinen per SSH anzubinden. So kann ich in einem Werkzeug mehrere Terminals und Agent-Sessions parallel organisieren.

Auch wenn es sich um ein CLI Tool handelt ist es wichtig zu wissen, dass man alles auch per Maus bedienen kann. Es lassen sich alle Panes per Drag&Drop verschieben, genauso wie Tabs. Auch Menüs kann man per Klick mit der Maus öffnen.
Über die Tastatur geht selbstverständlich auch alles.

Nicht nur Terminalfenster

herdr verwaltet mehrere Sessions und Workspaces. Das ist nützlich, wenn ich zum Beispiel lokal entwickle, parallel auf einen Server zugreife und dazu einen oder mehrere Agenten laufen lasse.

Ein wichtiger Unterschied zu mehreren gewöhnlichen Terminalfenstern ist die persistente Session: herdr basiert auf einer Client-Server-Architektur. Prozesse, die in einer Session gestartet wurden, laufen weiter, auch wenn ich die Verbindung oder das Terminal verlasse. Wenn ich später zurückkehre, kann ich dort weitermachen und den aktuellen Stand sehen. Das gilt nicht nur für Coding-Agenten, sondern grundsätzlich für Prozesse in der Session.

Damit lassen sich Aufgaben trennen, ohne den Überblick zu verlieren: etwa ein Workspace pro Projekt, separate Sessions für unterschiedliche Agenten und zusätzliche Terminals für Serverzugriffe.

Agenten in den Terminal-Workflow einbinden

Coding-Agenten arbeiten häufig direkt im Terminal. herdr bringt die Sessions, Workspaces und Agent-Integrationen in eine gemeinsame Arbeitsumgebung.
Das macht herdr nicht selbst zum Coding-Agenten. Es organisiert vielmehr die Umgebung, in der Agenten und andere Prozesse laufen. Der praktische Nutzen entsteht, wenn mehrere Aufgaben parallel bearbeitet werden und ich zwischen den jeweiligen Sessions wechseln möchte.

Dazu kommen weitere Features, wie Git-Worktrees für getrennte Arbeitsstände, Plugins, konfigurierbare Tastenkürzel sowie Werkzeuge wie Neovim und Lazygit. Welche davon sinnvoll sind, hängt davon ab, wie viel der eigenen Entwicklungsumgebung man in diesen Workflow integrieren möchte.

Agentische Nutzung

Herdr selbst ist über die Kommandozeile komplette automatisierbar. Da liegt es nahe, dass Agenten auch Herdr fernsteuern. Dazu beitet das Projekt direkt einen passenden Agent-Skill an.

npx skills add herdrdev/herdr --skill herdr -g

Der Skill enthält wichtige CLI Kommandos z.B. für das Window-Management. Dazu kommt noch, dass über das Tool auch über eine Socket-API steuerbar ist.

Remote-Zugriff und parallele Sessions

Für mich ist der SSH-Zugriff ein wichtiger Teil des Ganzen. Remote-Maschinen lassen sich in den Arbeitsablauf einbeziehen, sodass lokale Terminals, Serverzugriffe und Agent-Sessions gemeinsam im Blick bleiben.

Das ist besonders hilfreich, wenn eine Aufgabe nicht nur aus lokalem Code besteht. Man kann etwa ein Projekt bearbeiten, auf einem entfernten System Befehle ausführen und gleichzeitig den Status einer Agent-Session beobachten. Die Oberfläche bündelt diese Kontexte, statt sie auf verschiedene Programme und Fenster zu verteilen.

Fazit

Ich nutze herdr als Terminal-Multiplexer für gewöhnliche Shell-Arbeit, SSH-Zugriffe und Coding-Agenten. Besonders die persistenten Sessions und die Möglichkeit, mehrere Workspaces und Remote-Verbindungen zusammenzuführen, machen es für meinen Workflow interessant.

Es gibt auch noch andere Tools wie tuios die vielleicht flüssiger in der Darstellung sind oder besonders schickt aussehen. Ich persönlich fühle mich zur Zeit mit herdr sehr wohl und bin damit wesentlich produktiver.

In rund zwei Stunden zum eigenen Uptime-Kuma-Widget für KDE Plasma

2026-10-02T08:00:00+00:00

Manchmal entstehen kleine Projekte nicht, weil man unbedingt etwas Neues
programmieren möchte, sondern weil einem im Alltag etwas fehlt. Genau so
war es bei meinem neuen KDE-Plasma-Widget für Uptime Kuma.

Ich betreibe bereits seit einiger Zeit Uptime Kuma, um verschiedene
Server und Anwendungen zu überwachen. Wenn irgendwo etwas ausfällt,
bekomme ich eine entsprechende Benachrichtigung in Discord.

Das funktioniert grundsätzlich gut. Allerdings kann eine
Discord-Nachricht auch einmal untergehen. Gerade wenn man nebenbei viele
andere Nachrichten bekommt, ist schnell eine Meldung übersehen.

Da ich den größten Teil des Tages an meinem KDE-Desktop arbeite, kam mir
deshalb eine einfache Idee: Warum sehe ich den aktuellen Zustand
meiner Systeme nicht direkt auf meinem Desktop?

Gibt es dafür nicht schon ein Widget?

Bevor ich selbst etwas baue, habe ich natürlich erst einmal gesucht.

Meine Vorstellung war eigentlich ziemlich simpel: Ein Plasma-Widget
verbindet sich mit meiner bestehenden Uptime-Kuma-Instanz und zeigt mir
auf einen Blick, ob meine Server und Anwendungen erreichbar sind.

Ich habe allerdings kein vorhandenes Widget gefunden, das meinen
Vorstellungen entsprach.

Ganz unbekannt war mir die Entwicklung von Plasma-Widgets dabei nicht.
Vor vielen Jahren hatte ich bereits selbst ein KDE-Plasmoid geschrieben.
Damals natürlich noch ganz klassisch und ohne KI-Unterstützung.

Das Wissen darüber war inzwischen allerdings ziemlich eingerostet.
Gleichzeitig machte genau das die Sache für mich interessant.

Ein guter Anlass, Antigravity CLI auszuprobieren

Ich wollte Antigravity CLI ohnehin einmal intensiver an einem echten
Projekt ausprobieren. Bis dahin hatte ich nur einen kleinen Teil meines
verfügbaren Token-Volumens verwendet.

Also dachte ich mir: Warum nicht?

Das Projekt hatte dafür eine angenehme Größe. Es war kein künstliches
„Hello World", sondern etwas, das ich anschließend tatsächlich verwenden
wollte. Gleichzeitig war es überschaubar genug, um zu beobachten, wie
gut ein Coding Agent mit einem solchen Projekt zurechtkommt.

Zusätzlich wollte ich ausprobieren, wie sich ein schnelles
Gemini-Flash-Modell bei einer solchen agentischen Coding-Aufgabe
schlägt.

Damit wurde aus dem kleinen Widget gleichzeitig ein Experiment:

Wie weit komme ich mit Antigravity CLI und einem schnellen
Flash-Modell bei einem echten KDE-Plasma-Projekt?

Von null zum ersten Widget

Ich habe bei null angefangen.

Natürlich hatte ich durch mein altes Plasma-Widget eine ungefähre
Vorstellung davon, wie ein Plasmoid aufgebaut ist. Die konkrete
Umsetzung für ein aktuelles Plasma 6 hatte ich aber nicht mehr präsent.

Das war für mich auch ein wichtiger Teil des Experiments. Ich wollte
nicht erst stundenlang Dokumentation lesen und mir den aktuellen
KDE-Stack wieder komplett erarbeiten. Stattdessen sollte Antigravity
einen großen Teil dieser Arbeit übernehmen.

Relativ schnell entstand eine erste funktionierende Version.

Von da an bestand die Arbeit vor allem aus Iterationen: Widget
ausprobieren, Problem entdecken oder eine neue Idee haben, Antigravity
beschreiben, was geändert werden soll, und anschließend das Ergebnis
erneut testen.

Genau bei diesem Ablauf fand ich den Einsatz eines Coding Agents
besonders interessant.

Die Git-Historie zeigt die Geschwindigkeit ganz gut

Die gesamte Session habe ich nicht mit einer Stoppuhr gemessen. Wenn ich
sie rückblickend zusammenrechne, waren es ungefähr zwei Stunden.

Einen Teil davon kann man anhand der Git-Historie ziemlich gut
nachvollziehen.

Der erste heute sichtbare Commit entstand um 20:13 Uhr. Zu diesem
Zeitpunkt war allerdings bereits einiges passiert und das Widget
grundsätzlich vorhanden. Ich hatte ungefähr eine Stunde vorher
angefangen.

Danach ging es Schlag auf Schlag.

Innerhalb von nur 43 Minuten entstanden elf Commits. Dabei ging es
längst nicht mehr nur darum, überhaupt Daten auf dem Desktop anzuzeigen.

Unter anderem wurden Probleme mit der Plasma-6-Kompatibilität behoben,
Redirect-Handling und Gruppenfilterung verbessert, verschachtelte
Monitor-Gruppen berücksichtigt und verschiedene Darstellungsoptionen
ergänzt.

Ein schönes Beispiel dafür ist der Header-only-Modus. Die Funktion wurde
ergänzt, ausprobiert und wenige Minuten später direkt noch einmal
korrigiert.

Das beschreibt meinen tatsächlichen Workflow mit Antigravity ziemlich
gut:

Idee → umsetzen lassen → ausprobieren → Problem entdecken → Feedback
geben → korrigieren lassen → nächste Idee.

Nicht nur ein Proof of Concept

Was mich dabei selbst etwas überrascht hat: Nach diesen ungefähr zwei
Stunden hatte ich nicht einfach nur einen technischen Prototyp.

Das Widget war bereits etwas, das ich tatsächlich auf meinem Desktop
einsetzen konnte.

Es zeigt den Zustand der über Uptime Kuma überwachten Dienste,
Antwortzeiten und Uptime-Werte an. Die Monitore können nach Gruppen
dargestellt werden und über Heartbeat-Balken lässt sich auch der Verlauf
erkennen.

Für unterschiedliche Einsatzorte gibt es verschiedene Darstellungen. Auf
dem Desktop kann ich beispielsweise eine ausführlichere Übersicht
verwenden, während sich das Widget im Plasma-Panel deutlich kompakter
darstellen lässt.

Auch mehrere Widget-Instanzen mit unterschiedlichen Monitor-Gruppen sind
möglich.

Man kann das Widget auch in eine Panel (Leiste) klein einfügen:

Dazu kamen im Laufe der Entwicklung noch Dinge, die ich am Anfang gar
nicht unbedingt auf meiner Liste hatte: Suche und Filterung,
unterschiedliche Anzeigevarianten, KDE-Benachrichtigungen bei Ausfällen
und Wiederherstellungen sowie verschiedene Möglichkeiten zur
Authentifizierung gegenüber Uptime Kuma.

Aus einer relativ einfachen Idee wurde damit erstaunlich schnell ein
ziemlich vollständiges Plasma-Widget.

Der Coding Agent ersetzt nicht das Ausprobieren

Interessant fand ich dabei vor allem, wie sich meine eigene Arbeit
verändert hat.

Ich musste nicht jede QML-Komponente und jede Plasma-6-API selbst
recherchieren und implementieren. Meine Aufgabe bestand viel stärker
darin, das Ergebnis zu beurteilen.

Funktioniert das wirklich? Sieht das auf dem Desktop sinnvoll aus?
Welche Informationen fehlen? Was verhält sich anders als erwartet?
Welche Funktion möchte ich als Nächstes haben?

Gerade bei einem visuellen Projekt kann der Agent diese Bewertung nicht
vollständig übernehmen.

Ich musste das Widget immer wieder starten und tatsächlich benutzen.
Wenn etwas nicht funktionierte oder mir nicht gefiel, konnte ich
Antigravity aber ziemlich konkret beschreiben, was geändert werden
sollte.

Dadurch entstand eine sehr schnelle Feedback-Schleife.

Zwei Stunden sind natürlich nicht die ganze Geschichte

„In zwei Stunden entwickelt" klingt schnell danach, als würde die KI die
komplette Arbeit erledigen und man selbst nur daneben sitzen.

So würde ich es nicht beschreiben.

Ich wusste, welches Problem ich lösen wollte. Ich konnte beurteilen, ob
die vorgeschlagene Lösung sinnvoll ist. Durch mein früheres
Plasma-Widget hatte ich zumindest ein grundsätzliches Verständnis davon,
was dort passiert. Und vor allem habe ich während der gesamten
Entwicklung entschieden, was als Nächstes passieren soll.

Antigravity hat mir allerdings sehr viel Implementierungsarbeit und
Recherche abgenommen. Ich habe bewusst kein Agentic Engineering betrieben sondern nebenbein ein bisschen Vibe-Coding gemacht um zu sehen wie weit man auch ohne große Vorkentnisse kommen kann.

An der Konfiguration habe ich mit dem Agenten einiges iterativ optimieren lassen.
Das kann sich glaube ich auch sehen lassen:

Und genau dadurch konnte aus einer Idee, die ich ansonsten vielleicht
auf irgendeine TODO-Liste geschrieben hätte, innerhalb eines Abends ein
Werkzeug werden, das ich tatsächlich benutze.

Mein Fazit

Für mich war das Projekt ein ziemlich guter Test für agentisches Coding.

Nicht weil das Ergebnis besonders riesig oder komplex wäre, sondern
gerade weil es ein echtes kleines Alltagsproblem löst.

Ich brauchte ein Uptime-Kuma-Widget für meinen KDE-Desktop. Ich fand
keines, das meinen Vorstellungen entsprach. Also habe ich Antigravity
CLI gestartet und ausprobiert, wie weit ich damit komme.

Ungefähr zwei Stunden später hatte ich ein Widget auf meinem Desktop,
das meine Server und Anwendungen überwacht und mich sofort erkennen
lässt, wenn irgendwo etwas nicht stimmt.

Dass dabei ein schnelles Gemini-Flash-Modell ausgereicht hat, um mich
durch QML, Plasma 6, Uptime Kuma und zahlreiche kleine Iterationen zu
begleiten, fand ich mindestens genauso interessant wie das eigentliche
Widget.

Das Experiment hat für mich deshalb vor allem eines gezeigt: Coding
Agents machen eigene Ideen nicht automatisch gut. Aber sie können die
Strecke zwischen „Das wäre eigentlich praktisch" und „Das läuft
jetzt auf meinem Rechner" erstaunlich kurz machen.

Den Quellcode des Widgets habe ich auf GitHub veröffentlicht.
https://github.com/muench-dev/uptime-kuma-plasma-widget

Das Widget ist inzwischen auch direkt über den KDE-Store installierbar:

Home Assistant im Homelab: Bestehende Daten sichtbar machen und mit KI optimieren

2026-09-29T14:46:00+00:00

Ich wollte mehr aus meiner bestehenden Home-Assistant-Installation herausholen. Nicht, weil mir ein neues System gefehlt hätte, sondern weil ich gemerkt habe, dass etliche Informationen bereits im Haus erfasst werden. Sie waren nur nicht überall sinnvoll angeordnet oder auf einen Blick zu finden.

Also habe ich meine Home-Assistant-Konfiguration mit Claude Code und OpenCode prüfen und überarbeiten lassen. In beiden Fällen kamen OpenAI-Modelle zum Einsatz. Das Ergebnis ist mehr als ein neues Dashboard: Es zeigt, wie sich vorhandene Infrastruktur besser nutzen lässt, wie Monitoring eine Grundlage für Automatisierungen schafft und wo Coding Agents bei der Pflege eines gewachsenen Systems helfen können.

Die vorhandenen Daten besser lesbar machen

Der größte Teil der Überarbeitung betraf die Home-Assistant-Ansicht „Übersicht“. Sieben weitere Ansichten habe ich nach einem gemeinsamen Muster neu aufgebaut. Statt unterschiedlich gewachsener Kachelsammlungen gibt es nun klar gegliederte Abschnitte mit Überschriften und Symbolen, einheitliche Kacheln und kompakte Verlaufsgrafiken.

Welche Messwerte auftauchen, hängt vom jeweiligen Bereich ab. Dazu gehören unter anderem Temperatur, Luftfeuchtigkeit, Radon, elektrische Leistung und CO. Eine Kachel zeigt mir den aktuellen Zustand; ein kleiner Verlauf hilft dabei, ihn einzuordnen. Ist eine Temperatur ungewöhnlich, oder war sie schon den ganzen Tag so? Hat sich ein Messwert gerade verändert, oder ist der Verlauf stabil? Ein Graph beantwortet oft mehr als eine weitere Zahl.

Dabei ging es nicht darum, möglichst viele Daten gleichzeitig unterzubringen. Ein Dashboard soll die Fragen beantworten, die im Alltag tatsächlich auftauchen. Leere Abschnitte und doppelte Karten sind deshalb verschwunden. Verweise auf nicht mehr vorhandene Geräte und eine defekte Kamerakarte habe ich entfernt. Auch Beschriftungen und Tippfehler wurden bereinigt. Das klingt banal, macht eine Oberfläche aber leichter lesbar und verhindert, dass veraltete Einträge Vertrauen in die Anzeige kosten.

Zusätzliche Funktionen ergänzen die vorhandenen Ansichten: eine Wettervorhersage, Musiksteuerung, Optionen und Kindersicherung für die Spülmaschine sowie die Akkustände der Rauch- und CO-Melder. Der Schalter für das Gast-WLAN liegt nun im Netzwerkbereich. Die automatische Abschaltung um 22 Uhr bleibt bestehen. Das ist ein kleines Beispiel dafür, dass nicht jede Verbesserung neue Sensoren benötigt. Manchmal reicht es, eine bestehende Funktion an den Ort zu verschieben, an dem man sie erwartet.

Warnungen, die nur bei Bedarf erscheinen

Eine häufige Schwäche von Smart-Home-Dashboards ist die Dauerpräsenz von Statusinformationen. Wenn jeder Zustand gleich prominent dargestellt wird, ist die wichtige Meldung nur eine Kachel unter vielen. Ich wollte deshalb Warnungen, die nur auftauchen, wenn es einen konkreten Grund dafür gibt.

Die Ansichten machen unter anderem Rauch- und CO-Alarme, niedrige Batteriestände, Melder am Ende ihrer Lebensdauer oder außerhalb des Normalzustands sichtbar. Auch Schutzabschaltungen von Shelly-Steckdosen werden gemeldet, etwa bei Überhitzung, Überstrom, Überspannung oder Überlast. Für Salz- und Klarspülermangel sowie eine fertige Spülmaschine gibt es ebenfalls Hinweise. Ein Melder mit schwachem Funksignal bleibt so lange sichtbar, wie das Problem besteht. Bei Rauch- und CO-Alarm kann ich den Melder direkt im entsprechenden Abschnitt stummschalten.

Bei den Steckdosen von Kühl- und Gefriergeräten war mir zusätzlich wichtig, dass eine Berührung der Kachel nicht versehentlich das Gerät ausschaltet. Das ist eine kleine Änderung an der Bedienung, aber eine wichtige Trennung zwischen Statusanzeige und Aktion: Nicht jede Information muss gleichzeitig ein Schalter sein.

Diese Art von Dashboard ist für mich hilfreicher als eine möglichst vollständige Geräteliste. Ich sehe weiterhin relevante Zustände, aber die Oberfläche lenkt meine Aufmerksamkeit auf Abweichungen. Damit das klappt, müssen die zugrunde liegenden Entitäten natürlich gepflegt sein. Ein schöner Warnhinweis hilft nicht, wenn die Integration dahinter längst keine verlässlichen Daten mehr liefert.

Aus Messwerten werden Automatisierungen

Ein neues Dashboard zeigt jetzt außerdem die Nutzung mehrerer KI-Dienste: Kosten, Anfragen und Token-Zahlen für OpenAI, OpenRouter und Opper AI. Hinzu kommen eine Gesamtsumme und die Kosten des aktuellen Tages. Zum Zeitpunkt meiner Erfassung lag der Tageswert bei 1,16 US-Dollar.

Die Metriken sind nicht nur interessant, weil sie eine Rechnung erklären. Sie können auch eine konkrete Aktion auslösen. Ich habe eine Home-Assistant-Automation eingerichtet, die mich per Discord benachrichtigt, wenn die Tageskosten 10 US-Dollar überschreiten. Dafür gibt es die Discord-Integration und ein Skript zum Versenden der Meldung.

An dieser Stelle braucht es keine generative KI, um zu entscheiden, ob die Kosten „hoch“ sind. Der Grenzwert ist eindeutig: Liegt der Tageswert darüber, wird eine Nachricht gesendet. Das macht die Regel leicht verständlich und vorhersehbar. Die KI war bei der Arbeit an der Konfiguration hilfreich; im laufenden Betrieb übernimmt eine normale Automation die Entscheidung.

Für mich ist die Reihenfolge entscheidend: Erst müssen die Daten verfügbar sein, dann kann ich sie sinnvoll visualisieren. Wenn die Messwerte verlässlich sind, lassen sich darauf nachvollziehbare Regeln aufbauen. Ohne Metriken würde ich nur vermuten, ob ein Grenzwert erreicht wurde. Mit einer Automation muss ich auch nicht darauf hoffen, zufällig zur richtigen Zeit in die passende Ansicht zu schauen.

Dass Home Assistant an meinen Discord-Server loggt, hilft außerdem dabei, Meldungen außerhalb des Dashboards mitzubekommen. Eine Benachrichtigung ist dabei kein Selbstzweck. Sie sollte klar sagen, was passiert ist und warum ich darauf achten sollte. Für den Anfang ist eine einzelne Schwellenwert-Warnung besser als eine Flut von Meldungen, die ich irgendwann ignoriere.

Coding Agents für die Arbeit, die sonst liegen bleibt

Claude Code und OpenCode haben mich bei der Prüfung und Überarbeitung der bestehenden Home-Assistant-Konfiguration unterstützt. Gerade bei einem länger genutzten System sammelt sich Arbeit an, die einzeln überschaubar wirkt: Ansichten vereinheitlichen, alte Geräteverweise finden, doppelte Karten entfernen, Beschriftungen korrigieren und Warnungen konsistent aufbauen. Zusammengenommen kosten diese Aufgaben Zeit, die im Alltag oft für andere Dinge draufgeht.

Ein Coding Agent kann den Bestand analysieren, Zusammenhänge herausarbeiten und Änderungsvorschläge umsetzen. Das heißt nicht, dass jede vorgeschlagene Änderung automatisch richtig ist. Home Assistant hängt an echten Geräten und kann damit reale Auswirkungen haben. Ich behandle die Agenten deshalb als Werkzeuge für Analyse und Konfigurationsarbeit, nicht als autonome Hausverwaltung. Änderungen müssen nachvollziehbar bleiben und anschließend geprüft werden. Besonders bei Schaltern und Automationen sollte klar sein, welche Entität angesprochen wird und welche Folge eine Aktion hat.

Der praktische Gewinn liegt für mich nicht darin, dass KI jede Entscheidung abnimmt. Sie senkt die Hürde, einen gewachsenen Bestand aufzuräumen. Aufgaben, die ich immer wieder verschoben habe, lassen sich gezielter angehen, wenn ein Agent beim Durchsuchen und Strukturieren hilft. Die Verantwortung für die Änderung und den Betrieb bleibt trotzdem bei mir.

Neue Informationen aus bestehenden Integrationen

Neben der Dashboard-Arbeit haben sich auch die verfügbaren Informationen einzelner Integrationen erweitert. Nach einem Update von Home Connect gibt es zusätzliche Hinweise zu Salzmangel, Klarspüler sowie Erinnerungen an Maschinenpflege und Filterreinigung. Für den Fernseher im Wohnzimmer ist ein separater Schalter für den Bildschirm hinzugekommen. Bei der Photovoltaik zeigt ein weiterer Sensor an, wie lange Erfassungsdaten fehlen.

Das sind keine großen Plattformwechsel. Es sind Ergänzungen innerhalb der Infrastruktur, die bereits vorhanden ist. Wenn eine Integration einen hilfreichen Sensor neu bereitstellt, kann er in ein Dashboard aufgenommen oder als Auslöser einer Automation genutzt werden. Die Voraussetzung ist, dass ich die Information auch wahrnehme und ihren Zustand richtig verstehe.

Sichtbarkeit ist keine Fehlerbehebung

Die Überarbeitung hat nicht alle Probleme beseitigt. Bei der Türklingel liefert die Integration keine Kamera mehr. Ein Gerät war zeitweise nicht erreichbar; im Log standen dazu rund 530 Timeout-Meldungen. Außerdem gibt es einzelne nicht erreichbare Geräte und weiterhin einen Melder mit schwachem Funksignal.

Das ist kein Widerspruch zum besseren Dashboard. Im Gegenteil: Eine gute Übersicht sollte nicht den Eindruck erwecken, alles sei in Ordnung, nur weil die Oberfläche sauber aussieht. Sie hilft dabei, Fehler und Ausfälle leichter zu erkennen. Die Ursache kann aber bei einer Integration, einem Gerät, der Netzwerkverbindung oder einer anderen Abhängigkeit liegen. Das muss getrennt untersucht werden.

Diese Grenze ist auch für KI wichtig. Ein Agent kann Logs und Konfigurationen beim Eingrenzen eines Problems unterstützen. Er kann aber nicht allein aus einer schön formatierten Ansicht folgern, dass ein Gerät zuverlässig funktioniert. Wenn Daten ausbleiben, muss der Zustand als Problem sichtbar bleiben, statt stillschweigend als normal zu gelten.

Ein übertragbares Vorgehen fürs eigene Homelab

Vielleicht sind folgende Schritte auch für dein Homelab spannend:

Vorhandene Daten inventarisieren. Welche Sensoren, Integrationen und Zustände gibt es bereits? Bevor ich neue Hardware anschaffe, lohnt sich ein Blick auf das, was schon erfasst wird.
Nach Alltagstauglichkeit ordnen. Eine gute Übersicht gruppiert Informationen nach ihrem Zweck und zeigt Entwicklungen, wenn ein Verlauf beim Einordnen hilft.
Warnungen an Bedingungen knüpfen. Nur relevante Abweichungen sollten Aufmerksamkeit verlangen. Ständige Statusmeldungen stumpfen ab.
Erst messen, dann automatisieren. Ein stabiler Sensorwert und eine klare Regel sind eine bessere Basis als eine komplizierte Automation auf unsicheren Daten.
KI für Analyse und Routinearbeit einsetzen. Coding Agents können beim Durchsuchen und Aufräumen helfen. Änderungen, besonders solche mit realen Auswirkungen, müssen überprüfbar bleiben.
Fehler nicht verstecken. Ein Dashboard darf Probleme nicht kaschieren. Veraltete Daten, nicht erreichbare Geräte und Integrationsfehler gehören ebenfalls in den Blick.

Mein Home Assistant war schon vorher ein wichtiger Teil des Homelabs. Durch die Überarbeitung ist er für mich nützlicher geworden: Die Informationen, die bereits im System lagen, sind leichter auffindbar, ausgewählte Probleme fallen schneller auf, und aus einer neuen Kostenübersicht ist eine konkrete Discord-Warnung entstanden.

Die KI hat mir geholfen, die Arbeit anzugehen, für die ich sonst wenig Zeit hatte. Die Automatisierungen bleiben bewusst nachvollziehbar, und Home Assistant führt die klar definierten Regeln aus. Das Zusammenspiel aus vorhandener Infrastruktur, sichtbaren Metriken und geprüfter KI-Unterstützung ist für mich der eigentliche Mehrwert.

Welche Daten in eurem Homelab oder eurer bestehenden IT sind zwar schon vorhanden, aber noch nicht dort sichtbar, wo sie euch wirklich helfen würden?

LinkDing-Bookmarks automatisch taggen: Mein KI-Workflow mit n8n, Opper AI und kev

2026-09-25T08:00:00+00:00

Links speichere ich im Alltag schnell nebenbei. Sie später wiederzufinden, ist eine andere Sache. Eien gute Suche ist wichtig. Ich mag aber auch gerne Tags haben um auch Zusammenhänge und ähnliche Links schneller zu sehen. Für meine selbst gehostete Linkding-Instanz habe ich deshalb einen Workflow gebaut, der neue und bisher unverschlagwortete Bookmarks automatisch einordnet.

Dabei kommen zwei Browser-Erweiterungen, die Linkding-REST-API, n8n und ein kleines Modell über Opper AI zusammen. Der entscheidende Teil ist nicht einfach „KI macht Tags“, sondern das Klassifikationssystem, nach dem die Tags vergeben werden.

Links im Browser sammeln und wiederfinden

Ich nutze zwei Erweiterungen, die unterschiedliche Aufgaben übernehmen:

LinkDing Extension (Chrome Store) speichert einen Link in meiner Linkding-Instanz. Zusätzlich blendet die Erweiterung Linkding-Suchergebnisse im Hintergrund auf Suchseiten wie Google ein. Ich kann also beim Suchen sehen, ob ein Link bereits in meiner Sammlung liegt.

LinkDing Bookmark Sync (Chrome Store) synchronisiert meine Tags als Ordner im Browser und ordnet die passenden Bookmarks darunter ein. So kann ich gespeicherte Links auch über die vertraute Ordnerstruktur wieder aufrufen.

Linkding läuft bei mir selbst gehostet. Für die Anmeldung nutze ich SSO über Authentik. Die Sammlung bleibt damit unter meiner Kontrolle, ist für mich aber auch über die Weboberfläche durchsuchbar.

Der n8n-Workflow übernimmt ungetaggte Bookmarks

Der Automatisierungsteil läuft in n8n. Über die Linkding-REST-Schnittstelle lese ich die Bookmarks aus, die noch keinen Tag haben. Damit bearbeitet der Workflow nicht bei jedem Lauf die komplette Sammlung erneut, sondern konzentriert sich auf die offenen Einträge.

Die Bookmark-Daten gebe ich an einen kleinen separaten n8n-Workflow weiter. Dessen Eingabeparameter heißt body und ist schlicht ein String. So bleibt der Baustein unabhängig vom ursprünglichen Ablauf: Er bekommt die Informationen zu einem Bookmark, klassifiziert sie und ermittelt am Ende eine Tag-Liste.

Für die Klassifikation verwende ich Opper AI als Model Router und das Modell kev 4b. Der Baustein ruft die API zweimal auf. Die Einordnung läuft in zwei Stufen und basiert auf einem Klassifikationssystem, das ich gemeinsam mit Gemini ausgearbeitet habe. Es ist eher eine Art Weltbild als eine lose Sammlung einzelner Themenwörter: Die Tags sollen Links in eine Struktur einordnen, die zu meiner Art passt, Wissen und Interessen zu sortieren.

Ich beschreibe die beiden Schritte bewusst nicht als magische „KI versteht alles“-Funktion. Das Modell bekommt die Bookmark-Informationen und die Vorgaben des Klassifikationssystems; als Ergebnis liefert es die Tags, die ich für die Verschlagwortung nutze.

Warum ein kleines Modell hier ausreicht

Für diese Aufgabe brauche ich kein Modell, das lange argumentiert oder einen ausführlichen Text formuliert. Es soll einen Link anhand einer vorgegebenen Taxonomie schnell zuordnen. Das ist eine eng umrissene Klassifikationsaufgabe, bei der ein schnelles System-1-Modell für mich besser passt als ein großes Modell mit aufwendigem Reasoning.

Auch die Kosten sprechen dafür. Bei dem Tarif, den ich für kev 4b nutze, werden 0,04 US-Dollar pro einer Million Input-Tokens berechnet; Output-Tokens kosten nichts. Da der Workflow zweimal auf die API zugreift, ist der Input natürlich der relevante Kostenfaktor. Für die Menge an Text, die bei einem Bookmark anfällt, bleibt das sehr günstig. Die konkrete Preisangabe bezieht sich auf meinen verwendeten Tarif und kann sich ändern.

In der Praxis ist die Verarbeitung außerdem schnell genug, dass automatisches Tagging nicht zu einem eigenen Arbeitsschritt wird. Ein Link landet in Linkding, der Workflow klassifiziert ihn im Hintergrund, und die Tags stehen anschließend für Suche und Sync zur Verfügung.

Auch der vorhandene Bestand bekommt neue Tags

Der Workflow war nicht nur für neue Bookmarks nützlich. Ich habe damit auch alle meine bisherigen Bookmarks einmal neu taggen lassen. Das war wichtig, weil eine gute Taxonomie erst dann ihren Wert zeigt, wenn nicht nur die Links von heute, sondern auch das über Jahre gewachsene Archiv darin auftaucht.

Seitdem (ok seit gestern erst) ist die Verschlagwortung für mich deutlich schneller und konsistenter. Dadurch, dass ich einfach alle Tags neu habe vergeben lassen, sehe ich deutlich den Unterschied zu vorher. Ich muss nicht jedes Mal neu überlegen, welchen Tag ich für einen ähnlichen Link verwendet habe. Und weil die Tags anschließend auch als Browser-Ordner sichtbar sind, funktioniert dieselbe Ordnung in Linkding und im Browser.

Was ich dabei im Blick behalten muss

Automatisches Tagging macht die Klassifikation nicht automatisch richtig. Wenn sich die Taxonomie verändert oder ein Bookmark mehrdeutig ist, kann ein Tag fehlen oder unpassend sein. Das System steht und fällt deshalb mit einer verständlichen, gepflegten Tag-Struktur. Die zwei Klassifikationsschritte ersetzen diese Arbeit nicht, sie wenden die Struktur nur konsequenter an.

Auch der Datenweg verdient Beachtung: Linkding ist selbst gehostet, aber die Bookmark-Informationen, die ich an den Klassifikationsbaustein übergebe, werden für die Modellverarbeitung an Opper AI weitergereicht. Self-Hosting allein bedeutet also nicht, dass jeder Verarbeitungsschritt lokal bleibt. Bei privaten oder vertraulichen Links muss ich berücksichtigen, welche Daten ich an den Router und das ausgewählte Modell sende.

Fazit

Der Workflow ist für mich ein gutes Beispiel dafür, wo ein kleines Modell sinnvoller sein kann als ein möglichst großes: Die Aufgabe ist klar begrenzt, die Tag-Struktur ist von mir vorgegeben, und das Ergebnis soll schnell und günstig verfügbar sein.

Mit Linkding als selbst gehostetem Archiv, den beiden Browser-Erweiterungen für Sammlung und Zugriff sowie n8n für die Automatisierung ist daraus ein Ablauf geworden, der neue und bestehende Bookmarks konsistenter sortiert. Der größte Aufwand lag nicht in den zwei API-Aufrufen, sondern darin, ein Klassifikationssystem zu entwickeln, das für meine Sammlung tatsächlich funktioniert.

Ich nutze noch zum sammeln für Artikel oder für ein "Read it Later" das Tool Readeck. Das kommt (bewusst) ohne KI-Tagging daher. Auch dort habe ich die gleiche Tagging-Logik integriert. Das ist aber was für einen gesonderten Blog-Artikel.

Mein Hermes-Agent kümmert sich um unseren Minecraft-Server

2026-09-24T15:00:00+00:00

Mein Sohn wollte, dass ich ein Minecraft-Plugin auf unserem Server installiere. Ich war gerade bei der Arbeit. Statt die Aufgabe auf später zu verschieben, habe ich sie an mein Hermes-Profil "Homelab" übergeben. Der Agent kennt den Server bereits aus seinem Inventar und verwaltet ihn für mich.

Er hat die Installation übernommen und bei der Einrichtung ein Problem mit der Updatequelle entdeckt: Der Updater verwies auf ein anderes, ähnlich benanntes Projekt. Der Agent hat mich darauf hingewiesen und eine passende Korrektur vorgeschlagen. Wir haben die Änderung gemeinsam abgestimmt und umgesetzt. Auch die Einstellungen für einen sicheren Betrieb haben wir zusammen angepasst.

Vom Auftrag bis zur Prüfung

Der Agent hat nicht nur die Plugin-Datei installiert. Er hat den Serverzustand geprüft, das Problem mit der Updatequelle erkannt, eine Verbesserung vorgeschlagen und die abgestimmten Änderungen durchgeführt.

Anschließend hat er den Server geordnet neu gestartet und geprüft, ob das Plugin aktiv ist, der Server sauber hochkommt und der Updater die eingetragenen Plugins korrekt erkennt. Die Prüfungen waren erfolgreich.

Ein Agent mit Kontext über mein Homelab

Der Unterschied zu einer einmaligen Chat-Antwort: Mein Homelab-Profil kannte den Server bereits und hatte Zugriff auf die für die Verwaltung nötigen Informationen. Ich musste nicht erst erklären, welche Maschine gemeint ist oder die einzelnen Schritte selbst ausführen. Ich konnte den Auftrag übergeben und bekam auch eine Rückmeldung, als der Agent auf ein Problem stieß.

Die technische Routinearbeit hat der Agent übernommen. Änderungen mit Auswirkungen auf den Server haben wir miteinander abgestimmt. Danach hat er das Ergebnis überprüft. Genau diese Kombination ist mir wichtig: Der Agent kann Aufgaben in einer bekannten Umgebung selbständig erledigen, weist auf Probleme hin und bezieht mich ein, wenn eine Entscheidung nötig ist.

Für mich war das eine praktische Entlastung während der Arbeit. Mein Sohn bekam das gewünschte Plugin früher, und ich konnte weiterarbeiten.

Hindsight: Ein Agent-Memory-System, das mich begeistert hat

2026-08-27T07:00:00+00:00

Jeder, der täglich mit Claude Code, Codex CLI oder opencode arbeitet, kennt das Problem: Der Agent ist am Ende jeder Session wieder bei null. Man erklärt zum gefühlt zehnten Mal den Tech-Stack, die Team-Konventionen, warum man Redis-Caching vor drei Monaten wieder verworfen hat. Notizen in System-Prompts oder CLAUDE.md-Dateien helfen, skalieren aber nicht – sie erfassen keine gewachsene, sich verändernde Wissensbasis, sondern nur einen statischen Snapshot.

Ich bin seit ein paar Wochen mit Hindsight unterwegs, einem Open-Source-Memory-System von Vectorize.io, und bin ziemlich angetan. Oder sagen wir es wie es ist. Ich bin seit langem mal wieder richtig begeistert von einer Software-Lösung gewesen. Es macht genau das, was man sich unter "Agent-Gedächtnis" vorstellt, wenn man es nicht auf die naive Vektor-DB-Lösung reduziert. Es haben sich für mich gedanklich aber auch technisch neue Welten aufgetan.

Warum sollte man Hindsight nutzen?

Bevor ich in die technischen Details gehe, kurz die drei Gründe, die für mich den Ausschlag gegeben haben:

Erhöhte Kontextkontinuität: Agenten behalten relevantes Vorwissen über Sessions hinweg und liefern dadurch konsistente, personalisierte Empfehlungen – statt bei jeder neuen Session wieder bei null anzufangen.
Bessere Genauigkeit bei komplexen Fragen: Temporal- und Graph-Retrieval kombiniert mit automatischer Beobachtungs-Konsolidierung erhöhen die Trefferquote spürbar, gerade bei historischen oder indirekt verknüpften Fakten.
Kontrollierte, erklärbare Erinnerungs-Logik: Missionen und Direktiven schaffen Sicherheits- und Compliance-Guardrails, Evidenz-Tracking macht nachvollziehbar, worauf eine Antwort eigentlich basiert.

Was Hindsight ist – und was nicht

Der wichtigste Punkt zuerst: Hindsight ist keine reine Vektor-Datenbank mit hübscher API drumherum. Wer Rohdaten reinwirft und hofft, dass Cosine-Similarity am Ende die richtige Antwort liefert, wird von naiven RAG-Ansätzen regelmäßig enttäuscht. Sobald man ein paar hundert Memories über verschiedene Themen und Zeiträume hat, bricht das Prinzip "Embed alles, hol dir Top-K" oft zusammen.

Hindsight geht einen anderen Weg. Im Hintergrund läuft PostgreSQL mit der pgvector-Extension als Speicher, aber was aber genutzt wird, sind nicht die Rohdaten, sondern das Ergebnis eines Extraktionsprozesses: strukturierte Fakten, aufgelöste Entitäten (aus "Alice" und "meine Kollegin Alice" wird ein und dieselbe Entität), Zeitstempel für temporale Auswertungen und ein Wissensgraph, der die Beziehungen zwischen den Entitäten abbildet. Wer jetzt angst um seine Daten hat... ok, es sind auch die Dokumente in der Postgres Datenbank weiterhin gespeichert als "Document". Aber die reinen Dokuemten sind eben in dem gesamten Prozess nicht das spannende sondern die aufbereiteten Daten.

Angebunden wird das Ganze über MCP – Claude Code, Codex, opencode, Cursor, VS Code, praktisch jeder MCP-fähige Client kann sich verbinden. Für die interne Verarbeitung (Fakten-Extraktion, Entity-Resolution, Reflect-Operationen) braucht Hindsight einen eigenen LLM-Provider – unabhängig vom Modell, das der eigentliche Agent nutzt. Das ist ein Detail, das mir gut gefällt: Man kann hier bewusst ein günstiges, schnelles Modell einsetzen, weil diese Verarbeitung im Hintergrund läuft und nicht die Qualität der eigentlichen Agent-Antworten beeinflusst. Ich habe für meine Tests das GPT-5.6 Luna Modell verwendet, weil es erstmal auf meine private Rechnung lief. Trotz des günstigen Modells habe ich aber richtig gute Ergebnisse bekommen. Man kann in Hindsight aber auch mehrere Modelle nutzen und falles feintunen. Ich habe ehrlicherweise bisher vielleicht 30-40% der Funktionen ausprobiert. Aber das macht nichts. Man bekommen einfach schnell Ergebnisse und kann mit den Daten arbeiten und auch selbst die Daten verbessern. Wie? Das kommt jetzt.

Die drei Kernoperationen

Hindsight bietet drei zentrale Operationen, die als MCP-Tools zur Verfügung stehen:

retain – Speichern. Man füttert Hindsight mit Text (eine einzelne Tatsache, eine ganze Konversation, ein Dokument), und im Hintergrund extrahiert ein LLM strukturierte Fakten, löst Entitäten auf, erzeugt Embeddings und indiziert alles für die spätere Suche. Wichtig: Man sollte nicht vorab selbst zusammenfassen oder Fakten extrahieren – Hindsight braucht den vollen Kontext einer Konversation, sonst wird aus "ja, genau" oder "ich nehme Option 2" schlicht bedeutungsloser Text.

recall – Suchen. Hier laufen vier Retrieval-Strategien parallel: semantische Suche, BM25-Keyword-Matching, Graph-Traversal über den Wissensgraphen und temporale Filterung. Die Ergebnisse werden anschließend per Cross-Encoder-Reranking sortiert. Das ist der eigentliche Clou gegenüber einer simplen Vektorsuche: Eine Frage wie "Was haben wir zum Caching entschieden?" findet die richtige Antwort auch dann, wenn die ursprüngliche Memory eine andere Terminologie verwendet.

reflect – Synthetisieren. Reflect geht über reines Abrufen hinaus und lässt ein LLM über mehrere Memories hinweg Schlüsse ziehen – etwa auf die Frage "Welchen Tech-Stack würdest du mir basierend auf meinen bisherigen Entscheidungen empfehlen?".

flowchart LR    
    subgraph YourApp["Your Application"]
        A["AI Agent"]
    end

    subgraph Hindsight["Hindsight"]
        API["API Server"]

        subgraph MemoryBank["Memory Bank"]
            direction TB
            MM["Mental Models"]
            OBS["Observations"]
            ME["Memories & Entities"]
            CH["Chunks"]
            DOC["Documents"]

            MM --> OBS
            OBS --> ME
            ME --> CH
            CH --> DOC
        end
    end

    A -->|retain| API
    A -->|recall| API
    A -->|reflect| API

    API --> ME

Extraktionsstrategien und Tagging

Ein Punkt, der in der Praxis unterschätzt wird: Nicht jede Datenquelle soll gleich verarbeitet werden. Hindsight bietet dafür benannte Retain-Strategien – etwa verbatim für Inhalte, die wortwörtlich gespeichert werden sollen, oder chunks für größere Dokumente, die in Abschnitte zerlegt werden. Diese Strategien lassen sich in der Bank-Konfiguration definieren und dann je nach Quelle gezielt beim retain-Aufruf auswählen.

Dazu kommt ein Tagging-System mit sogenannten Entity Labels: kontrollierte Vokabulare nach dem Schema key:value, etwa user:christian oder topic:architektur, die beim Speichern automatisch extrahiert werden können. Für die reine inhaltliche Suche braucht man das oft gar nicht – Entitäten landen ohnehin im Wissensgraph und treiben die Graph-basierte Suche an. Für explizite Filterung auf entitätsähnliche Werte sind die Tags aber Gold wert, gerade wenn man mehrere Projekte oder Kunden in einer Bank sauber getrennt halten will.

Mental Models: lebende Dokumente

Was mich am meisten überzeugt hat, sind die Mental Models. Man definiert eine Frage – zum Beispiel "Welche Architekturentscheidungen wurden für Projekt X getroffen?" – und Hindsight erzeugt daraus ein Dokument, das sich automatisch aktualisiert, sobald neue Memories dazukommen oder sich bestehende Dokumente ändern. Man muss also nicht bei jeder Anfrage ein volles reflect über den kompletten Memory-Bestand laufen lassen, sondern bekommt eine Art vorberechnete, immer aktuelle Zusammenfassung.

Technisch läuft das asynchron über eine Queue: Die eigentliche LLM-gestützte Generierung passiert im Hintergrund, ein API-Aufruf liefert zunächst nur eine Operation-ID zurück, das fertige Ergebnis ist dann nach ein paar Sekunden abrufbar. Das ist konsequent zu Ende gedacht, hat aber auch eine Kehrseite, dazu gleich mehr.

Skalieren ist auch kein Problem, denn es gibt im Konzept auch Worker-Instanzen die dann auch per Kubernetes skaliert werden können. Das ist alles möglich. In meinem Homelab Setup tut es auch ein einzelner Worker in einem fixen Docker-Container.

Visualisierung

Im Control Plane – dem Admin-UI von Hindsight – gibt es die sogenannte Constellation View: eine interaktive, zoombare Graphdarstellung der Entity-Relationships mit Heat-Gradient-Einfärbung, auch im Dark Mode nutzbar. Für mich ist das mehr als nur ein nettes Feature – bei einem wachsenden Wissensgraphen hilft die visuelle Übersicht enorm dabei, ein Gefühl dafür zu bekommen, was die eigene Memory-Bank eigentlich "weiß" und wo die Extraktion vielleicht danebenliegt.

Natürlich kann man auch filtern, zoomen und auf die einzelnen dahinterliegenden Dokumente schauen.

Features im Überblick

Ein paar Punkte aus der Gesamtliste, die im Artikel bisher noch nicht vorkamen, aber zum Verständnis dazugehören:

Hierarchische Memory-Typen: Neben Mental Models (kuratierte, selbst definierte Zusammenfassungen) gibt es Observations – automatisch aus Rohfakten konsolidierte, evidenzgestützte Glaubenssätze –, außerdem World Facts und Experience Facts. Diese Trennung sorgt dafür, dass reflect bei der Beantwortung einer Frage zuerst die Mental Models prüft, dann die Observations und erst zuletzt auf Rohfakten zurückgreift.
Multi-Strategie-Retrieval (TEMPR): Die vier parallelen Suchstrategien aus recall – Semantic, Keyword/BM25, Graph, Temporal – laufen unter dem Namen TEMPR und werden per Reciprocal-Rank-Fusion zusammengeführt, bevor das Cross-Encoder-Reranking greift. Das macht den Abruf auch bei zeitlich oder graphbasiert verknüpften Fragen robust.
Observation Consolidation: Nach jedem retain-Aufruf läuft im Hintergrund automatisch ein Konsolidierungsprozess, der neue Fakten gegen bestehende Observations abgleicht, dedupliziert und mit Evidenz-Verweisen versieht. Beobachtungen, die durch neuere, noch nicht konsolidierte Fakten überholt sein könnten, werden dabei als "stale" markiert und vor der Nutzung gegen die Rohfakten verifiziert.
Temporal Reasoning: Abfragen wie "letzten Frühling" oder "im Juni" werden nicht nur semantisch, sondern explizit zeitbasiert aufgelöst – ein Bereich, in dem reine Vektorsuche typischerweise versagt.
Missions- und Richtlinien-Konfiguration: Auf Bank-Ebene lässt sich eine Mission definieren, die vorgibt, welches Wissen priorisiert werden soll, dazu unveränderliche Direktiven als Compliance-Guardrails und Disposition-Traits wie Skepsis, Literalität oder Empathie, die beeinflussen, wie reflect Argumente gewichtet. Wichtig: Diese Einstellungen wirken nur auf reflect, nicht auf recall.
Evidenz-gestützte Antworten: Observations verweisen auf ihre Quell-Memories inklusive Zitat-Belegen und Proof-Counts – das macht die Herleitung einer Antwort nachvollziehbar, statt sie als Black Box hinzunehmen.
Clients & SDKs: Offizielle SDKs für Python, TypeScript und Go, dazu CLI und HTTP-API – die Integration in bestehende Agent-Stacks jenseits von MCP ist damit unkompliziert.
Deployment-Optionen: Neben dem lokalen Docker-Setup, wie ich es im Homelab nutze, gibt es Helm-Charts für Kubernetes, eine pip-Installation für den schnellen lokalen Test sowie einen Integrations-Hub für angebundene Datenquellen.

Wie kommen Daten ins System?

Daten können auf verschiedenen Wegen in das Memory gelangen. Wird der MCP-Server genutzt kann einfach über das retain Tool etwas gespeichert werden. Bei jedem erfassten Dokumente können Tags und eine eindeutige Document-ID definiert werden. Das definieren der Document-ID ist optional. Wird keine mitgesendet, erstellt das System eine UUID.
Wenn man Rohdaten z.B. Chatverläuft speicher will, dann reicht es die generierte UUID zu verwenden. Wenn es Daten wie z.B. der Inhalt hinter Webseite sind, dann kann die Document-ID auch eine URL sein. Wird mit der gleichen Document-ID ein neues Dokument gesendet, dann aktualisiert Hindsight auch den bestehenden Eintrag.
Zusätzlich lassen sich in Hindsight auch für verschiedene Quellen dann unterschiedliche strategien für das extrahieren der Daten definieren. Man kann dann auch Einfluss auf die RAG spezifischen Parameter wie die Chunk-Size nehmen.

Da Hindsight durchgängig so konzipiert wurde, dass alles was die UI macht über eine REST-API kommuniziert, ist es auch ein einfaches die gleiche API für das importieren von Daten zu nutzen.
Beispielhaft habe ich mal ein n8n Community Plugin installiert, dass einfach die drei Grundopterationen in einem n8n Node abbildet.

Mein Setup im Homelab

Ich habe mir das Ganze nicht in der Cloud, sondern in meinem Homelab aufgesetzt – zwei LXC-Container, einer für die API, einer für das Admin-UI beziehungsweise Control Plane. Die Datenbank musste ich nicht neu aufsetzen: Ich hatte bereits einen PostgreSQL-Server mit pgvector-Extension laufen und musste dort nur eine zusätzliche Datenbank anlegen. Das hat das Setup deutlich vereinfacht – wer schon eine Postgres-Instanz mit pgvector betreibt, ist hier in Minuten startklar, statt sich mit der eingebetteten PostgreSQL-Variante aus dem Docker-Quickstart herumzuschlagen.

Als LLM-Provider für die interne Verarbeitung habe ich schnell OpenRouter angebunden und dort auf GPT-5.6 Luna gesetzt – die günstige, latenzoptimierte Variante aus OpenAIs GPT-5.6-Serie, gedacht für genau solche hochfrequenten, aber nicht sonderlich anspruchsvollen Hintergrundaufgaben wie Fact-Extraction. Das Modell lässt sich aber problemlos austauschen: Hindsight unterstützt eine breite Auswahl an Providern, von OpenAI über Anthropic und Gemini bis zu lokalen Modellen über Ollama oder llama.cpp. Wer die interne Verarbeitung lieber komplett offline und ohne externe API-Calls fahren will, kann das inzwischen ebenfalls tun.

Integration in andere Systeme

Über MCP lässt sich Hindsight praktisch überall andocken, wo ein Client den Standard spricht – Claude Code, Codex CLI, opencode und weitere Coding-Agents sind direkt unterstützt, teils sogar mit automatischer Ingestion ohne zusätzlichen Setup-Schritt.

Der MCP Server ist direkt in Hindsight enthalten und kann für jede Memory-Bank einzeln eingestellt werden. Man kann auch die MCP-Tools beschränken.

Ich habe bei mir nichts beschränkt da ich sowieso noch einen zwischengeschalteten LiteLLM-Gateway habe.

Use Cases

Der naheliegendste Use Case für mich persönlich ist gar nicht primär technisch: Ich möchte Daten rund um den Fußballverein Wormatia Worms aufbereiten, um die Mitarbeiter in der Geschäftsstelle zu entlasten. Statt jede Anfrage manuell zu beantworten, könnte ein Agent auf einer Hindsight-Bank mit historischen Informationen, Vereinsregeln und wiederkehrenden Fragen aufsetzen und so einen echten Teil der Kommunikationslast abnehmen.

Daneben baue ich gerade eine zweite, eigene Bank auf: Dort arbeite ich die Vereinschronik, Saisonergebnisse und Spieler-Steckbriefe ein. Das Interessante hier ist nicht der reine Abruf einzelner Fakten, sondern dass das System selbstständig statistische Besonderheiten und Zusammenhänge über die eingespielten Daten hinweg entdecken soll – etwa, dass eine bestimmte Saison auffällig viele Unentschieden hatte oder ein Spieler in mehreren Spielzeiten überdurchschnittlich oft getroffen hat. Genau dafür ist reflect gedacht: nicht nur Fakten abrufen, sondern über den gesamten Datenbestand hinweg Schlüsse ziehen. Besonders spannend wird das für den Archivar des Vereins, der Fragen stellen möchte wie "Wann war die längste Siegesserie?" – Fragen, die kein einzelner Datensatz beantwortet, sondern die erst aus der Zusammenschau vieler Saisonergebnisse entstehen.

Im technischen Projektumfeld sehe ich mindestens zwei weitere sinnvolle Einsatzszenarien:

Architektur- und Richtlinien-Gedächtnis: Ein Agent, der Softwarearchitektur-Entscheidungen, Coding-Guidelines und Projektkonventionen im Blick behält und Entwicklern direkt im Coding-Tool als Frage-Antwort-Instanz zur Verfügung steht – ohne dass diese erst in einem Wiki suchen müssen.
Vollständigkeitsprüfung bei Anforderungen: In Projekten, in denen Anforderungen laufend erfasst werden, kann ein Agent mit Zugriff auf die gesammelten Memories prüfen, ob alle notwendigen Dokumente und Informationen vorliegen, und gezielt auf Lücken hinweisen. Gerade in Business-Kontexten mit vielen Stakeholdern ist das ein Szenario, das echten Mehrwert liefert.

Beurteilung

Was gut funktioniert: Der Einstieg ist erfreulich niedrigschwellig, insbesondere wenn – wie in meinem Fall – schon eine Postgres/pgvector-Instanz vorhanden ist. MCP als Anbindungsstandard bedeutet, dass man nicht für jeden Client eine eigene Integration bauen muss. Die Kombination aus Multi-Strategy-Retrieval und Reranking liefert in der Praxis spürbar bessere Trefferqualität als eine simple Vektorsuche, gerade bei größeren, thematisch gestreuten Memory-Beständen.

Gibt es bei dem Ansatz auch Dinge die mich stören? Nicht wirklch, aber man sollte sich bewusst sein, dass mit der steigenden Anzahl an Informationen und mit jedem Mental Model auch der Aufwand steigt alles aktuell zu halten. Es können schon einige Token-Kosten entstehen.
Jede retain-Operation bedeutet zusätzliche LLM-Calls für die interne Verarbeitung, das summiert sich bei hohem Volumen. Und der Reifegrad des Ökosystems ist noch nicht in Stein gemeißelt. Integrationen können sich relativ kurzfristig ändern.

Hier kommt es einfach darauf an ob man den Context/Memory auch als Wert für sich entdeckt hat.

Business-Ausblick

Für ein Projekt-Umfeld wie ich es bei valantic kenne sehe ich den größten Hebel darin, dass Agenten über Sessions hinweg Projektkontext, Kundenpräferenzen und getroffene Architekturentscheidungen behalten. Das bedeutet, dass weniger Zeit für wiederholte Kontext-Vermittlung, mehr Zeit für die eigentliche Wertschöpfung vorhanden ist. Das ist ein handfester Produktivitätsgewinn, gerade in längeren Projekten mit wechselnden Ansprechpartnern.

Gleichzeitig darf man die Governance-Frage nicht ausblenden: Wo landen die extrahierten Fakten, wer hat Zugriff auf die Memory-Bank, wie sauber lässt sich zwischen Kunden oder Projekten trennen? Self-Hosting via Docker beziehungsweise, wie in meinem Fall, im eigenen Homelab per LXC-Container ist hier eine valide Antwort – man behält die volle Kontrolle über die Daten, statt sie einem Cloud-Anbieter anzuvertrauen.

Fazit

Hindsight ist das erste Agent-Memory-System, das mich wirklich direkt begeistert hat, weil es Memory nicht auf "Text in eine Vektor-DB werfen" reduziert, sondern strukturierte Fakten, Entitäten, Zeitbezug und einen Wissensgraphen kombiniert. Das Setup im eigenen Homelab war dank vorhandener Postgres/pgvector-Infrastruktur überraschend unkompliziert, und die Kombination aus MCP-Standard und flexibler LLM-Provider-Wahl macht das System für sehr unterschiedliche Einsatzszenarien interessant – vom Vereinsalltag bei Wormatia Worms bis zum Architektur-Gedächtnis in technischen Projekten. Ich werde das in den kommenden Wochen weiter ausbauen und berichte, sobald sich daraus konkrete Workflows ergeben haben.

mage-remote-run mit JSON Body Support und anderen neuen Features

2026-06-25T07:00:00+00:00

Zwei Releases an einem Tag - das passiert, wenn Features bereit sind. Am 17. Juni 2026 haben ich v1.9.0 und v1.10.0 von mage-remote-run veröffentlicht. Das Highlight in v1.9: Virtual Commands unterstützen jetzt JSON Request Bodies — POST- und PUT-Requests gegen die Magento REST API sind damit ohne eigenen JavaScript-Code möglich. v1.10 bringt eine sauberere Plugin-Infrastruktur: Inkompatible Plugins werden jetzt beim Laden erkannt und mit klarer Fehlermeldung abgewiesen.

v1.9.0: Virtual Commands mit JSON Body, Choices und interaktiven Prompts

Virtual Commands sind seit v1.4 ein zentrales Erweiterungs-Feature: REST-Requests per Konfiguration definieren, ohne JavaScript schreiben zu müssen. Bisher waren sie auf GET-Requests beschränkt. Das ist jetzt Geschichte.

JSON Body Templates

Mit body in der Command-Definition lassen sich POST- und PUT-Requests direkt aus der Konfiguration absetzen. Der Body ist ein JSON-Template. Optionen werden als Platzhalter eingebettet und zur Laufzeit ersetzt.

{
  "name": "customer update-email",
  "method": "PUT",
  "endpoint": "/V1/customers/:id",
  "description": "Update customer email address",
  "body": {
    "customer": {
      "id": ":id",
      "email": ":email"
    }
  },
  "options": {
    "id": {
      "type": "string",
      "required": true,
      "description": "Customer ID"
    },
    "email": {
      "type": "string",
      "required": true,
      "description": "New email address"
    }
  }
}

mage-remote-run customer update-email --id 42 --email new@example.com

Damit öffnet sich die gesamte Magento REST API für Virtual Commands und eben nicht nur lesende Operationen, sondern auch schreibende Workflows, ohne eigenen Plugin-Code.

Die vollständige Dokumentation dazu findet ihr unter: mage-remote-run.muench.dev/extensibility/virtual-commands

Choices für Options-Definitionen

Optionen können jetzt vordefinierte Auswahlwerte bekommen. Das macht Commands benutzerfreundlicher und verhindert ungültige Eingaben:

"options": {
  "status": {
    "type": "string",
    "required": true,
    "description": "Order status",
    "choices": ["pending", "processing", "complete", "canceled"]
  }
}

Im interaktiven Modus erscheinen die choices als Auswahlmenü. Per CLI werden ungültige Werte direkt zurückgewiesen.

Interaktive Prompts für fehlende Pflichtoptionen

Virtual Commands fragen fehlende Required Options jetzt interaktiv ab anstatt mit einer Fehlermeldung abzubrechen. Das Verhalten hängt vom Kontext ab: Im Terminal erscheint ein Prompt, in CI/CD-Pipelines wird der Fehler wie bisher ausgegeben. Soweit möglich werden Variablen die bereits von CI/CD Systemen wie Gitlab-CI oder Github Actions standardmäßig definiert wurden (wie CI=1), automatisch erkannt, sodass der interaktive Modus nicht die Pipeline blockieren kann.

Für Pipelines lässt sich der interaktive Modus aber auch explizit deaktivieren:

NON_INTERACTIVE=1 mage-remote-run my-command
# alternativ:
NONINTERACTIVE=1 mage-remote-run my-command

Beide Environment-Variablen werden als Alias akzeptiert an das Homebrew-Konvention-Feeling für Shell-Scripting.

Weitere Änderungen in v1.9

Performance: Config-I/O läuft jetzt vollständig asynchron (fs.promises statt synchronem fs) — spürbar bei häufigen Profil-Wechseln
Performance: findRegisteredPluginIndex nutzt Promise.all für parallele Prüfungen
Fix: Verschluckte Fehler in Catch-Blöcken wurden repariert — Fehler sind jetzt sichtbar statt still ignoriert
Refactoring: Duplicated Filter-Matching-Logik wurde in parseFilterOption extrahiert
Deps: axios, zod, inquirer und @modelcontextprotocol/sdk auf aktuelle Versionen gehoben

v1.10.0: Plugin-Kompatibilitätsprüfung über peerDependencies

Plugins deklarieren seit v1.6 eine peerDependency auf mage-remote-run. Ab v1.10 wird diese beim Laden tatsächlich ausgewertet.

Wenn ein Plugin eine Version von mage-remote-run voraussetzt, die nicht mit der installierten übereinstimmt, bricht das Laden mit einer klaren Fehlermeldung ab — statt mit unerklärlichem Laufzeitverhalten.

Das ist das übliche Prinzip: explizit schlechter als stumm falsch. Wer Plugins entwickelt oder nutzt, deklariert die peerDependency in der package.json des Plugins:

{
  "name": "my-mage-remote-run-plugin",
  "peerDependencies": {
    "mage-remote-run": ">=1.10.0"
  }
}

Die Prüfung läuft beim Plugin-Laden — noch bevor Commands registriert werden. Inkompatible Plugins werden übersprungen und der Fehler protokolliert.

Update

npm update -g mage-remote-run

Oder direkt auf die aktuelle Version:

npm install -g mage-remote-run@latest

Feedback und Bugreports wie immer via GitHub Issues. Wer Virtual Commands produktiv einsetzt oder Plugins entwickelt... ich freue mich über Erfahrungsberichte.

valantic wird Anthropic Partner – und ich war dabei

2026-06-18T08:46:00+00:00

valantic ist offiziell Select Partner im Claude Partner Network (Services Track) von Anthropic geworden - eines der ersten Consulting- und Solutions-Unternehmen in Europa überhaupt. Ich durfte an diesem Prozess inhaltlich mitwirken und war selbst Teil der Schulung, die dazu notwendig war.

Was diese Partnerschaft bedeutet

Eine Partnerschaft mit Anthropic ist kein reines Marketing-Abkommen. Um Select Partner zu werden, muss man nachweisen, dass man die Materie wirklich versteht: Claude, das Anthropic-Ökosystem, die Architektur hinter Agenten-Systemen. Und man muss in der Lage sein, dieses Wissen weiterzugeben – intern an Kolleginnen und Kollegen, aber auch in Kundenprojekten und Schulungen.

Der Gedanke dahinter ist nachvollziehbar: Anthropic will sicherstellen, dass Implementierungspartner nicht nur Lizenzen verkaufen, sondern echten Mehrwert liefern. Das setzt voraus, dass die Leute, die Kunden beraten, wissen, wovon sie reden.

London: Schulung zum Trainer

Ein Teil dieses Nachweises war eine Schulung in London, die ich zusammen mit meinem Kollegen Alexander Weinfurter besuchen durfte. Das Ziel war klar: Wir sollten das Wissen erwerben, um andere zu schulen – sowohl intern bei valantic als auch für Kunden.

Inhaltlich war es ein intensives Format. Wir haben uns tief mit der Evaluierung von Prompt-Ergebnissen beschäftigt – ein Thema, das in der Praxis oft unterschätzt wird. Es reicht nicht, einen Prompt zu bauen, der auf den ersten Blick funktioniert. Man muss strukturiert messen können, ob ein Modell konsistent, korrekt und für den jeweiligen Use Case geeignet antwortet. Dafür gibt es Methoden und Frameworks, die wir in London durchgearbeitet haben.

Ein weiterer Schwerpunkt war das Erstellen und Deployment von Agenten in der Cloud. Es ging darum wie man KI-Agenten produktionsreif aufsetzt, welche Infrastruktur dahintersteckt und wo die typischen Fallstricke liegen. Das ist genau der Bereich, der in vielen Projekten über Erfolg oder Misserfolg entscheidet: nicht das Modell selbst, sondern wie es eingebettet und verwendet wird.

Wir haben außerdem verschiedene Anthropic-Modelle verglichen und ein Gefühl dafür bekommen, wann welches Modell für welchen Einsatzzweck sinnvoll ist.

Was mich persönlich am meisten gefreut hat: der direkte Austausch mit Anthropic-Mitarbeitern und KI-Architekten und meinem valantic Kollegen. Alexander war zum Beispiel viel besser in der Optimierung der Prompts. So lernt man gegenseitig. Man bekommt in solchen Formaten einen anderen Einblick als durch Dokumentation und Blog-Posts. Fragen, die man im Alltag nicht einfach stellen kann, lassen sich dort direkt klären.

Was das für Kunden bedeutet

Wenn ich mir die valantic-Seite zur Claude Implementierung anschaue, sehe ich genau das abgebildet, was wir in London erarbeitet haben. Der Ansatz ist nicht "KI einschalten und fertig", sondern ein strukturierter Prozess: von der ersten Sondierung über einen Pilot mit messbarem Business Case bis zum unternehmensweiten Rollout.

Besonders wichtig finde ich den Aspekt, den valantic explizit benennt: Viele Unternehmen scheitern beim Sprung von einzelnen Tests zur produktiven Nutzung. Nicht weil das Modell schlecht ist, sondern weil Strategie, Governance und Integration fehlen. Das deckt sich mit dem, was ich in Projekten erlebe. Die Technologie ist selten das Problem.

Als konkreten Einstieg bietet valantic Claude Code Workshops für Entwicklungsteams an – ein direkter, praxisnaher Weg in Anthropics agentische Coding-Fähigkeiten. Für Entwickler, die verstehen wollen wie KI-gestützte Softwareentwicklung in der Praxis aussieht, ist das ein guter erster Schritt.

Der Select Partner Status bedeutet außerdem: valantic hat direkten Zugang zu Anthropic-Expertise und -Roadmaps. Das ist in einem Bereich, der sich so schnell entwickelt, kein unwichtiger Punkt. Einen Vorsprung beim Zugriff auf Informationen oder Modelle ist gerade jetzt ein Wettbewerbsvorteil.

Fazit

Ich finde es gut, dass valantic diesen Schritt gemacht hat – und ich finde es noch besser, dass er mit echtem Substanz-Aufwand verbunden war. Eine Schulung in London, inhaltliche Auseinandersetzung mit Evaluierung, Deployment und Architektur, direkter Kontakt zu Anthropic. Das ist kein Badge auf der Website, sondern Grundlage für Projekte, die tatsächlich funktionieren.

Wer das Thema Claude im Unternehmenskontext ernsthaft angehen will, hat bei valantic jetzt einen Ansprechpartner, der weiß, wovon er spricht.

Google Cloud Summit DACH 2026

2026-06-15T08:25:00+00:00

Letzte Woche war ich für valantic beim Google Coud Summit DACH in Frankfurt. Die Anreise war entspannt: mit dem Deutschlandticket per Zug, klimafreundlich und ohne Parkplatz-Stress. Schon das Rahmenprogramm hat gesetzt, was den Ton für die zwei Tage vorgab – groß, professionell, durchdacht. Mehrere Tausend Teilnehmer, kostenfreie Veranstaltung inklusive Essen und Getränken. Google lässt sich das was kosten.

Tag 1: Der AI Experience Walk

Der erste Tag stand für mich im Zeichen des AI Experience Walk – einer Art begehbaren KI-Ausstellung, bei der Google seine Lösungen entlang der kompletten Wertschöpfungskette vorgestellt hat. Vom ersten Kundenkontakt bis zur internen Prozessautomatisierung war alles vertreten.

Google gab selbst Einblicke wie sich die Entwicklung aufgrund der Nutzung von KI geändert hat. Es gibt immer mehr Entwickler die nur noch mit Prompts arbeiten und die IDE selbst gar nicht mehr wirklich nutzen.

Was für mich imer wieder durchkam war, dass das Thema "Grounding" einfach viel ernster genommen werden muss. Über Tests gilt es die Ergebnisse (gerade in Verbindung mit eigenen Daten) immer wieder zu automatisch zu überprüfen. Das Test-Driven-Development ist wieder da aber eben anders wie früher.

Was mich am meisten beeindruckt hat: Live-Remote-Video-Übersetzung in 15 Sprachen, in Echtzeit, direkt im Video-Stream. Das war kein Demo-Video und kein "coming soon" – das hat funktioniert. Solche Momente zeigen, wo KI gerade wirklich steht. Nicht alles ist noch Versprechen.

Ein zweites großes Thema am ersten Tag war Digitale Souveränität. Das ist kein neues Thema, aber es war auffällig, wie prominent Google es platziert hat. Wer kontrolliert die Infrastruktur, wer hat Zugriff auf die Daten, wo laufen die Modelle? Für viele Unternehmen sind das inzwischen keine akademischen Fragen mehr, sondern konkrete Entscheidungskriterien bei der Plattformwahl.

Tag 2: Hands-on statt Hype

Tag 2 war für mich der wertvollere. Weniger Bühne, mehr Werkstatt. In den Hands-on Sessions konnte man direkt selbst ran – und das macht einen Unterschied.

Ich habe einen MCP Server live auf das Google ADK umgestellt – direkt auf der Veranstaltung, nicht vorher vorbereitet, nicht in einer kontrollierten Demo-Umgebung. Das hat funktioniert, und das war ein gutes Signal. Das ADK ist praxistauglich genug, um spontan damit zu arbeiten.

Besonders interessant war ein Vortrag zum Thema RAG (Retrieval-Augmented Generation) am konkreten Anwendungsfall: Gesetzestexte. Die Herausforderung bei juristischen Dokumenten ist nicht nur, die richtige Passage zu finden – sondern sie auch korrekt zu zitieren, mit Paragraphen-Referenz und im richtigen Kontext. Genau das wurde gezeigt. Ein Anwendungsfall, der echte Anforderungen hat und bei dem schlechte Ergebnisse echte Konsequenzen hätten. RAG muss hier nicht nur "meistens" funktionieren.

Google als einziger Full-Stack-KI-Anbieter

Eine Beobachtung zieht sich durch beide Tage: Google ist der einzige Anbieter, der Hardware, Software und Plattform für KI aus einer Hand liefert. Eigene TPUs, eigene Modelle (Gemini), eigene Cloud-Infrastruktur, eigene Entwicklertools. Das ist eine andere Ausgangssituation als bei Anbietern, die sich auf externe Chip-Hersteller oder Drittanbieter-Infrastruktur verlassen.

Ob das ein Vorteil ist, hängt davon ab, was man sucht. Wer tief in das Google-Ökosystem einsteigen will, hat eine konsistente Stack-Erfahrung. Wer Unabhängigkeit und Portabilität priorisiert, sieht das vielleicht anders. Ich finde es trotzdem bemerkenswert, dass kein anderer Hyperscaler diese Kombination in dieser Tiefe vorweisen kann.

Fazit

Zwei Tage, mehrere Tausend Teilnehmer, kein Eintrittsgeld. Google investiert sichtbar in Community und Sichtbarkeit – und das zahlt sich aus. Man verlässt so eine Veranstaltung nicht mit fertigen Entscheidungen, aber mit einem guten Gefühl dafür, wo die Reise hingeht.

Für mich persönlich: Tag 2 hat mehr gebracht als Tag 1. Nicht weil der AI Experience Walk uninteressant war – sondern weil Hands-on-Erfahrung durch nichts zu ersetzen ist. Einen MCP Server live umzustellen und direkt Feedback zu bekommen, ist mehr wert als zehn Folien über dasselbe Thema.

Wer die Möglichkeit hat, beim nächsten Google Summit dabei zu sein: lohnt sich.