Deep Dive 214 –

LangChain mit Christian Bromann

18.08.2026

// Podcast
// Deep Dive 214

Es werden Daten an YouTube übertragen. Datenschutz

Immer erlauben

Shownotes

Wie baut man einen Agenten, dem man wirklich Arbeit überlassen kann? In diesem Deep Dive sprechen Jan und Dennis mit Christian Bromann von LangChain darüber, was heute alles dazugehört, wenn man Agents baut, testet, deployt und im Betrieb überwacht.

Christian beschreibt LangChain als ein Toolset, das den gesamten Agent Development Lifecycle abdeckt: vom Bauen über das Testen bis zum Deployen und Monitoren. Angefangen hat alles beim Monitoring, also beim Aufzeichnen aller Schritte, die ein Agent macht. Diese sogenannten Traces sind bis heute die Grundlage für vieles andere. Das Herzstück dahinter ist LangGraph, die Runtime, in der Agents laufen: Man baut einzelne Nodes, legt fest, wie sie durchlaufen werden, und jeder Schritt wird gespeichert. Über Middlewares kann man an jeder Stelle des Ablaufs eingreifen, etwa bevor ein Modell aufgerufen wird oder nachdem ein Tool ein Ergebnis liefert.

Ganz oben steht der Deep Agent, der Sandbox, Sub-Agents und nachladbare Skills mitbringt. Möglich ist das laut Christian erst, weil die Modelle inzwischen klug genug sind, zum Beispiel mehrere Tool-Calls parallel auszuführen.

Wir sprechen auch darüber, wer sich so einen Agenten überhaupt selbst baut, während es Agents doch längst von der Stange gibt. Für wiederkehrende Aufgaben im Unternehmen lohnt sich eine eigene, getunte Umgebung fast immer. Mit Fleet zeigt Christian ein Werkzeug, bei dem selbst nicht-technische Kolleg:innen per Prompt einen Agenten zusammenbauen, indem sie einfach ihre Tools wie E-Mail oder Jira verknüpfen: ein Agent, der Agents baut.

Zum Schluss wagen wir einen Blick in die Glaskugel. Christian sieht großes Potenzial in Open-Weight-Modellen. Statt jeden Monat große Summen an die großen Anbieter zu überweisen, könnten Firmen künftig kleinere, offene Modelle für ihren eigenen Use Case finetunen, auch aus Kostengründen und um die Kontrolle über ihre Daten zu behalten. Ob dieses Kostenargument wirklich trägt, diskutieren Jan und Dennis anschließend munter weiter.

Download

/transkript/programmierbar/deep-dive-214-langchain-mit-christian-bromann

