Architektur-Update: Der Paradigmenwechsel in den Cernion Energy Tools (v0.54)
Vollständige Entkopplung von fachlicher Routing-Logik und Codebasis durch No-Code Routing via Agent Receipts.
🚀 Architektur-Update: Der Paradigmenwechsel in den Cernion Energy Tools (v0.54)
Mit dem Rollout der Version 0.54 vollziehen wir in den Cernion Energy Tools einen entscheidenden architektonischen Paradigmenwechsel: Die vollständige Entkopplung von fachlicher Routing-Logik und Codebasis.
Bisherige Architektur-Muster in KI-Agenten neigen dazu, geschäftskritische Routing-Entscheidungen (z. B. „Braucht diese Anfrage einen VNB-Lookup oder reicht eine geobasierte Suche?“) hart in den Code zu gießen. Das führt auf Dauer zu starren Pipelines und unnötigen Code-Anpassungen bei jeder fachlichen Nuance.
Das neue Paradigma: No-Code Routing via Agent Receipts Ab sofort wird die Ausführungslogik unserer Agenten ausschließlich über sogenannte Receipts orchestriert. Das bedeutet konkret:
🔹 Strikte Scope-Trennung statt Heuristiken:
Wir trennen semantisch scharf zwischen dem geografischen Raum (locationScope wie Ort/PLZ) und der fachlichen Marktakteur-Identität (operatorScope wie BDEW-Code oder MaStR-Netzbetreiber-ID). Eine PLZ löst nicht mehr blind einen VNB-Lookup aus, wenn lediglich lokale Wetter- oder Anlagendaten gefragt sind. Die Fachlogik diktiert die Tools – nicht umgekehrt.
🔹 Orchestrierung durch Scoring & Executable-Checks: Die Auswahl des richtigen Lösungswegs passiert nativ zur Laufzeit. Der Router bewertet anhand von Trigger-Terms, Context-Verfügbarkeit und Workflow-Typen, welches Receipt am besten zur Nutzerabsicht passt. Hardcoded Fallbacks gehören der Vergangenheit an.
🔹 Lifecycle-Management by Design:
Um redundante oder kollidierende Logiken zu verhindern, nutzen wir ein integriertes Versionierungsmodell. Neue Logiken werden als Drafts isoliert getestet und beim Rollout (Promote auf active) durch das supersedes-Feld nahtlos über die Vorgängerversion gelegt. Alte Receipts werden automatisch archiviert.
Das Resultat: Ein massiv beschleunigter Entwicklungszyklus. Wenn Routing-Tests fehlschlagen oder wir neue Edge-Cases abdecken wollen, fassen wir den Code nicht mehr an. Wir passen lediglich die Receipts über die API an. Das System bleibt stabil, die Fachlogik wird maximal flexibel und das Blackbox-Testing sauber skalierbar.