#171 Topic: Agent Harness Engineering

Plötzlich sprechen alle bei Agent Harnises, aber was ist das eigentlich genau? Warum erzielen unterschiedliche Koalingagenten mit den selben Modellen teils völlig unterschiedliche Ergebnisse, haben unterschiedliche Qualität und vor allen Dingen einen ganz unterschiedlichen Tokenverbrauch? Die Antwort, die ich tollficht nicht im Modell selbst, sondern in dem, was drumherum passiert, also dem Agent Harnis. In dieser Folge schauen wir uns an, wieso die Diskussion von Prompt Engineering über Kontext Engineering hin zu Harnis Engineering entwickelt hat. Hallo zusammen, wir schwitzen noch immer von unseren Mikrofonen, aber heißen euch ganz herzlich willkommen zu einer neuen Folge vom Tudukas, die wir diesmal früh am Morgen aufnehmen, damit es noch nicht zu heiß ist in unseren Studios und Arbeitszimmern. Ihr hört am Mikrofon den schwitzenden Malte, der das Intro gemacht, der ist normalerweise Strategic Solutions Engineer bei GitHub. Ich bin Robin Manuel Tiel, ich bin Director für AI und Cloud beim E-Commerce Software Unternehmen Jotel. Den Podcast hier machen wir aber, wie ist Drunger, da in den frühen Morgenstunden und daher privat und teilen aber trotzdem unsere Erfahrungen aus echten Kundenprojekten oder diskutieren die aktuellen Themen, die die Valopperwelt bewegen und das Thema ist diesmal Agent Harnis. Wir hatten tatsächlich schon länger überlegt, über dieses Thema zu sprechen, weil tatsächlich ist das seit einigen Monaten in aller Munde ganz viele Leute reden darüber und ganz passend hat in dieser Woche GitHub einen neuen Blockpost, genau zu diesem Thema veröffentlicht, indem sie beschrieben haben, wie ihr eigener Agent Harnis funktioniert und wie dann auch die Performance in den unterschiedlichen Large Language Models gegenüber den nativen Harnis ist, heißt im Vergleich zum Beispiel gegenüber Codex mit den Open AI Modellen und Cloud Code mit den Enthropic Modellen und da sieht man ganz deutlich in diesen Benchmarks und dieser Vergleich finde gar nicht so häufig statt, dass mit dem gleichen Modell je nach Harnis unterschiedliche Ergebnisse erzielt werden können. Das heißt teilweise sind die 3rd Party Harnis in dem Fall, wie zum Beispiel Gitter-Copalette, besser in manchen Fällen sind sie stechter, aber was vor allen Dingen überraschend war, ist das in vielen Fällen der 3rd Party Harnis einfach tocken effizienter war und ich glaube, das passt gerade zu der Diskussion und dementsprechend werden wir gleich auch noch ein bisschen tiefer darauf eingehen, aber vielleicht zunächst, wie kommen wir eigentlich dahin und warum haben wir noch vor ein paar Jahren über das Thema Harnis Engineering noch gar nicht gesprochen? Ich glaube wir haben vor allem dahin, weil wir vor ein paar Jahren da für die Modelle genommen haben, so wie die sind, das fing alles so an und war das, das muss ich mir so 20 2022, 2023, glaube ich, kamen so dieser Begriff Prompt Engineering auf und das wurde riesengroß auf einmal, waren Leute auf linkt in Prompt Engineers, Ham Koso angeboten, es gab Zertifikates, gab die ersten Firmen, die wirklich nur Prompt Engineers eingestellt haben und das kam dadurch, dass man da schon gemerkt hat, es gibt Leute, die bekommen aus dem selben Modell, damals war so Chat GPT, Absolute State of the Art und diese ersten GPT-Modelle von OpenMale. Da hat man gemerkt, da gibt es Leute, die bekommen aus dem selben Modell komplett andere Ergebnisqualitäten raus, indem sie es anders prompten, also indem sie den Prompt anders strukturieren, damals haben wir angefangen in den Prompt-Beispiele oder kleine so, ja, HTML oder XML separatoren einzubauen und die ganze, die ganze Industrie hat eigentlich darüber diskutiert, was macht einen guten Prompt aus, aber das haben wir noch ein winzig kleine Kontextfenster von 4000 Token und Chat GPT hat uns zu vereinzelner Antwort gegeben und es ging gar nicht in dieser Agent-Loop, aber wir haben damals schon gemerkt, okay, wenn man das Modell etwas anders anfasst, kriegt man wirklich siktendig viel ganz bessere Ergebnisse und da hat das das erste Mal eigentlich so angefangen, dass man nicht das Modell selber verbessert hat, sondern nachdem das Modell fertig trainiert war, dann ist es gut hinterher, wie kann ich denn da jetzt besser oder schlechte Ergebnisse hinaus locken. Ja und das war ja damals die einzige Möglichkeit, die ich als Enduser hatte, um wirklich Einfluss zu nehmen, das heißt, ich konnte eigentlich nur diesen Prompt beeinflussen und das ganz hattig ein paar Jahre später verändert, also so circa 2024 als die ersten komplexeren Systeme kamen, insbesondere die ersten Coding Agents, die wirklich für mich Software entwickelt haben, aber auch Agents in anderen Bereichen, die für mich Aufgaben erledigt haben, wo ich mit dem Bereich des Kontext angefangen habe zu arbeiten. Das heißt, wir haben gemerkt, dass nicht nur der Prompt, den ich initial in diesen Agents gebe, darüber entscheidet, welches Ergebnis und wie gut das Ergebnis ist, sondern wir haben halt auch gemerkt, dass wir zusätzlichen Kontext bereitstellen müssen, der dem Agenten ermöglicht, genau das Ergebnis zu erzeugen, was wir haben wollen, das haben wir in der Software Entwicklung gemacht, indem wir zusätzliche Dateien hinzugefügt haben, indem wir genau Ordner spezifiziert haben, indem wir vielleicht Custom Instructions oder Agency-MD-Files geschrieben haben, aber natürlich haben auch die Agenten selbstständig bestimmte Informationen zu diesem Kontext hinzugefügt, zum Beispiel über Tools, die Möglichkeit hatten, auf das Dateisesthin zurückzugreifen oder eine Wäktor-Datenbank, wo ich tatsächlich Informationen abrufen kann, sie mannthische Informationen und in Kombination mit größeren Kontext-Fenstern hat das natürlich weitere Möglichkeiten eröffnet, wie man aus diesen Latch-Language-Models wirklich besser Ergebnisse rausziehen kann. Das kann mit allem aus einer Zeit wirklich diese Agents aufkommen, also das erste Mal Dinge, die einfach nicht nur ein Prompt oder ein Output fahren, sondern Agenten, die selber in einer Agent-Loop gelaufen sind und dann noch fallen über sowas wie Ragn, also Retrieval-Ogmented Generation haben wir mal eine eigene Folge zugemacht, was genauer eigentlich dahinter steckt, sich halt dynamisch neue Informationen nachladen können. Und dann war so Kontext-Engineering in aller Munde, wir müssen schauen, dass wir diesen Kontext mit unserem System Prompsen sowas möglichst gut von vorne rein bestücken, aber dann auch den Agenten die Möglichkeiten geben sich selber den Kontext nachzuladen, kam auch vor allem dadurch, dass die Modelle besser wurden und wir diese größeren Token-Fenster hatten, in denen wir einfach auch viel mehr Kontext reinladen konnten für die Modelle und dadurch längere Tasks möglich waren. Wir haben sowohl zu Kontext-Engineering als so zu Ragn, jeweils eine eigene Folge gemacht, wenn ihr da noch mal tiefe einsteigen wollt. Inzwischen haben wir natürlich viel größere Kontext-Fenster in den Latch-Language-Models, das heißt, wir haben die Möglichkeit, da auch immer mehr Informationen mitzugeben. Wir müssen uns aber natürlich, und da haben wir in einer der letzten Folgen darüber gesprochen, darüber bewusst sein, dass im Laufe der Zeit natürlich die Informationen im Rahmen so eines Agent-Lutes immer weiter anwachsen und am Ende vielleicht auch komprimiert werden. Und dementsprechend ist es natürlich wichtig, zu verstehen, wie funktioniert letzten Endes der Agent unter der Haube. Also wie ruft er das Latch-Language-Model ab? Wie greift er auf Tools zu? Wie ruft er Sap Agents auf? Die dann über verschiedene Möglichkeiten uns helfen bessere Ergebnisse zu erzielen, weil sie halt nicht immer das komplette Kontext-Window in das Latch-Language-Model sein werfen, um dann ein Ergebnis rauszuziehen, sondern wirklich viel Präziser bestimmter Aufgaben auch delegieren können. Und da kommen wir dann an den Punkt, wenn wir das Ganze betrachten und anfassen, dass wir da über einen Harnesprechen oder den Prozess des Harnes-Engineeringes, wo wir halt dieses Ganze darum herum bauen und selber dann beeinflussen, um die besten Ergebnisse zu erzeugen. Ja, und das gibt dadurch, dass wir eben, als wir dann dieser Agent-In-Gebaut haben, auch ein Strecht schnell gemerkt haben, dass die oft so halbfertig waren. Weil ich hatte schon gesagt, Kontext war dann irgendwie komprimiert und wir brauchen also irgendetwas, was diese Agenten etwas einfängt. Jetzt nicht so frei drehen, lässt die Abund zu wieder in die richtige Richtung schickt. Und wir haben ja auch mal eine Folge über die Ralfloop gemacht, also dieses Ralf-Engineering und das war schon so ein erster Ansatz, dass man einen Agent nimmt und den halt einfach so lange in so eine Wild True Schleife steckt, bis der sein Ziel erreicht hat. Heißt eigentlich immer, wenn der Agent fertig war, haben wir die noch mal selber gepromptet und gesagt, ja, bist du denn wirklich fertig, guck dir nochmal an, was war denn die Ursprungsaufgabe, was aus du in der Zwischenzeit produziert, passt das dann noch zusammen. Und das hat dann immer so ein frischen Kontext gestartet. Und das ist eigentlich schon ein kleiner Harnes. Da kommen wir gleich noch mal zu, was genau das ist, weil der so ein bisschen die Rahmenbedingungen absteckt und sagt, egal wie frei du drehst, die bargänth, am Ende wirst du eh wieder von vorne neu gepromptet. Und das hat jetzt eigentlich in 20/26 nochmal ganz nochmal viel stärkere Ausmaße genommen, weil jetzt gefühlt alle über Harnes-Engineering sprechen und auch zeigen, was sie damit für noch mal gut haller Ergebnisse herzielen. Ja und vielleicht für diejenigen, denen der Begriff so nicht bekannt ist, der Begriff Harnes bedeutet so viel wie irgendwie Zaunzeug, Geschirr oder Zügel. Und man kann sich das quasi so vorstellen, wenn das Ladschlangwitsmodel irgendwie dein Wildfährt ist, was super mächtig ist. Es kann super gut bestimmte Aufgabe ledigen, nämlich in eine Richtung laufen, springen, etc., nur mit dem richtigen Zaunzeug, hast du wirklich als Reiter etwas davon, weil du damit das Ladschlangwitsmodel in die richtige Richtung steuern kannst. Du kannst bestimmt wann springt das Fährt, wann geht es links, wann geht es rechts. Und genauso ist es natürlich mit dem Ladschlangwitsmodel, wenn du einfach nur einen Promt reinwärfs, dann macht das Modell irgendetwas damit. Aber wenn du letzten Endes genau diese iterativen Steuerungssysteme darum baust, dann baust du diesen Agent Harnes so, wie du das gerade beschrieben hattest. Ich glaube diese Analogie mit dem. ein Zaumzeug des Pferdes macht es ganz gut deutlich, gerade wenn man Pferd hat, was sehr stark ist, aber vielleicht seine eigenen Fähigkeiten auch nicht ganz unter Kontrolle hat. Da müssen wir aber auch fähre, glaube ich, das in der Industrie auch noch alle unter Harnis Engineering oder unter dem Harnisten was anderes verstehen. Ich teile das, was der Maltegarde gesagt hat, auch meine Auffassung. Selbst Leute, die Agenten bauen und selber so ein Harnis bauen, kommen da, glaube ich, immer wieder an so ein paar andere Punkte. Was ist es eigentlich? Was ist es nicht? Ich glaube, es ist kein klar definierter Begriff. Also wundert euch nicht, wenn ihr davon vielleicht sogar noch nie gehört habt oder wenn ihr da unterschiedliche Definitionen lehst, das formt sich gerade noch ein bisschen. Aber es ist nicht weg, du diskutieren das so ein Harnis überall da. Also, vielleicht mal, wenn du es irgendwie Claude Code zum Beispiel, da hast du ja auch einen Harnis. Also da hast du was, was dieses Claude Modell nimmt und Claude hat ja ihr eigenes Claude Code Agent SDK drum rum. Und das ist eigentlich fast schon der Harnis. Also genau diese Dinge, die dem Modell, die Tools dann zuschustern, die dem Modell sagen, hey, du wirst es hier im Rahmen von einer Software Developer-Aufgabe, die schauen, ob die regelmäßig checken, ob das Modell vielleicht irgendwohin abgedürftet ist, die aber vielleicht kontrollieren, dass das Modell Dinge nicht macht, die gar nichts mit Software-Enginien zu tun haben. Und wir können natürlich auch unseren eigenen Agenten bauen. Und auch da unseren eigenen Harnis oder unsere eigene oder auf dem bestehenden Harnis aufbauen. Und das ist wahnsinnig wichtig, weil es jetzt immer mehr Leute gibt, die auch durch Research und durch einen gut konferierten Harnis feststellen, dass sie da durch End-Wider die Performance eines bestehenden Modells erweitern können. Es gibt einen Blockpost von "Ziven" heißt ja auf "X", den verlinken wir unten mal, der hat quasi sich den System prompt, den geliebten System prompt von Claude Fable 5 genommen. Und den an Opus 4/8 gestickt und ein Harnis drumrum gebaut, mit dem er sagt, ich habe mir eigentlich Claude Fable 5 leid gebaut und weil jetzt so eine ähnlichen Performance gekommen ist. Und solche Sachen sieht man jetzt immer wieder, dass der Harnis, also das Ding, was das Modell nachher steuert, in die richtige Richtung schubst, fast schon so zu, ich würde sagen, zu 50% dafür verantwortlich ist, ob das Ergebnis gut ist und dass Modell selber nur die anderen 50% hat. Und deswegen sprechen gerade alle über Harnis-Engineering, wenn man damit noch mal richtig was rauskitzeln kann. Und ich glaube, das ist gerade von zwei Seiten relevant für uns, die wir irgendwie in der Software-Entwicklung sind, ist es relevant, weil wir natürlich Agenten nutzen, um Software zu entwickeln. Aber selber entwickeln wir natürlich auch agentische Systeme, die dann am Ende von jeder Mann, jeder Frau verwendet werden. Ich glaube ganz simpel gesagt, wenn man heute mit Claude oder ChatGPT arbeitet, man nicht mehr mit einem einfachen Chat-Boot, man arbeitet mit einem agentischen System, weil diese auch Aufgaben erledigen können. Sie machen Internet Research für mich, sie generieren, Powerporn-Präsentationen, Bilder, etc. Und dahinter steht natürlich auch der entsprechende Harnis, den diese Anbieter gebaut haben, rund um das Large-Ladschlengwutschmodel. Und ich glaube, man kann die, wenn wir sagen, wenn wir das Large-Ladschlengwutschmodel als den Motor haben, dann haben wir den Harnes außen rum, als den Rest des Autos, der halt die pure Energie, das Motor ist dann in die richtige Richtung längt und dafür sorgt, dass wir halt davon profitieren können, dass wir von Anachbekommen unser Ziel erreichen. Und nicht nur, wo ich bei viel Energie verbrauchen, um irgendwie beliebigen Output und Wärme zu erzeugen. Und ich glaube, es wird hier auch zu sagen, wenn wir Harnes selber, das ist kein Framework, wie irgendwie Lengchain, QAI oder Autogen, sondern mit diesen Agent Frameworks, mit denen bauen wir einen Harnes, oder die können wir verwenden, um unseren Harnes zu konfigurieren. Aber so eine richtigen Harnes gibt es nicht wirklich, als SDK runterzuladen, sondern wir müssen selber bauen, wenn wir einen Agent bauen. Weil das ist ja immer anders. Also, ich komme, das kommt ja auch immer komplett drauf an, was man agentun soll, dann braucht man auch nur unterschiedlichen Harnes, um in diesem Tas besonders gut zu performen. Und das ist quasi was in der Laufzeitumgebung von Agenten in Produktion. Wichtig ist, auch man muss unterscheiden, dass Wort Harnes gab es schon mal in dieser ganzen Machine Learning Welt. Ein Machine Learning Harnes ist nicht das selbe, aber ein AI Harnes. Ein Machine Learning Harnes ist eigentlich so, man kann sagen, eine Test Suite für Modelle. Und der AI Harnes ist genau in dieser Laufzeitumgebung, der die Modelle in die Richtung schubst. Und das kennen wir auch alle aus Freierbildbahnen, Klot Code, Codex Cursor, GitHub Co-Pilot. Die haben alle ihre eigenen Harnes. Und das ist auch der Grund, warum die teilweise mit den selben Modellen, also gerade im Fall von Cursor und GitHub Co-Pilot, kann man sich die Modelle ja aussuchen. Ganz andere Ergebnisse liefern für verschiedene Aufgaben, obwohl das Modell dahinter genau das selbe ist. Und so ein Harnes, den kann man natürlich auch selber bauen. Man kann einen eigenen Co-Dingangenten bauen für sehr spezielle Anwendungsfälle oder wenn die eigene Software sehr komplex ist. Haben wir bei JTL zum Beispiel auch hitzen Fall. Da hat einer unserer Mitarbeiter genauso was gebaut für ein ganz bestimmtes Produkt. Das muss man aber nicht von Grund auf selber machen. Kann man natürlich aber die offiziellen Agent SDKs, die können natürlich auch hier ein Harnes Startpunkt sein. Es gibt ja von eigentlich fast allen Herstellern, von GitHub Co-Pilot gibt es das Agent SDK. Von Entroppi gibt es auch deren Agent SDK Cursor, hat auch eins. Das heißt, da kann man auch schon diese Agent SDKs nutzen. Weil ich ja weiß zumindest schon mal, das macht zumindest schon mal aus einem generischen Modell einen Co-Dingagent. Und dann kann ich da drunter rum auch noch mal meine speziellen Harnesanforderungen reinprogrammieren. Ja und tatsächlich wird das genau mit diesen Agent SDKs der verschiedenen Anbietern umgesetzt. Wenn man sieht, dass es zum Beispiel in GitHub nicht nur den GitHub Co-Pilot Agent gibt, sondern auch den Codex Agent und den Cloud Agent. Das sind nämlich coding Agenten, die auf Basis dieses SDKs gebaut wurden, des entsprechenden Anbieters. Das heißt, man sagt halt, wir haben das gleiche Ladschleggmodell, zum Beispiel irgendwie Cloud Sonnet 4.6. Und lassen uns einmal im Co-Pilot Harnes laufen und einmal im Cloud Harnes und haben dementsprechend unterschiedliche Ergebnisse, weil natürlich Entroppi vielleicht die andere Gedanken gemacht hat als GitHub. Und dann wiederum auch der anderen Seite gibt es genau den gleichen Vergleich auf der Open-Ai-Seite, wo natürlich mit Codex auch versucht, wie er den möglichst guten Harnes zu bauen. Und ich glaube ganz wichtig ist, im Hintergrund zu haben, dass man den Harnes natürlich entweder auf ein bestimmtes Modell optimieren kann. Und das machen natürlich die Anbieter der Modelle sehr gerne, dass sie halt ihren Harnes so bauen, dass er mit ihrem eigenen Modell am besten performt. Weil es da eigentlich in der Regel gar keine Modell-Javariance gibt. Natürlich, wenn ich bei Enfropic bin, kann ich zwischen der Opus-Familie irgendwie der Sonnet und Heiko-Familie wählen. Aber es ist halt nicht so, dass ich jetzt plötzlich irgendwelche Open-Wait-Modelle sich jener unterstützen muss oder vielleicht die Modelle der Konkurrenz. Und das sieht natürlich bei dem Harnes von Kurser oder GitHub-Copilot anders aus, weil dort natürlich die Harnes so flexibel sein müssen, dass du quasi, ich bin ich sagen, ein beliebiges Modell, sondern dass du halt unterschiedliche Modelle quasi reinstöpst sein kannst und trotzdem gute Ergebnisse oder die bestmöglichen Ergebnisse für dieses Modell erzielen kannst. Und diese gleichen Gedanken muss ich mir natürlich auch machen, wenn ich mein eigenen Harnes für meine eigene Abtikation oder meine eigenen Agenten-Bauer, den ich anderen User zur Verfügung stelle. Also wenn ich jetzt zum Beispiel auf das SDK von Enfropic zurückgreife, muss mir bewusst sein, dass das natürlich optimiert wurde für die Enfropic-Modelle. Und wenn ich jetzt vielleicht einen eigenen Agenten-Bauer der Multimodellfähig sein muss, dann nehme ich entweder einen SDK von einem Anbieter, der auch Multimodellfähig ist, oder ich muss mir wirklich Gedanken machen, wie baue ich komplett von scratch mein eigenen Harnes. Weil wir hatten ja gerade in der Folge über Mythos darüber gesprochen, dass wir oder es war die Folge über Fable im engeren Sinne, dass wir vielleicht uns in Zukunft Gedanken darüber machen müssen, was passiert, wenn die Modelle eines bestimmten Anbieters wegfallen. Und jetzt stelle ich mir vor, ich baue es an Agent Harnes, der es auf eine bestimmte Modellfamilie optimiert, und dann fällt diese weg. Da muss ich natürlich viel Reengineering da reinstecken. Und dementsprechend ist es vielleicht auch sinnvoll, von vorne rein, ich will nicht sagen, Modell agnostisch zu arbeiten, aber zumindest diesen Multimodell-Approach im Kopf zu haben und mich nicht zu sehr beim Harnes an die quasi die Eingaben und Ausgaben eines bestimmten Large-Tenglutschmodels auch zu binden. Okay, jetzt haben wir schon viel geredet, warum man das braucht. Und was es um die Gruppe ist, aber das war alles sehr abstrakter, was wir machen können. Was ist denn jetzt genau in so einem Harnes drin, was brauche ich, denn für einen guten Harnes? Und das Herz davon ist eigentlich die Loop, die so while Loop, so ein bisschen ähnlich wie die Ralf Loop oder eigentlich haben wir sie so ein bisschen die Agent Loop. Was das Modell eigentlich macht in Eterationen, bis es zu einem Output kommt. Das heißt, das Modell geht hin, liest den System prompt, Welt-eventuellen Tool aus, was es ausführen möchte, um das Problem zu lösen, das Tool läuft, das Tool spielt das Ergebnis zurück in den Kontext, der magente oder das Modell in dem Fall entscheidet, ob es mit dem Output zufrieden ist und weitermachen, weil sie dort auch wieder von vorne starten will. Also vielleicht noch mal ein zweites Tool aufrufen möchte, weil das erste Empfehler geliefert hat oder weil das erste noch eine Leseoperation war und nicht dann eine Schreibbiterration darauf folgen lassen möchte. Und diese ganze Loop, das das Modell eigentlich hingeht und für sich erstmal versucht herauszufinden, wie es zum zu lösen, das Problem kommt. Das ist das eigentlich das Herz, diese große Eten-Schleife. Und hier kann schon die ersten Harnes Sachen reinkommen. Ich kann zum Beispiel eine maximale Anzahl an "Iteration" ist da rein programmieren als "Guardrake". Und es läuft das Ding teilweise bis zur privaten Sauerlandsdurch und verbrennt Tokens. Also könnt ich so wie ich sagen, wenn du das Ding nach zehn Interationen oder nach so und so viel Tool calls nicht gelöst hast das Problem, dann musst du zurückkommen zu deinem Menschen oder dem oder wer auch immer dich ja wenn du gepromptet hat und musst dir eingestehen, dass du diese Richtung nicht weiterkommen kannst. Oder ich könnte da ja auch als Interation auch irgendwie einbauen. Pass auf, du versuchst immer erst mal in dieser Wild Loop vielleicht ein kleines Modell zu verwenden und wenn du dann nach fünf sechs Interationen merkst, dass das nicht stark genug ist, dann kannst du auf dem größeres Modell wechseln und all solche Dinge, also diese alle Dinge, die diese Schleife beeinflussen. Damit fängt es eigentlich immer an, das war so das erste, wo man Agenten gebaut hat und diese Loop, das Herz eigentlich von unserem Agenten, das ist so der erste Bestandteil von einem Harnis wie baue ich die auf, wo limitiere ich die, was darf, wie lange darf so modeluten, all diese Dinge. Ja und der zweite Bereich der ganz wichtig ist, das hatten wir gerade am Anfang auch schon angesprochen, das ist das Thema Context Management, also wie stellen wir den Kontext für den Agenten zusammen? Das heißt was ist der User-Input, was haben wir vielleicht an irgendwie Custom Instructions, die wir reinladen müssen, was wurde vielleicht zusätzlich über andere Werkzeuge auch automatisiert bereitgestellt und wie können wir diesen Kontext dann nicht nur an das Large-Language-Model weitergeben, sondern wie können wir auch dafür sorgen, dass der Kontext nicht vollläuft. Und da gehört natürlich die ganze Kompaktierung oder Komprimierung des Kontextes dazu, jedes Large-Language-Model haben wir heute darüber gesprochen, hatten maximales Kontext-Window und wenn wir dann irgendwie 80, 90 Prozent des Kontext-Windows erreicht haben, müssen wir unseren Kontext komprimieren und dabei müssen wir natürlich darauf achten, dass wichtige Informationen erhalten bleiben und so ähnlich wie im menschlichen Erinnerungsvermögen irgendwie die wichtigen Dinge hoffentlich hängen bleiben und die unwichtigen Dinge wegfallen, weil natürlich die kognitive Leistungsfähigkeit eines Menschen ja auch begrenzt ist und wir sind glaube ich extrem gut da drin, als Menschen zu filtern und bestimmte Dinge einfach zu vergessen, die unwichtig sind und uns auf die wichtigen Dinge zu konzentrieren, aber das muss ich für so einen coding Agenten natürlich als die Wallerpa im Rahmen meines Harnes das implementieren, weil das schlimmste was passieren kann ist das wichtige Informationen fehlen durch die Komprimierung und dann natürlich haltwärtig Ergebnisse erzeugt werden, vielaftere Ergebnisse erzeugt werden und dementsprechend ist diese Thema Kontext-Window natürlich auch kontext-Window-Management natürlich auch extrem wichtig. Dazu kommen dann das ganze Thema Skills und Tools natürlich, also ah, kann ich denn überhaupt Tools an meinen Agenten ranflaunchen, das ist meistens über MCP ganz gut gelöst, es gibt aber auch natürlich eingebautet Tools, die solche Agenten haben, die sind auch Teil des Harnes, also universelle Sachen wie du das Dateienlesen, Schreiben, Bachel, kommandos ausführen, eine Suche auf dem Dateisesystem ausführen. Eventually kann mein Agent ja mit Skills arbeiten, das sind dann oft Themen oder teamspazifisches Wissen, vielleicht habe ich ja auch schon bestimmte Skills mit eingebaut, so Bild ins Skills, die auch auf der Box kommen irgendwelche Navigation durch den Code oder higher Levels gilt wie "Hey, wie mache ich eigentlich einen Git-Commit, wie öfter man einen Polic-West-Solche-Informationen können ja dem Agenten schon mitgegeben werden, wie arbeiten wir eigentlich bei uns in der Firma. Das ist wenn ich einen generischen Agenten nehme oft Teil des System-Proms, aber wenn ich genau beschreiben möchte, wie soll dieser Agent einen Polic-West-öffnen, dann kann ich das natürlich auch schon in diese Bild ins Skills mit einbauen. Das heißt, dieses ganze Thema, wie oft dürfen Tools aufgerufen werden, wie komme ich an die Authentifizierung von diesen Tools, gibt es bestimmte Tools, die ich blocken möchte für meinen Agenten, möchte ich überhaupt, dass mein Agent erweitert werden kann durch alle möglichen beliebigen Tools, wo kommen die her, das sind auch alles Teile des Harnes ist. Ja, nicht was das, im letzten Jahr neu dazu gekommen ist, ist das ganze Thema "Supp-Agent Management" und das finde ich extrem spannend, weil natürlich ein Agent ist quasi Single Threaded, aber wenn wir jetzt mit "Supp-Agenten" arbeiten, können wir Dinge auch parallelisieren. Da haben wir verschiedene Vorteile, aber wir zum einen halt vielleicht mit einem sehr frischen Kontext-Fenster anfangen können, weil die Aufgabe kleiner beschnitten ist und gar nicht der komplette Kontext notwendig ist. Und diesen Life-Cycle des "Supp-Agenten" muss man natürlich managen, man muss dafür sorgen, dass diese gestartet werden, dass diese ihre Aufgabe erledigen und dann natürlich am Ende der Ergebnisse auch wieder eingesammelt werden, um dann wieder quasi in diesen Hauptagenten zurückzukommen, der am Ende seine Aufgabe erledigen müssen, das heißt wir müssen den "Supp-Agenten" starten, wir müssen dafür sorgen, dass ihre Aufgabe erledigen und dann die Informationen zurückholen. Und das ist natürlich etwas, was dann in dem Agent Harnes des Hauptagenten passiert und dementsprechend können wir damit vor allen Dingen die Erledigung von Aufgaben massiv beschleunigen. Dann kommt natürlich auch so was wie Persistenz, vor allem für so Sessions oder so Memory Management dazu. Vielleicht will ich ja, dass mein Agent sich an bestimmte Unterhaltungen erinnert, dass er quasi irgendwo Markdown oder Jason Datein auf einer Festplatte oder auf irgendeinen Cloud-Speicher ablegen kann. Dazu gehört aber auch, dass was ist denn, wenn mal der Prozess crashed oder mein Loop mal irgendwie zu keiner Margätnis kommen, kann man da gerne sich vielleicht irgendwo Zwischenergebnisse abspeichern, wie es ein Back-Up. Das heißt, ich kann ein Replay von einer Agent-Session machen, bis zu einem gewissen Punkt oder kann ich eine Unterhaltung aus irgendwo forkeln und sagen, dass auch von hier mal, lässt jetzt mal zwei Agenten parallel laufen und welts am Ende einen Gewinner aus und die schreiben beide aber wieder ihre jeweiligen Zwischenergebnisse irgendwo hin, sodass ich das Ganze auch pausieren kann oder den anderen oder halt so diesen Gedankenvorgang von der Margänten nachvollziehen kann. Und da kann ich natürlich verschiedene Entscheidungen treffen, möchte ich das, sollte er überhaupt irgendwas persistieren können. Ist das vielleicht sogar kontraproduktiv, welche Dinge kann er persistieren? Wie kann er sie persistieren? Kann er die persistierten Sachen noch wieder löschen? All das sind Gedanken, die ich bewahren muss über so Session Persistence und Memory, wenn ich ein Harnis bau. Und dann haben wir noch ein Bereich, der es relativ nah in diesem Kontext Management, aber einige Leute haben da wirklich einen eigenen quasi Bereich draus definiert und das ist dieses System Prompt Assembly. Wir können ja den System Prompt, der in der Regel durch den Anbieter von einem Chatboard oder AI Tool fest koniert wird, gerade über den geliegten System Prompt von Fable gesprochen und dieser System Prompt wird natürlich erweitert durch die Informationen, die ich quasi immer mitgeben möchte, über einen Agents-MD-File, Cloth-MD-File oder andere Instructions, die dann immer quasi dazu gepackt werden. Und ich hatte natürlich dann einen statischen Teil und einen dynamischen Teil und werden gerade beim Thema Token Optimization schon darüber gesprochen, dass wir an der Stelle natürlich aufpassen müssen, dass wir nicht zu viel Dynamik früh in diesem Kontext-Fenster reinbringen, weil wir dadurch natürlich das Prompt Caching aushebeln würden, was uns der Model Provider anbietet, um die Kosten zu reduzieren. Das heißt, wenn man sagt, okay, dieser Teil der Logik, den wollen wir jetzt eigenen Bereich zusammenfassen, würden wir das als System Prompt Assembly-Teil bezeichnen. Als nächstes mache ich mir Gedanken über, bis wir mal Erweiterungen, die man in meinem Agent noch mal mitgeben kann. Viele Agenten, ihr kennt das irgendwie von Cloth-MD-File, die haben so pre-Tool, Hook und Post-Tool, Hook und alle möglichen Hooks, wo ich mich dann selber noch mal mit der Kastelmlogik reinhängen kann. Also der Agent sagt, drüberliegenden Systemen, in dem er läuft, eigentlich Bescheid, ich bin jetzt dabei, ein Toolkoll zu machen. Viele Agenten haben dann einen jungen In-The-Loop-Feature, wo Sie zu welchem ich sagen könnte, dass muss der User mir nochmal bestätigen oder einen Post-Tool Hook, wo der Agent sagt, ich habe jetzt eine Anfalt von den Tool bekommen, bevor ich das jetzt an das Model weiterleite. Hier könntest du nochmal Kastelmlogik hinterlegen. Hier könnt ich dann einen Audi machen, ob das, was ist, was vielleicht Schatt, wo er schätig Informationen beinhaltet, dann will ich das nämlich nicht an den Agenten weitergeben. Oder ich mache hier ein bestimmtes Logging, da ich sage, ich lockt auf jeden Fall dieses Toolergebnis einmal weg. Also ich muss immer gucken, wo in diesem Lebenszyklus von meiner Agenten will ich mich reinhängen, um noch vielleicht Kastelmlogik auszuführen. Vielleicht will ich aber auch die Möglichkeit geben, dass wenn man Agent vielleicht wirklich an andere User ausgeliefert werden soll, dass man eben genau da nochmal das Verhalten des Agenten auch steuern und erweitern kann. Und zu guter Letzt ganz wichtig, natürlich der Bereich Berechtigung und Sicherheit und wir kennen das alle von diesen Agenten, die dann relativ früh versuchen, irgendwelche Operationen auf meinem localen System durchzuführen. Zum Beispiel Dateien zu lesen, komandos auszuführen, wirklich Tools, Bash Tools zu verwenden. Und das Ganze muss natürlich gesteuert werden. Wir können es auf verschiedenen Ebenen betrachten. Wir können sagen, okay, wir haben nur Read Only Zugriff. Wir haben Zugriff auf den Workspace. Das haben wir gerade so ein IDE häufig gesehen, wo wir so ein Workspace laden. Und wenn wir dann in Agenten haben, kann dieser Agent per default nur auf den Workspace zugreifen und nicht auf das komplette Dateisystem. Bei CLI-basierenden Agents haben wir teilweise dann ein anderes System, wo sie wirklich full Access haben auf das gesamte System. Und wenn wir den Agenten haben, der vielleicht gar kein Coding Agent ist, sondern so etwas wie OpenClaw oder Hermes, dann müssen wir vielleicht auch so ein Full System Access erlauben, weil dieser Agent natürlich mit den ganzen System arbeiten können soll. Und wir können das Ganze dann auch innerhalb der Tools klassifizieren, da ich bestimmte vielleicht Lush Operationen nur in einem bestimmten Bereich machen oder da ich theoretisch die gesamte Festplatte löschen oder braucht es eine Prove von dem die Wallopper auf bestimmten Tools, die ausgeführt werden, aber auf andere nicht. Häufig ist so, dass diese Agenten auch quasi die die diese Erlaubnis dann vorab einholen können. Es gibt ja diesen berühmten Jolo Mode, den ich in den verschiedenen Coding Agents aufverwendet kann, wo wir quasi vorab so ein Approval geben und sagen, hier du das alles machen. In der Regel sollten wir das natürlich nur machen, wenn wir in der isolierten Umgebung laufen und nicht auf unserem kompletten System mit den kompletten Wächten arbeiten. Aber genau dieser Bereich Permissions and Safety ist natürlich extrem wichtig. Und da kommt natürlich mit dem Agent Harnis einiges mit. Teilweise müssen wir da rum noch was bauen, um sicherzustellen, dass selbst wenn der Agent dann quasi in diesem Harnis nicht reglementiert wird, dass er keinen Unsinn macht, da kann man über Sandboxing reden oder das war ein Thema für eine zukünftige Folge vielleicht. Aber natürlich in diesem Harnis muss das Ganze gesteuert werden. Wir kennen es aus selbst aus einfachem Chat GBT oder Clots in Ahring, wo wir einfach zwischendurch mal gefragt werden. Und dann möchtest du Folgendes machen oder ich hab's nicht richtig verstanden, soll ich jetzt eine Internet-Suche machen und dann der User-Lesten Endes gefragt wird. Wichtig ist aber auch, dass man jetzt nicht all diese Dinge sofort einbauen muss, wenn man selber so ein Harnis bauen. Also man muss um einen Harnis zu haben oder selber zu bauen. Muss man nicht alles davon einbauen. Gerade diese Security-Sachen sind schon Dinge, über die ich mir auf jeden Fall auch Gedanken machen würde, wie frei darf meiner Agenten eigentlich drehen, wo er auf der Zugriff. Aber man kann natürlich A erst mal die Start-Akits von den Herstellern nehmen und B kann man sich natürlich auf die Dinge fokussieren, die jetzt für den eigenen Newscase besonders wichtig sind, wenn man sich so einen eigenen Agent und damit auch einen eigenen Harnis baut. Wir haben das zum Beispiel bei JTL gemacht. Wir haben einen Mitarbeiter gehabt, der in einem Team arbeitet, die eine sehr komplexe Software. Über viele, viele Millionen Seilencode, da gibt's mehrere, sich tausend verschiedene Klassen drin, ganz viele verschiedene Datenbanktabellen arbeitet und dafür haben wir eine extra eigenen coding-Agenten gebaut, der wirklich eigentlich gefeintugend kann man schon sagen, ist auf dieses eine hochkomplexe Projekt, der sich dann Tools zur Rate zieht, die wir extra dafür gebaut haben, nämlich wie so eine Knowledge Graph über den Sourcecode. Das ich weiß, okay, wenn ich diese Klasse hier anfasse oder wenn ich diese Methode veränder, das hat das denn alles für Auswirkungen in meine Software, welche Datenbanktabellen, welche Start Procedures, welche anderen Klassen berührten, dass alles, dass der Agent das weiß und sich durch den Code navigieren kann. Und das er genau weiß, wie wird denn dieses ganz bestimmte Projekt gebaut und dafür haben wir uns einen agenten gebaut, den wir intern auch hausten, der sich zum Beispiel auch tick jetzt aus unserem D-Rat-Zi, Polrik, weil es bei GitHub aufmacht und so was und da wirklich wie gefeintugend ist für dieses ganz bestimmte Aufgabe, ihn nur diesem einen Projekt zu arbeiten und wir haben wirklich krass messbarer Ergebnisse gehabt. Das Ding hat in einer Nacht mehrere hundert Junitests gebaut und nachgeliefert, wie 40 kleinere Bucks gefunden und eigenständig gefixt. Also wirklich beeindruckender Ergebnisse für Aufgaben, an denen jetzt der Standard Agent von GitHub co-pilot und von Cloud Code einfach, muss man sagen, gescheitert sind, weil sie nicht genau auf dieses Projekt abgestimmt waren. Wir haben aus viel versucht auch über über gutes Prom, den Übersystem, Prom, über Custom Instructions zu machen, aber die Ergebnisse jetzt, ich mache, wenn das alles Spruch läuft, ist meine ganze Folge, auch gerne dazu, weil ich das Projekt hochspannend finde. Aber das ist zum Beispiel, wo wir uns einen Agent mit einem Agent Harnis gebaut haben, den wir genau gesagt haben, wenn du da so und so viel mal in der Loop in diese Richtung läuft, dann wird das wahrscheinlich nix. Wo wir genauer gesagt haben, das sind die Tools, die du auf jeden Fall immer aufrufen musst und das wirklich reinprogrammiert haben, dass ihr das musst und nicht immer eine Instruction nie mitgegeben haben und so ein paar Sachen, muss man also nicht selber bauen. Ja und wenn man das so ein bisschen ein paar Jahre oder vielleicht auch in die nahe Zukunft weiter denkt, dann gehen wir vielleicht in einen Bereich rein, wo halt diese Agenten und der Fly sich den Harnis selber bauen und wir haben einen spannenden Teak auch aus dem Beispiel, also aus der Ecke IBM gehört, dass das vielleicht der Trend nächstes Jahr sein wird. Das Agenten nicht nur ihre eigenen Skills on the Fly selber bauen, sondern dass wenn man ihn eine Aufgabe gibt, dass ihren eigenen Harnis anpassen oder sogar From Scratch neu bauen, damit halt der Harnis auf die Aufgabe optimiert ist und einige sagen, dass es dann der nächste Schritt Richtung AGI, also allgemeine künstliche Intelligenz, die wirklich in allen Bereichen vielleicht dem Menschen irgendwann überlegen, sein wird. Ich persönlich finde es schon wirklich sehr beeindruckend, wenn jetzt diese Agenten, die wir heute haben, schon um Probleme zu lösen, sich selber eigene kleine Applikationen schreiben, Helpas-Kripte bauen oder vielleicht im Falle von Hermes, diese dann auch direkt in einen wiederverwängbareren Skill ablegen, um dann in Zukunft schneller darauf zugreifen zu können. Und da kann man sich sehr gut vorstellen, dass das Ganze darum herum, sich natürlich auch selber entwickeln und anpassen lässt, wobei das natürlich dann auch immer so ein bisschen irgendwie gruselig sich anfühlt. Wenn ich halt nicht mehr wirklich dieses Gartrails selber komplett fix steuere, sondern sage, hey, das ist so ein Template, aber du kannst es gerne so anpassen, wie du es brauchst, um die Aufgabe zu erledigen. Und da hatte ich jetzt letztens noch mal diese, ich weiß nicht, wer es kennt, diese Paperclip oder Analogie gehört, wenn es um eine Zukunftsvision von einem autonomen Agent gibt, der tatsächlich alle Werkzeuge zur Verfügung hat. Und wenn man den dann sagt, produziert so viele Heftklammern oder Büroklammern wie möglich, dann wird dieser Agent quasi über Leichen gehen, um möglichst viele Büroklammern zu erzeugen. Und wenn dann natürlich diese Beschränkung wegfallen, weil der Agent diese Beschränkung selber steuern kann, dann wird das natürlich extrem viel Impact auch haben. Ich würde sich ja bei Paperclip erst an dieses Paperclip AI denken, wo du dir so ein eigenes Team, so wie du eine Firma von Agenten auf bauen kannst. Aber es ist eigentlich eine Witzigaufgau zu sagen, also ich gebe dir im Agenten einen Tarsproduzieren, so viele Büroklaues geht und gucken, wie man dort kommt. Ich glaube, es ist wichtig, dass falls wir über eine Zukunft reden, wo sich Agenten selber so ein Harness bauen. Also ich habe eigentlich auch ein großes Helfer Awareness haben, dann sie sehr bewusst sind, wo ihre Limit sind und wo sie gut oder schlechter sind, dass man die vielleicht nicht unbedingt den Security Teil von diesem Harness selber bauen lässt. Aber vielleicht ja durchaus in der Zukunft geht wohl, man sagt, "Ey, pass auf." Diese Agenten, diese modelle wissen relativ gut, wie sie selber funktionieren, was ihre Stärken, was ihre Schwächen sind und sie sich dann selber irgendwelche Gardriel setzen im Sinne von "Ey, pass auf, ich sollte wahrscheinlich schon jedes Mal mit dieses Wissen heranzigen, nochmal über Rack, ich muss auf jeden Fall immer dieses spezialisierte Tool aufrufen, was jetzt vielleicht für genau diese Codebase geschrieben wurde. Ich sollte nie länger als zehn Mal durch diese Toolsehälterier nicht geben mir jetzt mal ein Limit von, wenn ich nach drei Abfragen immer noch keinen Ergebnis von dem GYRA MCP Server bekomme, dann ist der wahrscheinlich kaputt. Und solche Dinge, das kann ich mir schon vorstellen, dass man sich das vielleicht kann man sich für dich so irgendwann so Agent Harness S-Econfig auch irgendwie selber schreiben, dass die Agenten das selber so ein bisschen steuern können. Ich gehe mal davon aus, dass das hier gemeint ist und nicht dass er eben sich selber erlaubt, überleichen zu gehen, wenn er beruhklar man produzieren will. Wahrscheinlich gibt es so einen Innerharnis, so einen Autoharnis und den Autoharnis, den da war dann nicht anfassen. Ja oder wir müssen tatsächlich sicher stellen und das ist ein etwas, also wir vielleicht nicht mehr können, sondern das müssen wir die Anbieter der Large Language Model machen, dass diese Large Language Model eine gewisse Self Awareness haben und auch eine gewisse Priming, dass die bestimmte Schadoperation quasi nie in der Wägen ziehen würden. Es gibt dann natürlich Menschen, die sich dann dadurch irgendwie sehr eingeschränkt fühlen, weil sie nicht alles mit diesem Large Language Model machen können, weil er diese Self-Karts implementiert sind. Aber das ist ja quasi am Ende der Motor, das Gehirn dahinter und wenn man dann vielleicht auf der Ebene schon erschafft, diese Schutzmechanismen mögt, ich es gut zu implementieren, dann kann man natürlich außen rum noch mehr Freiheiten geben und ich glaube, man muss halt mit beiden ebenen Spielen, damit die am Ende irgendwie optimal zusammenpassen, dass sie aber gleichzeitig möglichst flexibel sind und was ich halt ganz spannend finde ist, dass ja seit einiger Zeit gerade solche Agenten, coding Agenten auch so ein gewisses Self Awareness haben. Ich weiß nicht, ob es einfach daran liegt, dass sie vielleicht ihren eigenen Qualtext kennengelernt haben in dem Large Language Model oder ob sie vielleicht einfach nur wirklich ganz bewusst sind, welche System Instructions die bekommen. Aber tatsächlich kann man ja in diesen Agenten häufig auf Fragen ja, warum hast du das jetzt folgendermaßen gemacht und dann können sie es genau erklären, weil halt bestimmte Dinge im Harnes so designt wurden. Ich hatte letzten Phänomen, dass die GitHub-Copilot CLI bei bestimmten Operationen einfach nicht den GitHub-Copilot oder den GitHub-MC-Pießer war verwenden wollte, habe ich mit gefragt, wo er nicht das und dann konnte mir der Agent selber sagen, dass über die Implementierung festgelegt ist, dass er in den meisten Fällen, wenn es instadiert ist, die GitHub-CLA verwenden soll, das Command Line Tool, weil das auf die komplette GitHub API zurückgreifen kann und nicht beschränkt ist durch die Tools, die im MCP-Server sind. Und dann sieht man wirklich, dass da auch ein Self Awareness vorliegt und das glaube ich ist dann wichtig, wenn der Agent anfängt, seinen eigenen Harnes auch zu bearbeiten. Ja, da merkt man auch schon so ein bisschen, wenn wir jetzt mal so abschließen, vielleicht haben wir ein bisschen so über Best Practices reden und was wir so gelernt haben, dadurch dass wir so Agent Harnes auch gebaut haben. Man merkt schon, da hat GitHub schon mal immer die Erfahrung gemacht, dass diese KI-Modelle besser mit dem GitHub-Komando-Zeilen Tool umgehen können, zumindest in aller meisten Fällen als mit den Apikols und das dann halt hart in diesen Harnes reingeschrieben. Und daran seht man schon, und das wäre auch so mein Nummer einst Tipp gewesen, so ein Agent Harnes der erschützt. der entsteht selten an einem Whiteboard in einem Meeting Raum, sondern der wächst und Gedäht eigentlich durch echte Fehler, die diese Agenden machen und echte Learnings, die man generiert. Also bei uns war es so, dass dieser Harnis nichts, dass wir einmal gebaut haben und dann hat das funktioniert. Was was man wenn man wirklich so einen eigenen Agenden baut, eigentlich so diese die Stellschraube ist, die man immer wieder anpasst, um dann gut zu ergeben ist, zu liefern und deswegen genauso wichtig, das gehört eigentlich mit dazu, dass man eine Art e-Wells, also Evaluations für auch für seinen eigenen Agent Harnis hat. Also quasi eine feste Set-On-Tests. Wie ist ein eigenen Benchmark eigentlich? Man kennt das schon mal von diesen Code-Wary Fight Benchmarks, wo ich sage, ja ich habe jetzt hier was an dem Harnis verändert. Kommt mein Code-Agent jetzt mit dem gleichen Prom wie vorher, aber dem veränderten Harnis besser zum Ziel. Und das wird Githape gemacht haben. Die wegen gesagt haben, es wird einen Test geben, wo ich sage, keiner will ich mal mal genden, sage, öffne einen Polarikquest und dann haben die irgendwann gemerkt, wenn ich dem Agent Harnis vorschreibe, dass er Githape Commander-Zellen-Tool verwendet, kommt er besser oder token spa-sama oder schneller oder verlässlicher an das Ziel. Und deswegen glaube ich, dass ein Harnis auf was ist, was immer wieder angepasst und verändert wird. Ja und ich glaube gerade, dass die mal Verlässlichkeit ist extrem wichtig und wenn wir jetzt merken, dass wir nicht verlässlich zu dem richtigen Ergebnis kommen, dann können wir wahrscheinlich so viel Zeit in unseren eigenen Prom investieren wie wir wollen. Wir werden nicht verlässlicher zum besten möglichen Ergebnis kommen, sondern das ist der Punkt, wo wir merken, dass wir wirklich den Harnis anfassen müssen, wo wir Harnis Engineering betreiben müssen, um wirklich diese Vohersagbarkeit und Zuverlässigkeit konsistent zu erhöhen. Ein Beispiel hat dann gerade gebracht, aber das kann ich natürlich auch in meiner eigenen Nutzung von Agenten machen, wenn ich merke, okay, in bestimmten Bereichen komme ich mal zum guten Ergebnis und mal nicht. Dann ist das vielleicht ein guter Indikator dafür, dass ich vielleicht nicht mal ein Prom to verändern muss, sondern dass ich eine anderen Stelle angreifen muss. Und zweite Sache, wo glaube ich viele Fehler auch passieren, ist bei zu aggressiver Komprimierung oder Kompaktierung vom Kontext. Wir hatten ja vorhin gesagt, es ist Teil des Harnises, dass der irgendwann entscheiden muss, so moment, bevor der Kontext vollläuft, fasse ich jetzt, dass passierte Zusammen und die Art und Weise, wie diese Zusammenfassung entsteht, genau das programmiert man eben in so einen Harnis rein. Und wenn ich glaube, es machen vieler am Anfang falsch, dass man den zu aggressiv dieses Komplating macht, dass man sagt, okay, der ist jetzt zu 90 Prozent voll, mein Kontext Fenster, ich komprimiere das jetzt sowieso oft 20 Prozent runter. Und das Problem ist, dass man dabei oft zu viel da wieder rauslöscht. Also ich glaube, was viele schon machen, ist so diesen ersten Initialen Promt, der reingegangen ist, den würde ich jetzt nicht überschreiben, weil daran kann der Agent sich ja später dann messen, ob er das auch geliefert hat, was da Ursprung nicht gefragt war. Aber sie sie zwischen Beweise dafür, dass er zwischen Schritte richtig gemacht hat, dass er ein bestimmte Meilenstein schon erreicht hat. Das wird oft in so einer Summarie dann weggeschluckt. Und da haben wir das Learning gemacht, dass das dem Agenten dann oft nicht wirklich hilft, sondern das er glaubt, der Tasks sei fertig, weil vielleicht auch der Gegenbeweis, oder der Beweis, dass er was nicht gut funktioniert hat, in so einer Summarie irgendwie untergegangen ist. Und wenn der Agent dann nachher hingeht und sich den ursprünglichen Promt anguckt und sich seinen Ergebnis anguckt, glaubt, dass er das gut gemacht hat, obwohl auf dem Weg, auf der Empfahrt dahin eigentlich quasi leichen liegen, die dann in dieser Summarie untergegangen sind. Also der Agent, der nachher evaluiert, ob das Ergebnis stimmt, natürlich diese Leichenswischen nicht mehr sehen kann, weil sie zwischenzeitlich aus dem Kontext ausgepackt wurden. Also lieber vorsichtig komprimieren und die richtigen Dinge, wenn Tool Call 3-mal-Failschläge, wo sie sich nicht 3-mal die gleiche Fehlermeldung im Kontext haben. Also wir haben da schon mal so ein bisschen im Kontext-Engine in der Kontext-Engineering-Folge darüber gesprochen, aber das sind Dinge, wo darüber wir gestolper sind und wo wir dann nach ein bisschen Googleen gemerkt haben, dass da einige darüber stolpern. Und zuletzt haben wir noch ein paar best practices, die wir euch mitgeben wollen, wenn ihr tatsächlich ins Harnas-Engineering einsteigert, und der erste Schritt ist hier auf jeden Fall zu schauen, wie kann ich verifizieren, dass eine Aufgabe komplett erledigt wurde. Ich glaube, wir kennen das ein bisschen aus diesem Ruffloop, wir haben da in der Folge Detail-Jet-Rüber gesprochen, dass wir tatsächlich auch ein deterministisches Feedback brauchen und dann lieber einen ehrlich, fehlgeschlagenen Versuch als irgendwie, dass das Leichenglischmodel ein Erfolg halos zuniert und behauptet, es hätte das Problem gelöst, obwohl das Problem noch gar nicht gelöst ist. Wir können da entweder testausführen, lassen Winter laufen, lassen, wir können einen zusätzlichen Review durch vielleicht einen anderen Agenten laufen, das uns wirklich verifiziert, sicherzustellen, dass eine Aufgabe wirklich erledigt würde. Und das können wir natürlich fest in unseren Harnes einbauen oder in einen existierenden Harnes als Erweitung mitgeben. Dann was wir zu mir hier gelernt haben, ist, dass Skills besser funktionieren als dieser Tool waren. Das ist ja glaube ich auch kein Geheimnis mehr, aber dadurch kann man auch so ein bisschen sehr komplexes, sehr lange Anweisungen in so einem Skill verstecken und hat den dann nicht immer schon mal ins Kontext-Fenster reingeladen und wir haben wirklich die Erfahrung gemacht, dass 5-10 Skills für einen spezialisierten Agents deutlich besser funktionieren und so ein Skill kannst euch hier sein. In unserem Fall, wie mache ich jetzt einen Prorequest auf und dann wird ganz klar beschrieben, okay, du machst den auf, wenn das und das gegeben ist und das sind die Schritte und das die Beschreibungen, die die Tools, die du für verwenden kannst und vielleicht sollst du auch noch ein Diagramm in den Polarik-Wesbeschreibung reinmachen. Das machst du dann so und so. Und dieser Skill, weil wirklich nur geladen, wenn es dann auch zum Polarik-Wesendekon, letztendlich kommt, das ist bei uns deutlich besser gewesen als dem 50 Tools direkt an die Hand zu geben, über zum Beispiel in den MCP-Service, selbst wenn man die sehr genau beschreibt, weil die halt jedes Mal für jede auch Subaufgabe dann mit reingeladen werden, haben wir wirklich gelernt, präzise gut aus damit es Skills schlagen eine große Liste an Tools. Und zuletzt noch etwas was wir vorhin schon angesprochen hatten, man muss natürlich nicht den Harnes from scratch selber bauen. Wir können ein existierenden Harnes verwenden und auf diesem dann aufbauen. Es gibt da die SDKs von den großen Anbietern, das heißt, wenn ich ohnehin mich vorforsst festgelegt habe auf eine bestimmte Sprachmodellfamilie, kann ich natürlich von OpenAI oder ein Tropic, die entsprechenden SDKs verwenden. Es gibt diese multi-modell Harnes, die ich verwenden kann von zum Beispiel Curse oder GitHub um meinen eigenen Agenten dann zu bauen. Es gibt auch andere Open Source Harnes, die ich verwenden kann. Also ich muss auch nicht auf die großen Anbieter aufsetzen. Ganz wichtig ist, glaube ich, einfach diese Erkenntnis, dass wenn man etwas komplett from scratch baut, wird man wahrscheinlich nicht an diese Qualität rankommen, die vielleicht eine große Community aufgebaut hat oder diese großen Unternehmen. Also von daher schaut euch diese existierenden SDKs an, weil sie euch auf diesem Weg einen großen Teil mitnehmen und ihr dann flexibel ergänzen könnt. Ja, und das müssen auch nicht immer der eigene ergänze, indem man dann selber diesen SDKs baut. Also Harnes Engine Ring kann auch einfach bedeuten. Ich schaue mir mal diese ganzen Konfigurationsmöglichkeiten und Optionen an, die mir der Anbieter von meinem Coating Agenten, den ich jetzt gerade verwende, eigentlich mitgibt. Weil ganz viele von den Dingen, die wir heute gesagt haben, die sind eben schon tweetbau und dass ich selber Kast im Code schreibe. Ich kann bei GitHub Co. Pilot, bei Cloud, bei Curse, ganz viele Dinge sehr genau einstellen. So euch diese ganze Security-Netz, die haben alle einen Konzept darin, von Dingen, die ich zum Beispiel prüfen möchte, von ganz bestimmten Coating oder CLI Tools, die ich immer zulasse, andere von denen ich immer eine Pue will haben möchte. Es gibt ganz viele Möglichkeiten zu sagen, in wie viel , nach wie viel Interationen zum Beispiel, so ein Agent aufgeben soll. In welchen, ich kann so Szenarien bauen, in denen verschiedene Tools dann stammen, mäß ich reingeladen werden. Ich kann eben mit Skills und so weiter meinen Agenten bearbeiten. Das heißt, es muss gar nicht immer sein, dass ich das Ding selber engineering im Sinne von Kast im Code schreibe, sondern ich kann auf die bestehenden Agenten auf meine Bedürfnisse anpassen. Und ich würde sagen, eine Stunde Harnes building oder engineering oder configuration schlägt wahrscheinlich zehn Stunden an irgendein Prom zu arbeiten. Denn die Frage muss eigentlich, wenn der Agent nicht gut funktioniert, ist in der Regel nicht, ja, was war denn dein Prom? Vielleicht hast du falsch gepromptet. Ich würde sagen, in den meisten Fällen ist es, wie es denn ein Harnes eingestellt ist, da denn vielleicht ein, also hat der Agent wahrscheinlich gar keine andere Wahl gehabt, als sie in die falsche Richtung zu laufen oder hast du ihn nicht richtig, ja, hast du das fährt nicht richtig aufgezeugt, müsste man eigentlich sagen. Und ich muss mir ja nicht immer mein eigenes Zaumzeug selber basteln, sondern kann ja mal auf den bestehenden schon verschiedene Stellschrauben und Schnellen einstellen, um bei diesem Beispiel vom Anfang zu bleiben. Ja, ich glaube, man kann sagen, diese Dinge, die sind jetzt nicht komplementär, sondern sie bauen aufeinander auf, wie du gerade gesagt hattest. Ich fand irgendwie an, erst mir mein Prom anzugucken, wenn das nicht reicht, fange ich mir an Prom plus Kontext anzug schauen und wenn das dann nicht reicht, dann gehe ich an den Harnes. Und wenn ich all dies beherrsche, dann komme ich zu dem bestmöglichen Ergebnis. Zumindest stand heute, das Ganze ist natürlich ein extrem dynamisches Umfeld und wahrscheinlich wird dann in 2027 die nächste Sau durchs Dorf getrieben und ich bin mal gespannt, was dann engineered wird. Wir machen auf jeden Fall eine Folge dazu. Ich wüsste jetzt auf jeden Fall Bescheid, wenn ihr das nächste Mal vom Agent Harnes hört oder lehst, könnt ihr mitdiskutieren, das könnt ihr natürlich auch hier direkt bei uns machen. Da freuen wir uns darauf. Habt ihr schon Erfahrungen damit gemacht? Habt ihr vielleicht schon euren eigenen Agent Harnes gebaut oder stark konfiguriert und damit besonders gut oder vielleicht auch schlechterer Ergebnisse zielt als die eingebauten Sachen? Das würde uns interessieren und bestimmt doch andere hier in der Community. Also lasst gerne noch mal einen Kommentar da, was eure Erfahrungen mit dem Thema sind. Auf Spotify und YouTube kann man ja öffnen. kommentare schreiben. Freu wir uns immer drüber. Wir können das aber auch gerne unter uns diskutieren. Wir freuen uns über jede Zuschrift. Wir haben eine E-Mail-Adresse unten in den Show Notes verlinkt. Zusammen mit einer ganze Menge Lesematerial nochmal zu dem Thema Agental-Nus-Engineering, was wir uns auch in der Vorbereitung angeschaut haben, wenn ihr da also noch tiefer einsteigen wollt, schauen wir mal in die Beschreibung von der Folge. Und wie immer, wenn euch die Folge gefallen hat und euch weitergebracht hat, lasst uns gerne eine positive Bewertung da, das können wir machen auf Spotify oder Apple Podcasts. Und natürlich könnt ihr uns auf allen gingenen Plattformen auch abonnieren. Und wenn ihr schon mal unten in der Folgenbeschreibung seid, dann schaut mal an der Saisonklingler Link zu Bimey or Coffee. Da könnt ihr uns was rutes tun, uns ein Kaffee ausgeben, wenn ihr mögt oder wenn ihr zu eurem eigenen Kaffee die passende Nerd-Taste haben wollt, schaut auch gerne bei unserem kleinen Shop vorbei. Links zu allem findet ihr in der Beschreibung und es bereitet uns immer eine große Freude zu sehen, wenn ihr uns einen virtuellen Kaffee da lasst. Das lösen wir auch wirklich ab und zu ein, indem wir uns in Persona treffen und dann auf euch die Community einen Kaffee trinken. Und bevor mir jetzt völlig schwarz vor Augen wird, bei der Hitze, so wie vorhin meiner Kamera, oder ob ich mal nur wird, das wahrscheinlich im Videofied raus schneiden, dem entsprechend wäre das vielleicht gar nicht sehen. Aber leider war es meiner Kamera zu warm. Jetzt ist mir auch zu warm, von daher beenden wir jetzt schnell die Folge und freuen uns darauf, wenn ihr auch nächste Woche wieder mit dabei seid. Nächste Woche gibt es ja wieder eine Newsfolge, der to Do the World of Health Podcast erscheint. Jede Woche am Montagmorgen. Hol euch ein Eis, springt ihr den See, genießt das Wetter so gut es geht oder macht die Rollers runter und schreibt ganz viel Code. Wir freuen uns in den nächsten Wochen wieder mit dabei seid. Macht's gut. Bis dann.