Jan: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar. Heute für euch am Start einmal der Jan Gregor in Betrieb will und neben mir Der
Dennis: ist ausnahmsweise.
Jan: Dennis Becker. Das grüßt mich so an.
Dennis: Du sagst ausnahmsweise. Ja, wir sind
Jan: ja nicht so oft physisch im selben Studio. Das Das stimmt. Passiert da nicht so häufig. Ich fühl mich hier immer noch sehr neu. Ihr habt alle son bisschen mehr Erfahrung schon hier damit. Ich war vorhin schon überfordert, die Lampen wieder anzukriegen, aber es hat alles funktioniert. Ton und Bild haben wir jetzt auch Gott sei Dank. Und wir sind zwar zu zweit nur hier, aber zu dritt in diesem Gespräch, nämlich haben wir noch am Start Christian Bromann. Hallo Christian, schön, dass Du da bist.
Christian: Hallo Dennis, hallo Jan.
Jan: Mir fällt grad zum ersten Mal auf, dass das in dem Video ja komplett antichklimatisch ist dieser Effekt, weißt Du, in der Audioaufnahme. Da merkt man nicht, dass 'n Gast dabei ist, bis man sagt, so und heute ist 'n Gast dabei und dann sagt er das 1. Mal hallo. Mhm. Und im Video sieht man jetzt die ganze Zeit schön Christian und wir reden Ja. Nur auf
Dennis: einmal, wie Du zusammenschneidest. Du kannst ja in den ersten Fram snones zeigen.
Jan: Ja, Challenge an Carlo, wir produzieren das jetzt einfach mal 'n bisschen bisschen anders. Genau. Christian ist heute bei uns, über Langchain zu sprechen und wie man Agents baut und Christian, ich hab mir vorhin noch mal dein LinkedIn Profil angeguckt und ich hab gesagt, da hast Du ja schon ziemlich viel so gemacht, ja, also weiß nicht, was da alles dabei schon auswendig noch im Microsoft MVP und bei der Open JS Foundation und Web Driver. Io Mainainer habe ich gesehen und da muss ich ganz kurz 'n besonderes Lob aussprechen, weil jeder, der früher mal, so wie ich son Selenium Cluster Maintain musste, ja, ja, da lacht gestern schon, mir treten traumatische Angstschweißperlen gleich wieder auf
Christian: die Stirn, ja, weil das war
Jan: früher alles, Schweißperlen gleich wieder auf die Stirn, ja, weil das war früher alles son richtiger sagen oder müssen wir das raupieen?
Dennis: Das ist okay. Und das ist
Christian: Ich fand, weil ich der Einzige gewesen bin, der das damals gerne gemacht habe, weil ich wirklich das Thema spannend fand, Bausautomisierung, fand ich immer, ich hatte 'n Vorteil, weil alle haben mich da rangelassen und konnte mir dann die Bonuspunkte einheimsen.
Jan: Das das das Ich Entwickler, ich bin ich bin Valent von soner, wie heißt das, evolutionären Nische. So, Du besetzte sone Stelle, wo sonst niemand hinwill und breitest dich dann da irgendwie irgendwie aus. Ja, ich muss sagen, das hat mir auch irgendwie immer Spaß gemacht, aber es war halt son sehr schwer zu debuggendes Ding. Weißt Du, hast Du son Selenium Server und dann sind da 'n paar Clients dran connected und irgendwas funktioniert nicht und ist das das Network zwischen irgendwie dem Client und dem Server oder ist irgendwas in dem Browser oder hast Du nicht gesehen, das war schon immer
Christian: Jeder Tag ist 'n neues Abenteuer, wenns ums Debuggen geht.
Jan: Das das ist richtig, aber ich wollte fast sagen, Gott sei Dank, aber so soll wahrscheinlich sein. Wir reden hier heute nicht über Browserautomatisierung, sondern wir reden über Langchain und ich glaube, Langchain ist in der programmier.bar das 1. Mal so aufgetreten, 22, vielleicht, Spätestens 20 23, weißt Du, hatten wir mal Christian Weiher zu Gast und haben wir über so AI Integration und Rack und so was alles gesprochen. Ich glaube, da war das ja das 1. Mal inhaltlich son Thema und Langg shin ist ja gefühlt son sehr junges Projekt und gleichzeitig in AI Jahren gemessen schon son sehr altes Projekt, weil das ja von Anfang an gefühlt so mit dabei war und ich hab das immer noch so im Kopf als, ah, das, wie gesagt, wir haben damals über Rack und Retriever Argumentation gesprochen und son bisschen über Inference im Browser machen und so und das ist immer so, wo ich Langchain noch noch abgespeichert hab, aber ich glaube, es ist mittlerweile viel viel mehr und deshalb, Christian, bevor wir in das zu tief in das Thema einsteigen, wie würdest Du denn Langchain grade beschreiben?
Christian: Ich würde Langchain beschreiben als eine Organisation, die Services und Tools baut, die den kompletten, wir wir sagen dazu, den Agent Development Lifecycle abdeckt. Also alles von das Bauen von Agents zum Testen der Agents, zum Deploying der Agents und zum Monitoren der Agents. Und das Interessante dabei ist, dass ich glaube, unser Steckenpferd sozusagen ist die Tatsache, dass wir auf quasi unser erstes Service war Monitoring. Das heißt, wir wir nehmen alle Traces auf, die son Agent macht, alle LLM Calls, alle Two Calls und wir speichern diese Daten und wir können da mit den Daten können wir genau können wir jetzt quasi genau wissen, wo's bei dem Agent hängt, was der an welchen Stellen falsch macht, wo der falsche Abbiegung aufsetzt oder macht und wir haben jetzt quasi unsere eigenen Agents, die sich diese angucken und dann sagen, hey, Du könntest das verbessern, Du könntest das verbessern. Das ist quasi son, so mehr umso mehr Leute den Agent benutzen und umso mehr Monitoringdaten wir bekommen, umso mehr Traces wir haben, desto bessere Vorschläge können wir machen, wie man den Agent noch intelligenter machen kann.
Jan: Okay, vielleicht machen wir noch 2 halbe Schritte zurück und sprechen noch einmal darüber, was so ein Agent eigentlich ist und was ein Agent für euch eigentlich ist.
Christian: Ja, ich finde das mal ganz, ich glaub, das lässt sich ganz gut beschreiben, indem man mal die ganze Palette von Tools, die wir so mal in den letzten 3, 4 Jahren gebaut haben. Ich meine, ich bin ja jetzt seit einem Jahr jetzt dabei, aber die es so gibt. Also als Erstes, als Langzeit 2023 quasi gestartet ist, das 1., was sie gebaut haben, sind quasi so einfache SDKs, mit LLM zu kommunizieren. Damals war Models noch nicht so, die waren noch nicht so schlau. Du konntest 'n prompt hinschicken und Du hast quasi 'n prompt 'n Text zurückgekriegt. Und die haben halt Chains gebaut, die man miteinander verknüpfen konnte, halt die Antwort 1 Models in den prompt 1 anderes Models reinzuschicken. Und das hat funktioniert, aber Leute haben halt immer mehr gebaut und was halt her musste, ist irgendwas, was man deployen konnte und was wo man halt die Informationen, auch wenn ja, die Informationen zwischenzeitlich abfangen kann und quasi speichern kann. Und dahingehend wurde was gebaut, was wir nennen. Ist quasi eine, mit dem man sich Notes aufbauen kann und sagen kann, welche Notes wie ausgeführt werden. Also ich geh von Node a zu b zu c und basierend auf welcher Kondition gehe ich 'ner d oder e. Und das konnte man dann deploying und jeder Step in dieser Node wurde quasi gespeichert, gechecktpointet und man konnte dann halt genau wissen, was passiert, welche Schritte passiert sind zwischenzeitlich. Das das war quasi die die Foundation für die ganze Observability Und basierend darauf dann haben dann Leute mehr komplexe Systeme gebaut, grade in den Zeiten, wo RAC 'n großes Thema war, konnte man in gewissen NOTES dann einbauen, dass man eine Datenbankinformationen holt und die das Resultat hat man dann der nächsten Node gegeben, wo man dann den LRM Score gemacht hat. Und Langlauf ist unsere Agent Run Time bis heute noch. Die die führt alles aus, worum's geht, Workflow durch zu bauen oder ja halt son son son ja son Agent zu deployen und laufen zu lassen und
Jan: Wenn ich dich da vielleicht kurz unterbrechen darf, weil Du hast ja eben schon beschrieben, wie ihr so in Langkraft diese Flows gebaut habt, ne. So einen Block nach dem anderen, Ergebnisse bauen aufeinander auf und dann hast Du gesagt, na ja, das ist auch heute im Prinzip noch die Run time, in der die Agents laufen.
Christian: Genau.
Jan: Ich stell mir son Agent immer so sehr laienhaft eigentlich eher als son Loop vor und wenn ich mir den in sonem Graph vorstelle, sieht das eigentlich für mich erst mal relativ unspektakulär aus, weil er sich halt mit son paar Schritten nur im Kreis treten und diese ganzen Abzweigungen und wenn Ergebnis so, dann so und nicht ihr Ergebnis weiterreich und so. Das das wird ja gar nicht mehr so stark gebraucht, oder? Also macht macht euch 'n Agent nicht quasi die Run Time dann einfacher als diese komplexen Graphen, die da vorher von von Hand zusammengeschraubt wurden sind?
Christian: Genau, das wär das dann das nächste die nächste Abstraktion, die wir darauf gebaut haben, als dann letztes Jahr quasi das Jahr der Agents der der oder der React Flow quasi sehr populär wurde, haben wir quasi diesen React Flow auf aufgesetzt und das wirklich einfach mit 'ner einfachen Funkfunktion abgedeckt, wo man dann einfach, hier sind 'n paar Tools, hier ist eine System prompt und wir haben halt halt im Hintergrund den aufgebaut. Mhm. Nun kommt auch, dass wir als ein als Alleinstellungsmerkmal noch Middlewares eingebaut haben. Das bedeutet, dass Du quasi Hooks hattest, bevor Du 'n Model benutzt hast oder nachdem Du 'n Model oder LM Resultat zurückbekommen hast, bevor Du 'n Tool ausführst oder nachdem Du 'n Tool Resultat bekommen hast. Du konntest halt in jeder Stelle des dieses Tool Loops eingreifen und Ergebnisse verändern oder was hinzufügen, was fixen. Das war schon ziemlich hilfreich, weil wir damit viele Middleware bauen konnten, die gewisse Workflows abgedeckt haben und Sachen vereinfacht haben, die anderweit son bisschen schwieriger gewesen sind. Und auf dem und auf dieser Foundation nun haben wir 'n Deep Agent gebaut, der quasi der oder der React Blueop ist, aber mit quasi der nächsten Generation von Komponenten, die ein Agent heutzutage braucht, was zum Beispiel die Sandbox ist, was zum Beispiel Sub Agents sind oder Skills, wie Skills geladen wären, progressives Laden von spezifischen Fähigkeiten. Das findet sich nun alles in diesem Deep Agent Paket drinne und grade die letzte Woche hab ich angefangen, quasi eine Stufe weiter höher zu bauen. Wenn es darum geht, wenn man Agent in 1 Organisation jetzt benutzen will, triggerst Du die ja nicht in 'ner 'n Terminal, sondern Du willst einfach über Slack 'n Agent die Message schicken und da geht's dann darum, okay, wie nimmt son Agent eine Identity an? Das heißt, führt der Agent einen Auftrag für dich aus, für eine Organisation, für 'n Team? Basierend darauf hat der Agent auch nur spezielle Zugriffe auf Repositories oder auf Tools und das ist quasi diese nächste Generation von Agents oder Frameworks, die wir sehen. VrCell hat vor 2 Wochen Eve rausgebracht. Das Flu Framework ist vom von Threadshot, gibt's mittlerweile schon 'n bisschen länger. Das sind so diese diese nächste Generation von Agenten Frameworks, die sich jetzt so entwickeln. Und ja, für Langstein in den letzten 3 Jahren ist quasi interessanterweise konnte man konnte man sehen, wie so die ganzen Primitive sich jetzt aufgebaut haben, obwohl Langstein in selber schon so dieser React Loop, der man hat darüber schon geredet 2023. Damals waren halt die Models noch nicht klug genug. Und diese Abstraktion, die wir alle bauen, jetzt die können wir auch nur tun, weil die Models klüger sind. Die können jetzt Tool Calls gleichzeitig laufen, also gleichzeitig ausführen. Das konnte man früher nicht und deswegen hat sich das früher auch noch nicht gelohnt, diese Abstraktion zu bauen. Das kommt jetzt alles als die so, als die Models jetzt immer klüger wären.
Jan: Du hast gesagt, es gibt immer mehr diese Agent Frameworks von ganz vielen verschiedenen Anbietern, die es jetzt im Prinzip jedem erlauben, so seinen eigenen Agent zu bauen und bei euch kommt noch entscheidend hinzu, dass ich mein Agent dann auch einfach bei euch laufen lassen kann, ja. Das ist ja auch nicht so selbstverständlich. Bei manchen gibt es nur das das SDK dazu, bei manchen vielleicht noch 'n bisschen Inference oder so, aber manchmal muss ich auch meinen Agenten dann selber betreiben. Lass uns vielleicht einmal kurz darüber sprechen, was es alles braucht, das betreiben zu können. Also was muss ich entweder selber mitbringen oder was stellt ihr quasi im Prinzip schon im Hintergrund so bereit, das für mich nutzen zu können. Ich sag mal, der allerbanalste Teil davon ist, ich brauch Computing, weil irgendjemand muss das Ganze ausführen. Ich brauch Inference, irgendjemand muss muss mein Model bereitstellen oder ich brauch 'n lokales Modell, was ich irgendwie nutzen kann, aber was was brauche ich noch?
Christian: 'N Agent ist oder 'n Agent Server ist im Prinzip nichts anderes als 'n Backend, welches dir gewisse Erdpunkte zur Verfügung stellt, son Agent zu triggern. Im einfachsten Fall, wir haben quasi 'n einen Endpunkt, wo Du dem Agent 'n 'n, ja, 'n Prop schicken kannst und dann kriegst Du halt 'n 'n 'n Response zurückgestreamt und den kannst Du dann halt auf 'ner App zeigen und mit Reacthooks quasi streamen, wie man das so schön kennt. Dazu bräuchte wahrscheinlich jeder noch son, wir könnten wir nennen das 'n Checkpointer, das bedeutet, eine Stelle, der das es erlaubt dir den den Schritt, der der das der den der Agent macht, abzuspeichern und die Möglichkeit hat, quasi 'n Thread, den Du mit 'n Agent gestartet hast, auch wieder von der Datenbank zu laden und quasi an 'ner gewissen Stelle wieder weiterzumachen. Aber im Prinzip, das ist im High Level schon das, was es braucht. Ich hab jetzt noch nicht gesehen, dass jemand 'n lokalen Model mit seinem Server deployed irgendwohin. Es wäre 'n bisschen, ja, weiß nicht, wie das mit den Ressourcen funktioniert, aber meistens nimmt man dann Model oder hat sein API Key aufm Server dann geladen und kann dann dem Model das Model dann irgendwie remote benutzen.
Jan: Du hast ja auch schon 'n Tool Calling angesprochen. Das zu ermöglichen, bedarf es ja irgend eine Umgebung. Also das wird ja nicht so sein, dass wenn mein Agent bei euch jetzt irgendwie 'n Tool ausführt, dass er dann da Bash als Root irgendwie auf der auf der Kiste, wo das alles läuft macht, sondern da brauchst Du irgend eine irgend eine Sandbox, irgend eine Environment, was da irgendwie vorgefertigt wird. Was und wie stellt ihr da bereit?
Christian: Da, ja, da gibt's mehrere Möglichkeiten. Die meisten werden wahrscheinlich eine Sandbox benutzen und sich mit 'nem Sandbox Provider verbinden, wo man dann relativ schnell eine Sandbox zur Verfügung gestellt bekommt, die man auch vorher Provisionay, also vorher aufbauen kann, wo man sagt, ich brauche immer dieses Repository in meiner Sandbox, dann kann man sone Sandbox vorher zusammenbauen und die dann snapshotten und dann kann man immer wieder auf der gleichen Sandbox aufbauen. Wo wir 'n bisschen mehr investiert haben, sind wir nennen's Interpreter. Das bedeutet, dass wir quasi ins anstatt eine Sandbox zu benutzen, können wir einfach den Agent eine Javascriptumgebung geben.
Jan: Mhm.
Christian: Die benutzen kann, so einfache Codegeschichten ausführen zu lassen. Das benutzen wir aber meistens, den Orksfelder eine Möglichkeit zu geben, Sub Agents über Code aus zu zu ja, zu triggern. Das ist, man kann sich so vorstellen, wenn man 'n Agent hat und man sagt, gib den Agent sone CSV CSV Datei mit 100 oder 100 Reihen drinne und man gibt es den Agent und sagt, guck dir jede Reihe an und man stellt eine Frage dazu, dann wäre das 'n bisschen, dann könnte der Agent jetzt einen Tour Call nach dem anderen machen oder er könnte halt eine 1 JavaScript Code erstellen, weil Agents oder LLMs sind ziemlich gut im Coding, der quasi über diese CSV Datei einmal rübergeht und die ganzen Zellen parallel für parallel 'n Sub Agent aufruft. Also wir haben zusätzlich zum Sandbox noch son son Interpreter sone Rapple Umgebung, die über QUICGS relativ sicher in im Agent selber läuft, ohne dass man eine Sandbox braucht. Aber das, wie gesagt, mehr für Orchestrationen von Sub Agents und kleinen, also einfachen Coding Problemen.
Jan: Du hast auch schon das Thema Identity angesprochen. Wo wer wer ist mein Agent und was was darf er? Wenn ich mir jetzt überlege, ich will hier bei uns bei Lotum son son Agent mal bereitstellen für alle in Slack, wie Du gerade angesprochen hast. Wie viel Gedanken muss ich mir da zum einen das Thema Access und Autorization machen, aber auch das Thema Identity des Agents selbst. Also wie wichtig ist das, dass ich dem im, sagt man da bei dem Agent auch System prompt, ist das das System prompt von dem Agent, Dass ich ihm quasi vorher son bisschen beschreibe, wer er ist und was er was er können soll, wofür er zuständig ist, versus wie viel kommt er eigentlich aus dem Gespräch mit dem Agent und den den Mitarbeitern selbst raus?
Christian: Ja, also das eine ist dem Agent quasi 1 1 1 Bewusstsein zu geben, was man sone System prompt hat, wo Du sagst, Du bist 'n hilfreicher Assistent für das Team ABC. Das ist quasi mehr son Bewusstsein. Worum's in der Identity mehr geht, ist, dass man herausfindet, wer den Agent gestartet hat und da basierend darauf gehend dem dieser diesem Active quasi eine gewisse Verfügung gibt über welche welche Tools er benutzen kann und welche welchen Zugang er auf gewissen Ressourcen hat. Und das gibt's tatsächlich so noch nicht in vielen Frameworks. Das wird jetzt langsam, ich seh das bei Flur, gibt's so einfache Andeutungen für diese Modelle, aber ich hab das so noch nicht gesehen, dass es so was gibt. Das ist auch relativ neu, dass man dass dass man sieht, dass man solche Probleme jetzt bei Agenten ablösen muss, grade wenn grade als viele das jetzt in großen Organisationen deployen und mehrere Teams auf Agenten zugreifen. Viele bauen das grade noch selber quasi ein und wir versuchen das halt 'n bisschen zu abstrahieren und das einfach zu machen, dass Du sagen kannst, okay, wenn dieser User von Slack auf meinen Agenten zutrifft, dann kann ich dem gewisse Zugriffe auf dieses Repository geben und dann kann ich auch den Commit, den ich erzeuge mit meinem Agenten so erstellen, dass es quasi 'n p a wird, wo auch sein Name dann draufsteht. Und genau das macht man mittlerweile alles noch händisch und da versuchen wir halt auch Abfraktionen zu bauen, dass es alles 'n bisschen einfacher wird.
Dennis: Und ist ja auch das auch das Ansatz, wenn das praktisch in einem Team in 1 Teamkonstellation ist, ne, weil Du das gerade über Slack sprachst, aber ist schon die Idee, ich als Dennis gebe eine Aufgabe und er erledigt das praktisch für mich und committe dann auch in meinem Namen.
Christian: Genau.
Jan: Okay. Und wessen wessen Problem in Anführungszeichen muss es denn überhaupt sein, weil eigentlich muss es den Agent ja gar nicht so interessieren oder? Also der Agent weiß, mit wem oder für wen er das quasi macht Dann ist ja dieses Identity Thema eigentlich eher sone Herausforderung für die Tools, die er's, die er eventuell aufrufen muss und gar nicht mal so für den Agent, also für das LLM und den laufenden Prozess quasi so selbst, oder?
Christian: Das kann man, also das ist dann immer bei jedem jedem überlassen, wie er sein Agent definieren kann. Klar kannst Du diesen Agent auch sagen, einfach committe mit deinen Namen, mit mit dem Agent seinen Namen oder seinen Authentifikation. Ich glaube, wo es dann kritisch wird, ist beim beim bestimmten Leuten bestimmten Zugängen zu geben, was ist dann halt, was dann halt die über Identity auch gemappt wird.
Jan: Genau, aber das ist ja für den für den laufenden Agenten quasi intransparent, sondern ich muss diese diese Identität, ich muss wissen, das ist Dennis und dann muss ich das dann alle meine Tools, meine MCP Server, meine keine Ahnung was weiterreichen, dass mein mein git Command auf der CLI muss Dennis seine Identität haben, wenn ich auf Confluence zugreif über MCP, muss ich das mit Dennis seiner Identität machen, aber den Agent selbst stört es ja quasi nicht, ob das Dennis ist oder Jan oder Christian oder Hans Müller, sondern für ihn ist es son transsend Ding, was er im Prinzip immer nur mitreicht während diesem ganzen Gespräch.
Christian: So sieht's aus, genau.
Jan: Okay.
Dennis: Ich muss trotzdem noch mal 'n bisschen grundsätzlich fragen, wo son bisschen der Einstiegspunkt ist oder beziehungsweise wo ihr da genau hängt in in in diesem Ding. Also ihr bietet ja keine LLMs an, das heißt im Hintergrund connected man dann ein Model seiner Wahl. Genau. Und übernehmt ihr trotzdem praktisch die Harness, also das, was nach außen rum passiert, mit dem Modell zu sprechen oder basiert das dann auch auf der Harness von irgendeiner Umgebung, mit der ich sowieso interagiere?
Christian: Also Du kannst generell jeder Hahnes nehmen oder jedes Agent Tool, was es gibt und dir einfach nur die Services picken, die Du möchtest. Wenn Du 'n Agent bauen willst mit Langchain Tools, dann kannst Du das mit Langchain Tools machen, aber die Traces irgendwo anders hinschicken. Wenn Du p oder Cloud Code benutzt, aber willst die Agent Traces bei uns behalten, dann kannst Du die Agent Traces zu uns schicken. Ich weiß nicht, wie viel, ob man nur Ich glaube, man kann nur Agent Harnesses, Longchain Harnesses auf uns deployen. Könnte sein, dass ich da falsch liege, aber Deployment ist 'n eigenes Thema. Also es gibt einmal die die Hornissees, die man die Du bauen kannst, entweder mit Langchain Tools oder nicht mit Langchain Tools. Obsevability, die Du machen kannst, entweder auf unserer Plattform oder auf anderen Plattformen. Evals, die Du running lassen kannst, also Agent Testing, entweder auf unserer Plattform oder auf anderen Plattformen. Da gibt's unsere Kunden, die die mixen Cledes zusammen und es gibt Kunden, die nur Longchain benutzen, aber ich glaub, die die Mehrheit hat so, die nutzen nur Observability, die nutzen nur unsere STKs, Mathens zu bauen. Da da sind wir wir wir wir sind wir locken jetzt die User nicht ein und sagen, hey, ihr müsst nur unsere Sachen benutzen, wenn ihr irgendwas von Longcham benutzen wollten.
Dennis: Okay. Und hast Du konkrete Use Cases oder Companyarten vielleicht oder Branchen oder auch individuelle, wo Du sagen würdest, da sollte man mal reingucken, weil man dann einen Mehrwert hat?
Christian: Ich glaube, jede Firma, die in irgendwelchen Sinne digital arbeitet, da wird sich Use, da werden sich Use Cases finden. Also in unserer Firma hat jedes Team mindestens ein oder 2 Agenten und das ist nicht nur das Engineering Team. Also wir haben 'n Go to Market Team, das 'n Go to Market Engine hat, das mit Salesforce verbunden ist und mit den ganzen Tools, die Go to Market benutzt, herauszufinden, wie es bei dem Kunden steht. Wir haben es Finance Agents, die wissen, wie uns ums unsere Finanzen steht. Wir haben mehrere Coding Agents, die bei uns laufen. Ich glaube, da da gibt's der Kreativität keine Grenzen und was jeder Schritt, wo der quasi automatisiert werden kann, kann oder jeder Arbeits, jeder Arbeitsschritt, der quasi, wo man nicht so viel, wo man keine persönlichen Entscheidungen treffen muss, kann man mit Agenten ab abbilden.
Dennis: Und? Einfach.
Jan: Ich glaub, bevor Du die nächste Frage stellst, ich würde mich aufbauend auf der Frage stellen, für wen lohnt es sich denn dann so einen eigenen Agenten zu bauen? Weil es gibt ja mittlerweile auch, ne, Agenten, ich sag mal, von der Stange. So, ich kann bei Entropic kann ich zu Cloud Co Work gehen und da im mitarbeiten. Ich kann bei OpenAI auch hier Kodex in den Kodexpot in Slack reinhängen. Also wer baut sich das denn selbst und was erhofft man sich davon oder oder für wen ist das halt besonders rentabel, da so eine Schicht tiefer zu gehen und zu sagen, na ja, wir wir schrauben das hier lieber selbst zusammen?
Christian: Ich glaube, es hängt davon an, wie welchen Use Case Du hast und wie speziell er ist. Ich glaube, im in den meisten Fällen kannst Du dir eine Codinghanes nehmen, wie bei uns son Deep Agent dem Deep Agent ein paar Tools geben oder mit mit dem mit 'nem NCP Server verbinden und dann damit starten. Da gibt's da gibt's nicht so viel, wo ich sagen könnte, da gibt's ein, 2 Stellen, wo Du dann doch selber deine eigene Hannes bauen willst, grade weil wir, weil ich weiß, dass eine gute Hannes zu bauen sehr anstrengend sein kann. Da gibt's so viele ja, Knöpfe, die man drehen können, eine Hannes besser zu machen. Da ist es oft besser beraten, wenn man einfach son existierende Hannes benutzt und die Komponenten einfach dazu gibt. Klar, kann man immer noch dann da hingehen und sagen, okay, ich will meine den Agent verbessern und jeweils aufbauen und versuchen, die System Proms zu tunen, bessere Resultate zu kriegen. Ich glaube, das sollte man immer machen. Es gibt nicht, wo wirklich son Agent Klar kann man sich Kodex runterladen und Kodex benutzen für Coding, aber es gibt für so für Workflows innerhalb 1 Firma, würde ich halt auch immer dahin gehen und sagen, eine Hannes aufbauen und dann versuchen die zu tunen, immer bessere Resultate zu kriegen.
Dennis: Ich stell's mir auch son bisschen so wie son Katz und Maus Spiel vor, oder? Ich mein, also es ist ja, ich würde behaupten, wahrscheinlich oder meine aktuelle Vermutung ist, wenn man eure Tools nutzt, ist man 'n bisschen mehr an der Cutting Edge und hat vielleicht noch mehr Möglichkeiten, verschiedene Dinge zu individualisieren und möglich zu machen, so die vielleicht so out of the box mit einem Klick nicht gehen, was vermutlich dann so in der Entwicklung halt ne, paar Monate später vielleicht ein Teilaspekt ist von einem der der großen Anbieter, vielleicht nehmen wir mal Cloud Tag als Beispiel so, ne, weil wir jetzt eben mit dem Slack Barn, wo sie jetzt auch so was gebaut haben, wo 'n Teil davon eben abgenommen wird, ne und auch gemacht wird. Und in meinem Kopf, also zumindest auch so der Wahrnehmung war das ja auch immer schon son bisschen, ne, dieses also dass man mit Langchain und den Tools drum rum halt die Möglichkeit hatte irgendwie noch einen Schritt weiter zu gehen zu dem, was jetzt erst mal so das Modell von Haus aus irgendwo angeboten oder angeboten hat. Wie macht ihr das denn, also sagt schon selbst, dass ihr auch selbst die Agent dann nutzt so im euren Alltag, aber ich stell mir das halt auch sehr spannend vor an dieser Entwicklung irgendwo, ne, praktisch an dieser Metaebene vorne zu arbeiten und mal zu gucken, woher sind denn die nächsten Schritte, die die man gehen kann und wo ist man son bisschen limitiert? Wann ermöglicht ein neues Modell beispielsweise Dinge, die vorher nicht möglich waren? Waren es einfach nur eine schlaue Tooling Idee, weil man sagt, hey, das wär doch gut, das in Prozessen abzubilden. Also wie treibt ihr da so ein bisschen das das Produkt voran? Und ich weiß nicht, ob's in dem Sinn oder eine Sprite Sprache noch, Sprache, eine weitere Frage Anschlussgleich ist, was son bisschen euer aktuelles Geschäftsmodell dahinter ist.
Christian: Genau, also wir also wir haben eben, wenn man irgendwie wieder zurückgeht, mit Langgraf angefangen. Viele unserer Kunden benutzen halt immer noch Langgraf. Die bauen halt immer noch diese Notes auf und haben halt relativ sehr, also spezifische Workflows, die sie abdecken wollen dadurch. Und wir sehen halt mehr und mehr Leute jetzt sonen Create Agent, die bauen halt son Create Agent oder gehen halt eine Stufe weiter höher, bauen halt 'n Deep Agent und hoffe, dass halt viele Leute auch diese Managed Deep Agent benutzen, weil's halt einfach einfacher ist, gewisse Wenn man das schon 3, 4 Mal gemacht hat innerhalb der Firma, dann merkt man, okay, das Pattern bleibt das Gleiche, ist eigentlich nicht immer anders und es gibt nicht wirklich Ich würde sagen, es gibt nicht wirklich immer, jeder Workflow braucht nicht immer gleich 'n Agent. Also es gibt viele Workflows, wo man mit Langraf sogar besser aufgestellt ist, weil der die Schritte, die man macht, die sind halt immer die gleichen. Man hat halt 'n paar LLM Calls in gewissen Notes drinne, die dann einem helfen, gewisse Workflows abzubilden. Aber Deep Agent kann auch 'n bisschen Overkill sein für gewisse Sachen, wo die Aufgabe relativ einfach ist, wo man keine Sub Agents braucht, wo man keine Sandbox braucht, wo man einfach nur gewisse Informationen zurückgehen will, basierend auf Daten, die sich in der Datenbank befinden zum Beispiel. Also dahingehend gibt's nicht wirklich so, man sollte immer Deep Agen benutzt oder immer auf 'ner Agent Harness zurückgreifen, die es so im Markt gibt. Da bietet Lang Change schon sone sone Auswahl an, so an von wie viel Intelligenz willst Du in so 'ner Harness packen oder wie viel Komplexität willst Du da reinhauen?
Dennis: Liek ich falsch mit der Aussage, wenn das Gefühl ist, dass es gerade irgendwie für Unternehmen und das Rollout von solchen Dingen irgendwie auch interessant ist, weil man gerade durch Observability, also weißt Du auch dieses Optimieren und sowas. Ist das auch 'n Use Case, den ich so als Single Contributer, ich mach irgendwie mein eigenes Ding, wo ich von profitieren kann oder sind das Features, die eher in 'nem Unternehmenskontext gut funktionieren?
Christian: Observability im großen Rahmen, glaub ich, eher fürn Unternehmenskontext, wenn Du jetzt deinen eigenen Agent baust, der dir beim Maintain 1 1 Repository hilfst, da guckst Du wahrscheinlich eher selten in die Observabilities rein, weil Du eher an die an den Agenten Resultaten interessiert bist. Ich glaube, jeweils auf der anderen Seite sind halt immer gut, weil Du halt immer versuchen willst, dein Agent zu tunen. Grade wenn Du deine Hahnes selber aufbaust, ist es halt immer gut daran gelegen, E-Bike zu bauen. Ich kann ein Beispiel nennen, ich habe, das nennt sich, ich hab's schon wieder vergessen, aber ich das nennt sich Zeitzeuge. Zeitzeuge dot dev, hab ich einfach mal gebaut, Performance Probleme in meiner Javascript Applikation zu finden. Und den hab ich halt jeweils gegeben, einfach 'n Code Repository, wo ich gewisse Probleme eingebaut habe und ich habe halt jeweils drum gebaut, herauszufinden, ob der der mein Agent dann all diese Probleme findet und die richtigen Vorschläge macht, die Probleme zu beseitigen. Und glaube, son für jeden Use Case, wo wo man dann son Agent baut, ist, glaube ich, so jeweils das Einzige, wo ich sagen würde, ja, das ist schon interessant für jeden Agent. Das muss man nicht bei uns laufen lassen, das kann man auch einfach lokal laufen als sone Art Test. Ich glaube, wenn's darum geht, so, wenn man Production Load kriegt, das heißt, wo man dann deine Agent von Leuten in deiner Firma benutzt werden und dann ist es schon interessant so zu sehen, okay, ich kann mir aus diesen Traces, die durch die Observability erstellt werden, Datensätze bauen, die ich dann über jeweils laufen lasse, halt 'n besseres Bild über die Fähigkeit meines Agenten zu bekommen.
Jan: Wär's eine richtige Einordnung zu sagen, Observability ist eigentlich immer dann interessant, wenn ich davon ausgehe, dass mein Agent denselben Job halt wirklich mehrere Male macht, ja. Also wenn ich jetzt, weiß nicht, ich hab hier unseren unseren Slack Agent, der unser Conference durchwühlt oder so was, nicht, weil wirklich gucken, okay, wird er besser oder schlechter da drin, so Ergebnisse zu finden, ne, oder ich hab 'n Agent, der unsere bi Dashboards baut oder so nicht wir wissen, okay, wird er besser oder schlechter oder schafft er überhaupt die Aufgabe zu erfüllen in in den meisten Fällen so, ja? Wohingegen, wenn es jetzt so dein privater Agent ist, dein Openclown oder dein Pi oder so was, dann zu sagen, na ja gut, der macht ja immer sehr viel unterschiedliche Aufgaben meistens nur einmal und da da kann sich quasi gar nicht son son Pattern ergeben, was überhaupt mit Observability anschauen kann.
Christian: Ja, und Du gehst auch davon aus, dass wenn Du 'n Agent benutzt, wie ich zum benutze zum Beispiel Curser als Coding Agent. Ich geh mal davon aus, dass die Leute bei Curser ihre eigenen jeweils laufen lassen und die diesen Agenten selber testen. Da brauchst Du, wenn Du 'n Agent von jemand anderes benutzt, dann hoffst Du, dass die dass der durch jeweils gut abgedeckt ist. Das machen wir mit Debagen genauso. Wir haben mehrere jeweils Laufen und jedes Mal, wenn wir in der Hahnes was verändern, sei es eine System prompt oder wir nennen einfach nur 'n Pool dann laufen wir die komplette Hahnes, die kompletten jeweils Sets durch, zu sehen, dass es da nicht irgendwelche Änderungen gibt. Ich glaube, bei wenn man halt son Agenten selber baut für seinen eigenen Use Case, dann sind jeweils schon sehr hilfreich, weil man genau weiß, okay, ich bau den Agent, Problem x zu lösen und kann dir dieses Problem x auch mit diesen Inputs zuverlässig lösen.
Dennis: Und würdest Du, oder funktioniert das dann auf dieser eine Ebene höher oder Ebene nicht mehr, wenn man jetzt, Du meintest gerade, wenn ich jetzt irgendwo eine 1 Programmieraufgabe hab und will unterschiedliche Coding Agents miteinander vergleichen. Ist das auch was, wo Du sagen würdest, das kann man damit machen oder ist das dann außerhalb des Scopes?
Christian: Also es gibt ja die sogenannten Benchmarks. Terminal Bench ist zum Beispiel ein sehr bekanntes, welches dir quasi eine Reihe von Problemen gibt und Du kannst es in so 'ner Harnest einpacken, die quasi alle Agenten laufen lassen kann. Das nennt sich Haber, ist mittlerweile 'n relativ bekanntes Framework, halt gewisse Problemsets auf diverse Agenten loszulassen und dann gibt's halt sone Sache wie Terminal Bench, wo Du sehen kannst, okay, für dieses Set auf Problem, Coding relatet, schneiden diese Harnnessel unterschiedlich ab. Das Ding mit durch 'n Terminal Benches oder mit Benchmarks generell ist, dass wir, dass es oft so ist, dass die Teams dann versuchen, auf diese Probleme, die diese Bändchen hier gibt, quasi zu optimieren. Und das ist dann Dann dann hast Du ja wieder deinen eigenen Bias drin für Weil die Probleme sind ja auch speziell in 'ner gewissen Art und Weise und kommen wahrscheinlich im Alltag eher weniger vor. Das heißt, wir sehen, dass es nicht immer das Beste ist, wenn man Also es muss nicht immer heißen, wenn irgendein Mhm. In Terminal bench gut aufgestellt ist, dass es auch generell eine gute Hahnes ist, das das würde ich dann immer bezweifeln.
Dennis: Ja, da kann man gerade ein bisschen Gedanken, hey, ja, weil wir ne, hier auch immer mal wieder Diskussionen haben, jetzt irgendwie ein neues Modell rauskommen, dann nutzt jetzt 1 irgendwie Faible 5 oder eine oder eine andere Cloud Opos oder der GPT 5 5 oder 5 6 oder was auch immer und bis jetzt ist es halt immer son Gefühlsding son bisschen auch ne, also dass man sagt, ja okay, hat jetzt vielleicht besser funktioniert, wenn man den Thinking Mode auf irgendwas stellt. Ob es dir sinnvoll erscheinen, ob man dann praktisch son eigenes Benchmark oder eigene IBS macht für das Environment, was man selbst hat, also ne, die Projektstrukturen, die Aufgaben, die und so weiter.
Christian: Ja, wie gesagt, da würde ich da reingehen, wenn man eine Hahn ist von jemandem anders benutzt, dann würde ich davon ausgehen, dass die Hahn ist schon relativ gut getuned sein sollte. Nur wenn man seine eigene, wenn einen eigenen Agent baut, der wo man seine eigene Tour zur Verfügung stellt und seine eigenen System prompt dazu schreibt, dann glaube ich, sind jeweils schon gut, dann das Tuning zu starten und quasi zu versuchen, dann diesen die Fähigkeiten zu verbessern. Weil tatsächlich, also, da kommt es wirklich auf Nuancen Hand, manchmal in 'ner System Form, wie son son Agent sich verhält. Ich hab das gestern bei 'ner, ich hab eine Demo gebaut und wollte halt diesen Agent, dass der die meine Sub Agents dann parallel ausführt und hab dann Ewigkeiten gesessen, irgendwie die Systemprom tausendmal getweeed und dann irgendwann festgestellt, ach, wenn ich von GPT 5 Punkt 5 auf Cloud Code umsteige, also das Model änder, funktioniert das alles relativ besser. Und tatsächlich kann man gibt's da noch für gewisse Probleme andere Models, die besser funktionieren. Da gibt's bestimmt auch viele Storys, die andere haben, wo man sagt, oh Coding, da benutze ich gerne Cloud Code, aber wenn's darum geht, irgendwelche komplexen Probleme zu analysieren, dann schicke ich ja GPT 5 Punkt 5 vor, mir das alles zu quasi zu erläutern.
Jan: Du hast vorhin gesagt, bei euch in der Firma hat eigentlich jedes Team mindestens einen Agenten irgendwie am Start für verschiedene Aufgaben. Da hätte ich 2 Fragen noch zu. Zum einen, wie wie wird son Agent bei euch gescopt, ja, weil das ist ja oftmals eine Entscheidung so, will ich einen sehr spezialisierten Agenten, ja, will ich im Financeteam einen Agenten, der sich halt optimal in meinem Data Warehouse, was auch immer auskennt und da Dashboards schrauben kann oder, oder, oder. Oder will ich halt einen sehr breiten Agenten, der alles son bisschen kann, dem ich vielleicht mit 'n paar Skills hier und da noch unter den Arm greife, aber ich will mich nicht jedes Mal damit beschäftigen müssen, welchen Agenten ich jetzt frag. So wie wie trefft ihr da eine 1 Abwägung?
Christian: Ich glaube, die Best Practice würde ich sagen, es ist immer auf das Problem zu schauen, welches Problem am besten funktioniert oder welches Problem man so quasi isolieren kann und dafür den Nagetten zu bauen, weil man kann dann da hingehen und sagen, wenn mein Team irgendwie 5 verschiedene Probleme hat, dann würde ich irgendwie ungern Nagetten bauen, der irgendwie 100 Tools hat, diese 5 Probleme abzudecken. Was man besser machen kann, ist sagen zu sagen, okay, ich bau einfach einen Agenten, der mir das eine Problem löst. Dem gebe ich dann 10 Tools, die es dafür braucht. Es kann dann mehr effizienter arbeiten und gebe diesen diese 5 Agenten, die ich dann baue für die 5 Probleme, die setze ich dann als ins Sub Agent to 'n Orchestrader. Und dann quasi gibt es dann nur 'n Orchestrader, der sich dein Problem anschaut und sagt, oh, der der Jan, der möchte das Problem lösen, dann schick ich mal das Problem zu den Sub Agent und der Sub Agent kann dann isoliert mit den wenigen Tools, die es braucht, das Problem für dich lösen. Also es am besten Agent Engineering, geh doch dahingehend, versuchen ein Problem zu isolieren, die richtigen Tools zu finden, weil wenn man zu vielen Tools einem Agenten gibt, dann dann hat man, dann dann bläst man den Kontextwindor auf, der was man ja auch nicht möchte. Also für Effizienz natürlich immer versuchen, das Problem zu isolieren, die wenigsten Tools dem Agenten zur Verfügung zu stehen, dass es braucht, sodass es nicht viel überlegen muss, was es jetzt machen soll. Die richtigen Skills zur Verfügung stellen, den richtigen Ansatz zu dem Agenten hier Informationen zu geben, wie der richtige Ansatz zum Problem ist. Und dann kann man das skalieren, indem man das diese Agenten dann als Sub Agents an 'nem Orchestrrator anhängt und der kann dann entscheiden, wo es langgeht. Oder man kann son Agent dann auch innerhalb von Langgraff starten, wo man sagt, okay, ich hab verschiedene Prozesse, die halt sequenziell laufen, wo ich dann sage, okay, ich geh zu dieser Note oder zu der nächsten Note und dann erst laufe ich, lass ich die Nagenten laufen. Da gibt's quasi also sehr viele Möglichkeiten, die man das dann zusammenbauen kann am Ende.
Jan: Ja, ich denke auch grad son bisschen an unsere Use Cases hier, ne. Wenn wir jetzt allein nur für die Programmierer gar nicht mal ans große Lotum irgendwie denken, Du brauchst jemanden, der die Shownotes macht, jemand, der vielleicht Recherche vorbereitet, jemand, der die Cover Assets erstellt und das ist ja auch so. Das könnten alles verschiedene sein, es könnte aber rein theoretisch auch 1 sein und was jetzt bei Christian rausgehört hab, ist eher so, vielleicht unterschiedliche Adrens dafür bauen, mit gegebenenfalls im einen Orchestraate drauf, so als, ich sag mal Convenience Layer oben drüber, dass ich nicht mit 5 unterschiedlichen reden muss.
Christian: Ist ja im echten Leben auch so. Also kannst natürlich einen haben, der quasi sich alle mit allem son bisschen auskennt oder für jede Problem irgendwie seine Spezialisten.
Jan: Ja, ja, richtig, richtig. Und wenn Du das gerade schon so schön beschrieben hast, wie ihr das zusammensetzt, dann frage ich mich natürlich auch, wer baut es denn bei euch? Also muss ich mir das so vorstellen, dass jetzt euer Finance Team sich selber hinsetzt und die sich überlegt, wie son Agent zu skopen ist und dem die Tools an die Hand gibt und sich dann den Orchestrarator dazu ausdenkt und und und. Oder ist das immer noch eine sehr technische Challenge, wo tatsächlich dann auch Entwickler mit 'nem Facheam zusammensitzen und hat so, okay, wir bauen hier mal was für euch und wir machen hier auch die Observability und wir maintainen das quasi auch oder ist da schon richtiger Self Service möglich?
Christian: Wir haben 'n Produkt, das nennt sich Fleet und das ist quasi 'n Agenten, das ist 'n Agent, der Agent baut. Du gehst quasi hin und hast eine einfache Text Bond, wo Du sagst, ich brauche einen Agenten, der mir das und das erledigt. Und Lead hat halt Zugang, kannst Du einrichten zu deinen E-Mails, zu deinen Systemen wie Jira oder was auch immer man benutzt und kann dann quasi den Agenten für dich zusammenbauen. Dann klickst Du okay, super speichern und dann kriegt die Person seinen eigenen Prompt oder seinen eigenen seine eigene Seite, wo man dann quasi diesen Agenten prompen kann und er kann dann für einen arbeiten. Also selbst die Leute, die nicht technisch sind, können sehr einfach Agenten bauen, bei indem sie einfach nur ihre Integration verknüpfen und dann 'ner anderen Agenten sagen, hey, brauchen wir mal mit meinen Agenten zusammen. Meta Agent.
Jan: Mhm. Mhm.
Dennis: Der dann auch bei euch deployed wird.
Christian: Genau, der wird dann über unsere Plattform deployed, hat sein eigenes Tracingprojekt. Das heißt, wenn Leute interessiert sind, sich die Traces anzug schauen, können sie das machen. Wir haben auch Land Landchain Engine haben wir jetzt erst kürzlich released, dass halt dieser Agent, der sich diese Traces automatisiert anschaut und dann deine Agenten dann automatisch auch updated und verbessert. Das das das geht auch für Non, also für Leute, die halt nicht technisch sind, die können Agenten in 'ner gleichen, einfachen Weise auch herstellen.
Dennis: Und da ist es mit Human Feedback diese Optimierung oder komplett LLM gesteuert?
Christian: Mit Human Feedback, also wenn's irgendwelche Informationen gibt, die der Agent braucht, dann jeder, also entweder bei der Erstellung oder bei der, wenn der Agent komplett ausführt, dann kann der Agent immer einen Interview ausgeben und sagen, hey, ich brauch diese Informationen und die kann man dann
Dennis: eingeben. Mhm.
Jan: Vielleicht ist das 'n guter Zeitpunkt, noch mal über das Geschäftsmodell zu reden, dass Du nämlich vorhin schon mal kurz drauf abgestellt, dann sind wir irgendwo falsch abgewogen und haben haben nicht mehr drüber gesprochen, weil also Inference ist ja ist ja nicht, sondern die ganze Infrastruktur drumherum, ja, so wie ich das verstanden hab. Das heißt, wie muss ich mir das denn jetzt vorstellen, wenn ich jetzt mein Agent mit Language bauen will? Es heißt, ich bring meinen eigenen Key mit zu 'nem Modelbetreiber meiner Wahl und dann bezahle ich bei euch aber noch was
Christian: und wofür? Also im einfachsten Falle bezahlst Du nichts, wenn Du erst mal nur testen willst. Also man kann immer 'n Account erstellen, dort 'n Agenten deployen und sehen, was der so macht. Natürlich, wenn's dann irgendwie ins Eingemachte geht und mehrere Agenten bauen will, dann bezahlt man irgendwann für den Sitz. Aber es gibt immer Ende des Tages bezahlt man für die Menge der Agenten, die man bei uns laufen lässt, weil die brauchen Computing und das müssen wir natürlich dem Kunden dann eine Rechnung stellen. Die Datenmenge an Traces, die wir für Agenten speichern und auch grade hinsichtlich, wie lange wir diese Daten einbehalten, kostet dann am Ende Geld und das ist mittlerweile die 2 großen Einnahmequellen, sagen wir mal. Ich kenn mich jetzt mit dem Pricing, weil ich ich geh einfach nur auf die Plattform drauf und krieg alles umsonst, aber ich
Jan: kenn's praktisch, wenn man Mitarbeiter ist, ja.
Christian: Ist immer 'n bisschen schwierig, aber ja. Also unsere Haupteinnahmequellen sind meistens, also sind im Endeffekt das deploying der Agents. Viele Leute wollen das auch nicht auf unsere Plattform haben, die wollen quasi eine Version von Longchain auf ihren eigenen Servern betreiben. Das kostet dann auch noch mal extra die ganzen Geschichten oder auch wenn Du deine Daten woanders speichern musst, da gibt's halt viele Modelle, wie Ja. Du dir das zusammenbauen kannst und also aber generell geht's darum dann das Bezahlen vom Computer, wenn wir in Agenten hosten, sowie die das Speichern der Daten und das das kostet dann.
Jan: Ich glaub, der Vergleich, der sich am ehesten anbietet, das wahrscheinlich so ähnlich wie bei Börcell. Du zahlst son bisschen was pro seed und danach ist alles von deiner Usage Ja. Abhängig, Mhm.
Dennis: Was man
Jan: da so macht. Okay, vielleicht riskieren wir noch einen Blick in die Ach so, nein? Noch nicht? Wir riskieren noch keinen Blick?
Dennis: Nee, ich wollt gerade noch einmal, weil Du meintest, das andere große ist das Observability und dann hat's ja Anfang auch anfangs auch gesagt, es gibt viele Kunden, die ausschließlich diesen Part nutzen.
Jan: Mhm. Und
Dennis: ist es hauptsächlich für den Use Case, die den Agenten oder das, was rum ist, zu optimieren? Oder ist es auch irgendwie
Christian: in die Fehler? Also es kann ja, es kann ja bei grade bei Agenten, die halt relativ länger laufen, kann's halt immer passieren, oh, da wird dann ein Tool Call falsch ausgeführt und dann passiert das mal bei einem Agenten und dann mal beim Zweiten. Da gibt's 'n Und man will auch nicht immer in die Patterns, also nicht in jeden Trace reinschauen, weil das dann auch relativ viele Daten sind am Ende des Tages. Da gibt's halt dahingehend, dass es halt die unterschiedlichen Observability Plattformen gibt, die halt unterschiedliche Features geben, zu verstehen, wie son Agent funktioniert im im Hintergrund. Und viele benutzen halt Observability, ihre eigenen Datensets zu erstellen, gleichzeitig auch jeweils laufen zu lassen. Ich glaube, Observability und jeweils gehen auf das Hand in Hand. Ich glaube, da gibt's wenige, die einfach nur ihre Traces zu uns schicken und damit dann auch nichts machen. Also öfters werden dann die Traces dann auch zur jeweils Optimierung benutzen. Aber dann benutzen, müssen die dann nicht unsere Tools für jeweils benutzen, sondern können auch ihre eigenen Tools mitbringen, weil wir am Ende des Tages stellen auch nur diese Datensätze bereit und Du kannst dann mit deinen eigenen Traces die Datensätze erstellen und dann dadurch quasi die dein den Agent testen.
Dennis: Die haben aber auch schon
Jan: während dem Development einfach superhilfreich vor. Wenn Du dich daran erinnerst, wie wir unser Agentic Spiel gebaut haben im letzten Game Jam, da haben wir uns ja selber son Log für das Tool Calling im Prinzip eingebaut, einfach nur zu sehen, okay, Du gibst jetzt dem Model was und son bisschen zu beobachten zu können, na ja, verhält es sich auch so, wie Du das erwartest und benutzt es die Tools, die Du eben gibst, so wie Du das irgendwie angedacht hast. Das ist ja vom Development auch schon interessant irgendwie, das zu sehen.
Dennis: Ja. Und da gibt's da dann noch irgendwas, was ihr automatisiert oder mit AI anbietet, das zu evaluieren und zu optimieren oder ist das erst mal nur die Sammelschicht?
Christian: Wir sammeln die Daten und bieten dir die Agenten an, quasi über die Traces zu schauen, Okay. Verschiedene Patterns zu finden und sagen, hey, bei dem Two Call macht sendet dir die Agent manchmal falsche Informationen und dann diese lang Langsmith Engine kann dir dann auch gewiss zusätzlich dann sagen, wenn Du das änderst in deinem Agent, dann sollte der besser laufen. Und dann kann man sagen, okay, ich möchte diese Änderung an 10 Prozent meiner User ausgeben, zu sehen, ob das tatsächlich dann auch Verbesserungen zeigt.
Jan: Mhm. Dann schauen wir jetzt in die Glaskugel,
Dennis: wenn das dein Wunsch ist.
Jan: Du hast eben schon gesagt, Christian, dass so Identity grade 1 der großen Challenges ist, mit der ihr euch beschäftigt, weil das immer relevanter wird bei dem kollaborativen Einsatz von Agenten. Was sind denn so danach oder darauf aufbauen so die die nächsten großen Hürden, die ihr so antizipiert?
Christian: Das ist eine gute Frage. Ich glaube, es kommt immer darauf an
Jan: Endlich eine Stunde später und wir haben's geschafft, die 1. Gute Frage zu stellen.
Christian: Also die also ich kann ja heute sagen, okay, das ist morgen das große Thema, aber dann ist auch schon wieder übermorgen und in unserem in dem Feld im AI Bereich ändern sich auch so viele Also wenn man einfach nur mal 6 Monate zurückgeht, dann hätte ich nicht gedacht, wo wir jetzt heute stehen und ich glaube, was in der Zukunft interessant werden kann, wo wo wir 'n spannendes Feld sehen, ist die Open Waides Models, die mittlerweile immer besser wären. Ich kann mir nicht vorstellen, dass jede Großeorganisation wie Hunderte von 1000 Euros an an an Tropic oder OpenAI jeden Monat überweist, gewisse Agenten laufen zu lassen. Dahingehend sehe ich, finde ich 'n spannendes Feld, wie man diesen Open Waides Models für sich selber tunen kann und für sich selber aufbauen kann, halt Also ich kann sehen, dass jeder später für jeden jede Agent wird später vielleicht sein eigenes getuntes Model kriegen, das basierend auf 'nem Open wait Model, das aufm Open wait Model basiert, das durch die Daten, die eine Firma so aufnimmt, trainiert wird oder gefeintunet wird und dadurch wirklich super funktioniert für den Use Case, den für den das Model gebaut wurde, aber nicht für andere Model. Also diese generellen Models, die Frontier Models, ich glaube, das wird irgendwann in den in den nächsten Monaten zurückgehen und die Open Rates Models werden bald immer mehr Popularität finden, grade im Kostenbereich, aber auch in 'ner Hinsicht, wie man das dann auch selber tunen kann. Gerade wie wir unsere eigene Agenten bauen, kann man vielleicht in der Zukunft die Models einfacher tunen und für seinen Use Case aufbauen. Ohne Nvidia oder anderen Firmen irgendwie Tausende von Euro für Grafikkarten zu bezahlen, sondern da gibt's wahrscheinlich werden mittlerweile schon Firmen aufgebaut, die sich auf solche Services spezialisieren.
Jan: Da meine Frage vielleicht an euch beide, weil wir das ja in den letzten paar Monaten ja auch schon immer wieder gehört haben, diese Open Way Models, die so am Aufholen sind und ganz oft wird dieses Kostenargument, Christian, was Du auch grade angeführt hast, genannt, ne, Firmen wollen sich son bisschen unabhängiger von ihrer Rechnung an Open AI oder wen auch immer machen, aber am Ende brauchst Du ja trotzdem Inference. Also ist ja egal in Anführungszeichen wessen Model ich benutze, aber irgendwo muss ich's ja trotzdem ausführen oder ausführen lassen. Also irgendjemand lässt sich das ja am Ende des Tages trotzdem bezahlen und irgendjemand braucht trotzdem teure GPUs dafür. Kann das wirklich son großes Argument sein, aufn offenes Modell zu wechseln, nur weil ich da nur weil ich da Geld spare, weil auch die auch die offenen Modelle müssen ja, also zum einen, wie gesagt, betrieben werden, aber auch ja erst mal entwickelt werden. Auch das muss ja irgendjemand nachhaltig finanzieren können. Und ich frag mich bei dieser Argumentation immer, ist das, also ist das wirklich so einfach zu sagen, ich geh jetzt auf mein was ist das neueste? Kimmy, Gwen, keine Ahnung so. Ich nutze jetzt 1 von denen und dann wird meine Rechnung nur noch 'n Bruchteil sein von dem, was es vorher war?
Christian: Bitte zu zu handhaben, Versantwort Dennis?
Dennis: Ja, also ich mein, ob man's sicher sagen kann, aber zumindest für mich deuten alle Trends dahin, dass es so sein wird. Also erstens, weil Du es auf Hardware, die jetzt nicht irgendwie H2hundert irgendwas ist oder sowas laufen lassen kannst, sondern jetzt schon in Bereichen bist, ne, wo Du vernünftige Ergebnisse von mir aus auf deinem M5 MacBook oder sowas erzielst, das ist das eine, weil wir zweitens sehen, dass dauerhaft Optimierungen auch in der in der Interference sind und ne, wie viel mit wie viel weniger Power man auch solche großen Modelle teilweise laufen lassen kann, gerade wenn das dann auch noch diese Open Rates Modelle optimiert ist. Ja, und so das, da ist ja eher mein Tag, ich hab ja gelernt in unserer Diskussion, dass ich vielleicht eher darauf gehe zu sagen, okay, ich kann mir nicht vorstellen, dass teuer wird so. Vielleicht eher bei der Aussage zu bleiben, ich kann mir vorstellen, dass die Intelligenz, die wir aktuell haben, teurer wird so, ne. Es kann passieren, dass irgendwie Du noch mehr willst und es sinnvoll ist, noch mehr zu also mehr zu nutzen davon, aber auch nur, wenn damit einhergehend dein dein Benefit, dein Output, den Du hast, ebenso skaliert so zu und dann dann ist es auch wirtschaftlich wieder ne sinnvoll. Dann kannst Du auch von mir aus 100000 Euro im Monat ausgeben, ne, wenn Du irgendwie den Benefit davon hast, aber das halt so der der Preis für Intelligenz, den sehe ich halt nicht, dass der da da steigt. Von daher, ja, glaube ich schon, dass das auch 'n Kostenargument ist und wo wo man schon sieht so, das wird in 'nem Rahmen sein, der der okay ist. Christian?
Christian: Ja, ich ich stimm dem zu. Auch aus wissenschaftlicher Sicht, glaube ich, ant Tropic und OpenAI wollen ja auch keine Milliarden von Dollar ausgeben, diese Models zu trainieren. Ich glaube, viele viel Research geht auch gerade dahin gehen, wie kann man solche Models trainieren in in immer einfachen Formen, immer optimisierter, dass man relativ schnell mit wenig Compute gute Resultate erzählen kann und dahingehend glaube ich, dass das in der Zukunft möglich sein kann, diese diesen Use Case zu betreiben und auch wenn man, sagen wir mal, Firmen wie Firworks benutzt, Models zu fine. Es braucht ja nur 'n bisschen, aber wenn man dann halt 'n Open Source oder Openway Model fine tunen mit 'n bisschen Weil man da 'n bisschen Geld reinsteckt und dieses Feintuning kann alleine schon den Unterschied machen, gerade für wenn man dieses Model für einen gewissen Use Case innerhalb 1 Firma benutzt. Und wenn man dann das dahin gehen kann und sagt, ich nehm das Model und laufe das halt, lass da halt nur über meine Firma laufen, dann hast Du heute auch nicht die Probleme wie, werden meine Daten benutzt, das Model zu trainieren? Ja. Das ist auch gerade, warum ich noch nie bis jetzt, seit den letzten 3, 4 Wochen, Paper konnte ich noch nicht benutzen, weil Paper, die diese Data Disclosure hat, dass man nicht ausstellen kann, dass sie die Daten, die Faible einzieht fürs Turnieren benutzen. Das konnte durft ich durch meine Firma gibt's halt diese Policy, dass wir das machen können. Daher konnte ich auch noch nicht Faible benutzen und das da so was gibt's halt, wenn man in die Massenadaption schaut, dann wird's für viele Firmen gehen, die das damit auch nicht eingehen und die werden dann auch ihre eigenen Open Rates Models benutzen.
Jan: Mhm. Ich hab deine Frage unterbrochen mit meiner Geldfrage.
Dennis: Vergessen. Okay. Ich glaube, er hatte gerne, oder? Hab ich schon irgendwas ausgesprochen?
Jan: Nein, nein, ich hatte doch irgendeinen von euch grade unterbrochen, weil ich gedacht hab, ach so, ja genau, wir waren ja grade bei Christian mit, was sind was sind so die Tendenzen, die wir so in Zukunft hätten, dann sind wir bei Open Bereich alles hängen geblieben. Okay.
Christian: Aber ich glaube dahingehend, dass es dass wir das Entwickeln von Agenten wird immer einfacher sein. Wie gesagt, mittlerweile hast Du diese No Code Tools wie wie langchain Fleet, wo Du einfach nur eine Prompt eingibst und Agent wird für dich erstellt. Ich, ist immer interessant, wenn ich dann mal meine Freunde in in Sachsen Anhalt besuche, wenn ich mal nach Hause fahre und dann frag, die arbeiten dann bei Siemens oder VW und dann frage, was macht ihr so mit Agenten und da kommt dann halt noch nicht viel raus. Ich glaube, da gibt's noch eine Riesenkurve von Firmen, wo die halt erst mal anfangen, IR halt zu benutzen und sich damit erst mal auch einstellen, diese Workflows über Agenten laufen zu lassen. Und ich glaube, da gibt's eine Menge Arbeit oder eine Menge Agenten, die gebaut werden müssen, bis wir in 'nem mehr intelligenten Zeitalter leben können.
Jan: Das vielleicht noch eine spannende Frage, haben wir ja vorhin beim Mittagessen zufälligerweise auch drüber gesprochen so. Wer nutzt das eigentlich grade schon wie vielen, ne, wenn Du jetzt sagst, okay, die, okay, also deutsche Großkonzerne kann ich mir vorstellen, dass die jetzt noch nicht so ganz vorne mit dabei sind, Agenten irgendwie zu nutzen, aber hast Du son Gefühl dafür oder gibt's da vielleicht so klare Trends, wen ihr so in eurer Customer Base seht, wer da am motiviertesten ist?
Christian: Wir haben tatsächlich, also es ist wenig es ist weniger geht's darum, was die Firma macht, sondern mehr darum, wo die Firma ihren Hauptsitz hat. Also alle alle Firmen, die so in unserer Silicon Valley Blase sich befinden, die da von von A bis Z sind alle dabei, die versuchen irgendwie auf diesen diesem Pferd aufzuspringen. Also mittelständische Unternehmen aus anderen Bereichen, in anderen Regionen der Welt, da ist es halt wahrscheinlich noch nicht so ganz angekommen. Ist halt auch irgendwie sone Blase, in der wir hier gerade drüben leben.
Jan: Ja, ja. Müssen wir noch 'n bisschen die Werbetrommel rühren. Ja.
Christian: Also oder einfach mit einem Spülprofil.
Dennis: Ja genau. Blase kann man ja auch durchaus negativ sehen im Sinne von, dass sie irgendwann platzt, aber ich glaube, Du meinst eher den eingegrenzten Kreis an an an Menschen, der da den Zugriff drauf hat und da sehen wir uns ja irgendwo auch ein bisschen, dass wir da einigermaßen Ab spirituell sind wir quasi
Jan: im Silicon Valley. Genau. Von von der Wetterau an ans Golden Gate. Ja. Cool, dann, wenn Dennis keine Fragen mehr hat. Jetzt ist unsere standardschätzte Frage und unser Gast immer, Christian, welche Frage haben wir dir nicht gestellt? So, auf welches Thema warst Du ultra vorbereitet, wolltest unbedingt drüber reden und ärgerst dich jetzt, dass dich keiner danach gefragt hat?
Christian: Eigentlich, ich bin heute morgen aufgewacht, ich bin heute 5 Uhr 30 aufgewacht, hier heute am Start zu sein, da konnte ich noch nicht so viel überlegen, welche mir gestellt werden sollte. Ich war einfach, oder dass ich mal wieder 'n bisschen Deutsch reden konnte.
Jan: Happy to be of Service, so, ja. Aber vielleicht ist die die Taktik für uns hinzugefügt, einfach unsere Gäste früh überrumpeln und dann können sie nicht so mit so so viel Hintergedanken hier aufschlagen.
Dennis: Sehr gut.
Jan: Wunderbar, dann sind wir mit dem regulären Teil der Sendung quasi durch und was bleibt uns noch? Die Wunderbar und Du hast die Musik nicht angemacht.
Dennis: Endelt hier.
Jan: Wunderbar. Dann würde ich sagen, Christian darf anfangen, weil der Gast ist und ich mich sehr auf seinen Pick freue.
Christian: Mein Pick of the day ist die Show Silicon Valley, die ich gerade auf einmal gewiebinscht habe, weil ich finde, dass das für mich irgendwie grade irgendwie teilweise auch 'n bisschen Realität ist und interessanterweise ist auch irgendwie jede Staffel von Silicon Valley bildet auch immer einen eigenen Lebenszyklus 1 Firma hier im im Valley ab und da wollte ich herausfinden, welcher Season ich gerade mich selber befinde.
Jan: Oh, spannend.
Christian: Und dahingehend war das für mich in den letzten 2, 3 Wochen 'n Spaß, mir die Sendung noch mal einmal komplett durch anzuschauen.
Jan: Sehr gut. In welcher Season befindet sich Langstein jetzt gerade? Das ist vielleicht ja spannende spannende Erkenntnis jetzt noch.
Christian: Ich glaube, ich weiß nicht mal genau, in welcher Season sie in ihrer eigene große Firma mit ihren ersten Entwicklern so, also raus aus Backmans kleiner Hütte. Ja. Aber da sind wir jetzt, wo wir unsere eigene, die eigene Firma haben mit den ersten Leuten und den Sales Leuten, die anfangen, die die Sachen zu verkaufen und die die Dinger großzumachen.
Jan: Es ist ja eigentlich so, Du hast ziemlich gern bei dir nie geguckt, oder? Nee. Also es ist eigentlich so lustig, weil in der in den späteren Seasons haben sie ja auch diesen AI Agent Anton, der in der Garage, am Anfang wohnt er in 'nem Serverrack in der Garage und irgendwann, wenn sie dann eine eigene Firma haben, wohnt er im im Keller im Serverrack und der wird ja quasi wie son eigener Protagonist auf soner Metaebene dadurch und deshalb ist es vielleicht schon halt irgendwie auch
Dennis: noch super passend, dass das halt Ja. Aber mir ist gerade wieder eine Frage, die ich mir jetzt schon jetzt häufiger auf der Zunge erwarte. Ich wollte noch also dich persönlich fragen im Sinne von, wie stressig ist dein Job aktuell? Weil zumindest ist ja so, ne, also ich meine, das ist ja 'n Bereich, wo sich wahnsinnig viel ändert und wenn man dann auch noch irgendwie Infrastruktur bereitstellt und Dinge und Tools bereitstellt, die in diesem Bereich drin sind, dann ist es ja noch mal irgendwo son Faktor zeitkritischer irgendwie. Also wie also wie stressig empfindest Du deinen Job aktuell?
Christian: Schon stressig. Also ich hab immer meinen Job als Hobby angesehen, weil anders hätte ich das irgendwie nicht ausgesucht, hier rüberzukommen, wo man dann tatsächlich versucht optimieren, dass man jede freie Sekunde, die man hat, irgendwie sich an die Arbeit setzt, weil das für mich irgendwie ist son wie son anno fünfzehner 3 Strategiespiel, wo man immer was zu tun hat und irgendwie immer handeln kann und sich immer versuchen, sich irgendwie weiter auszusetzen. Ich merke mittlerweile, ich bin ja jetzt auch schon 37. Das ist tatsächlich, ich kann so viel Zeit reinstecken, wie ich will. Ich werde nie fertig sein. Ich werde immer jüngere Leute haben, gerade die die AI Natives, wie wir sozusagen, wie wir sie nennen, die können mit der in ARDours tatsächlich natürlicherweise besser umgehen als als die wir, die wir schon irgendwie noch händisch programmiert haben, sagen wir mal so. Also es gibt immer mehr zu tun. Stressig wird's dann, wenn man tatsächlich irgendwie diese Deadlines hat und Sachen abliefern muss und dann Sachen nicht funktionieren und viele Sachen gleichzeitig balancieren muss. Aber dahingehend gibt's dann auch, wo man dann am Wochenende dann auch mal abschalten kann und wenn man son Gas Weizen trinken kann, ist auszuhalten, aber deswegen geht man auch hier rüber, so diesen Spaß mitzumachen. So die Nine to five Jobs gibt's halt hier leider nicht.
Dennis: Und 'n Weizen kriegst Du aber?
Jan: Ich wollt grad sagen, stell dir vor, Du bist in Amerika und kriegst nur 'n amerikanisches Weizen.
Christian: Nee, hier gibt's Borlana und und ja, hier gibt's Borlana und die deutschen Hefeweizen gibt's da schon. Ja, Horstschau.
Jan: Schau mal Ach, oh, schau mal was, das not alles lost, so, ja.
Christian: Aber das einzige Problem, was es hier nicht gibt, ist son son guten Döner. Den gibt's nach ganz barrier nicht. Ich hab wir haben schon, ich hab mal von mit mitm Point und dann der Malte von Bécell, der CTO, der wohnt ja auf der anderen Seite der Brücke in in Oakland. Wir wollten schon mal sonen deutschen Stammtisch aufbauen mit, wo wir dann uns dann dem besten Döner in Oakland treffen regelmäßig. Das hat noch nicht geklappt, weil jetzt glaube ich der Döner auch noch nicht ganz so gut ist. 0000000000000000000000000000 son türkisches Brot und dann son Döner zusammenschustern, sollte ja nicht so schwer sein, aber tatsächlich, wenn's jemand da draußen gibt, der guten Döner bauen kann, den und den hier dann irgendwie für 10 Dollar verscherbeln könnte, das das würde mir würde mich freuen und jeden, der hier als Deutscher im Silicon Valley Leben zu knüpfen hatte, haben wir schon. Jetzt fehlt noch der Döner.
Dennis: Sehr gut.
Jan: Also ich mein, wir haben ja, wir kennen ja bei der Poker, mir war schon son paar Leute, die im Valley arbeiten. Vielleicht ist jetzt der Aufruf hier für Dönerempfehlungen in und San Francisco an uns und Ja. Reichen das dann weiter. Oder wenn's ihn nicht
Dennis: gibt, wie gesagt und Ernstke meinte Menschen, die motiviert sind, trotzdem Wobei ich dann, also
Jan: da würde ich jetzt schon meine Hand dafür uns vorlegen, dass niemand im Valley Döner für 10 Dollar verkauft,
Dennis: sondern für 15.
Jan: Ja oder halt für 20 oder 25 oder keine Ahnung, aber ich glaube, ich glaube diesen Preispunkt Christian. Ich weiß nicht, ob man das letzte Mal hier in Deutschland 'n Döner gegessen hat, aber Dönerpreise sind auch sehr inflationär. So.
Christian: Wie sieht denn der Dönerindex bei euch grade aus?
Dennis: Also hier in Bad Nauheim sind wir bei 9 Euro.
Jan: Ja, und das sind ja schon mehr als 10 Dollar und da bist Du noch nicht im Valley.
Dennis: Das stimmt. Okay. Hat man ja 5
Christian: Mark gekostet?
Jan: Ja, das das ist schon 'n bisschen her.
Dennis: So, Moment mal, so alt bist Du, was hast Du gesagt, 37?
Jan: Ja. Da hast
Dennis: Du Döner nicht in dem Markt gezahlt,
Jan: oder? Ja,
Christian: genau, inner Sie
Dennis: macht das doch
Christian: auch das Gymnasium. Vierzehner knapp. Aufm Gymnasium hat er, glaube ich, damals 2 50 gekostet. Hast Du recht, ja.
Jan: Ja. Okay, Dennis hat mit seiner Zwischenfrage genug Zeit geschüttet, jetzt ist er fertig. Was ist dein Pick of the day?
Dennis: Ja,
Jan: den gibt's den Pick.
Dennis: Na, tatsächlich logisch schaue ich jetzt mal richtig was raus.
Jan: Okay. So.
Dennis: Es ist 'n sehr, es profitiert ein sehr kleiner Nutzerkreis von von meinen Pickets und zwar die, die Kinder haben in einem Alter, die noch nicht
Jan: Unglaublich. Glaubnis.
Dennis: Die noch nicht alt genug sind, ein eigenes Smartphone zu haben und trotzdem schon alt genug sind, alleine zu Hause zu sein. Und da ist irgendwie son Gap, wo man dann vielleicht nach Erreichbarkeit und so was guckt. Und dann sone Alexa zu Hause zu haben, wo man einfach mit sonem Sprachbefehl dann im Notfall mal anrufen kann oder sich melden kann, ist sehr viel wert.
Jan: Also ich wir lassen jetzt hier einfach mal unter den Tisch fallen, dass Du vor irgend eine Stunde mit deinem Kind telefoniert hast und deshalb auch irgend 'nem Grund die Inspiration dazu hattest. Aber ich muss sagen, wir haben ja auch son Set-up zu Hause, das ist ja tatsächlich sehr gut. War das vorhin hier 'n Videocall? Ja. Mit sonem Echo Show Dingsbums?
Dennis: Ja, Echo. Nee, Dots ist ja, aber relativ altes Ding, aber ja, irgendwas mit Display und Kamera, ja.
Jan: Ja, weil Dots hat tatsächlich bei uns auch den Unterschied gemacht. Also wir hatten schon diese diese Echo Dots, die nur so Stimme machen, Aber ich glaube, ich weiß nicht, ob das son son kognitives Ding ist, aber es hilft für Kinder, wenn die halt irgendwie sehen, mit wem sie reden. War so mein Eindruck und dann ist es auch besser geworden. Und das ist natürlich auch cool, weil Du kannst ja auch so rum anrufen. Ja. Und je nachdem, wie Du das einstellst per Drop in geht das ja auch schon direkt an, ohne dass sie abheben müssen in Anführungszeichen und dann ist natürlich auch einfach cool schon mal zu sehen, so was da grade Sache ist.
Dennis: Ich hab ja irgendwie, ich hab da noch nicht so viel in den Einstellungen geguckt. Bei uns ist immer noch so verschwommen mein Bild. Ich seh schon irgendwie, dass es da ist, aber erst wenn dann jemand mit dem Gesicht hervorgeht, dann wird's, glaube ich, erst scharf gestellt, Aber ich kann schon rufen, so von wegen. Ja, man hört sich auf jeden Fall schon. Na ja.
Jan: Komm her. Okay.
Dennis: Ja, also von daher, da ich halt andere Erfahrungen hab, wird es wohl Alexa jetzt erst mal sein.
Jan: Ja. Als Aspekt. Wunderbar und bei Zehntausenden Leuten geht jetzt gerade, wo Du das zu dem Lautsprecher gesagt hast,
Dennis: Ja, das geht doch nicht mehr. Alexa, kauf eine Packung Haargummis auf Amazon. Hättest Du
Jan: jetzt auch schon 'n Programmierkonticket kaufen lassen können oder so. Sehr gut. Wunderbar. Mein Pick of the day ist was ganz anderes, was ganz Technisches und nichts, was mit dieser Folge zu tun hat. Ich hab tief in meiner Pick Kiste gewühlt und hab set Servers dot com gefunden. Das ist eine Webseite für alle, die sich son bisschen Operations, Infrastruktur, Serverthemen gerne kümmern und zwar kann man da an so kleinen, aber feinen Aufgaben lernen, wie man so Server and production de backt. Sert Server dot com, traurige Server dot com, Du riechst da drauf, Du kriegst eine, es dauert 'n paar Sekunden, dann fährt wirklich sone kleine VM Setbox hoch, Du kriegst 'n kleines Problem gestellt, so Hier ist ein Lock overflow, finde den Prozess, der daran schuld ist, terminiere den Prozess, aber lass das Lock irgendwie bestehen, bla bla bla und lass das so zum bisschen üben, eigentlich mal ganz nett. Jetzt springt Dennis gleich wieder von der Seite ein und sagt, ah, das macht doch dein Infrastruktur Agent irgendwie alles bald und da muss man sich gar nicht mehr drum kümmern. Das ist wahrscheinlich wichtig, aber ich behaupte immer noch, es gibt son paar Basics, das ist ganz gut, wenn man die mal verstanden hat und wenn man nicht am eigenen Server üben und experimentieren will, ist set Servers dot com eine kleine, aber feine Zwischenübung und die sind gar nicht so groß die Sachen, die kann man sich meine Mittagspause 'n paar Minuten ein oder 2 anschauen und dann bisschen Fingerspitzengefühlübungen machen. Sehr gut.
Christian: Wie viele Leute mögen es noch an Servern rumzufuscheln oder wie viele sagen einfach, ah, schweißt den Server runter, ich starte mir einen neuen? Ja, das hab ich schon. Also ich hab jetzt auch relativ schon. Servern.
Jan: Auch das habe ich schon gemacht, ja, wenn man, weiß nicht, wenn es 'n größeres Update oder sowas ist. Ich meine, er hat ja auch in den letzten paar Jahren, ne, so Entwicklungen wie Docker oder sowas megaviel dazu beigetragen, dass ein sehr großer Teil von einem Setup einfach ultraportabel geworden ist und der Server selbst gar nicht mehr sone große Rolle spielt. Also bei mir laufen auch nur noch Docker Container und wenn ich mit der Kiste nicht mehr ganz zufrieden bin, dann bin ich halt weggeschmissen, neue Provisioniert und die ganzen Container da wieder hochgefahren. Das ist ja schon gar nicht mehr so wichtig, aber wie gesagt, viele von diesen Übungen, ne, grade dieses Lockding, das ist ja unabhängig von der eigentlichen Infrastruktur, das kann man sich auch so mal anschauen und irgendwo müssen die Kinder von heute ja auch irgendwie Bash und so was alles lernen, so.
Christian: Das stimmt.
Jan: Wobei ich weiß nicht, Du hattest heute mit den Studenten die die Einführung gemacht, so lernen die überhaupt noch Bash?
Dennis: Oder schon, ich weiß nicht.
Jan: Schon, ja vielleicht, ja. Ja. Who knows. Wunderbar, damit sind wir durch für heute. Uns bleibt nicht viel zu sagen, außer danke Christian für die Zeit. Danke, dass Du so ultrafrüh aufgestanden bist, deiner Ortszeit nach und die Zeit für uns genommen hast. Es war super interessant. Danke Dennis, dass Du da warst und wenn ihr Fragen, Anregungen, Kritik habt, dann immer gerne an Dennis at programmia Punkt bar. Lob immer gerne an, was Dave, Dave wollten wir
Dennis: auch einrichten. Gibt's auch jetzt schon, ja.
Jan: Gibt's jetzt schon Lob bitte gerne an Dave dann oder so und ansonsten können wir uns auch auf Social Media schreiben überall da Nachrichten hinterlassen, wo ihr uns hört oder seht. Wir lesen alles fleißig mit und wir verabschieden uns. Bis nächste Woche. Vielen Dank Christian. Vielen Dank. Danke dir. Tschau, tschau. Tschüss.

LangChain mit Christian Bromann

Shownotes

Picks of the Day

Alexa

SadServers

Silicon Valley

Speaker Info

Christian Bromann