150 - Understanding Agents: Communication Channels

This podcast is a project of the AI ​​Guild. The content and voices are generated with AI and are used for information and demonstration. Have fun listening! Welcome to the AI ​​Guild Podcast. Today we arrived at the 11th episode of our Friday series Understanding Agents. Today we’re taking a close look at how we actually communicate with our AI agents. Correct. We now have various agents available, such as the Hermes agent. And the really big difference to a classic chat is the choice of communication channels. Exactly. And today we'll discuss which channels are now standard and, above all, how a connection to external networks works, such as WhatsApp. This is a huge topic. And a very important question is whether you can send a task via a channel when the agent is currently working on something else. Or is the channel then blocked? We'll clarify all of this in detail. We also look at how autonomously and in parallel such an agent can work in an isolated environment, for example in Docker or on a dedicated computer. But before we get to the technology, imagine you've hired a brilliant new employee. Okay, I'm imagining it. You ask him to do an in-depth market analysis for you. He nods, turns around, starts working and after exactly 20 seconds he is summarily fired from your internal communications network. Simply because he didn't answer quickly enough. Of course that sounds completely absurd. But that's exactly the situation that happens when you try to connect modern agents to everyday chat platforms. Yes, because this employee I described doesn't fail because of his intelligence. Just can't handle it yet. We really have to completely abandon the idea of ​​how we have previously interacted with large language models. Okay, let's break this down. A classic language model is basically like an extremely clever lexicon. Yes, that's exactly it. You look something up, it generates a text for you and then it immediately falls asleep again, so to speak. It's just waiting. If you want the next step, you have to make the next entry. And if the model makes a mistake, it stops. Correct. It virtually shrugs its shoulders and waits for you to tell it how to correct this mistake. In system architecture we call this the stateless conversation mode. So a mode where people have full control over the process chain. Exactly. You are in control, but you also have to laboriously dictate every single step. But with a real autonomous agent, like the Hermes agent, we are talking about something completely different. It's about targeted action. This means I give him an overarching macro goal in the morning. So I say no more, look for the first competitor on a search engine and summarize the first paragraph. No, not at all. You phrase it much more freely. You say instead, research the pricing models of our three largest competitors in the European market. Compare the hidden items and create a well-founded table. And that's exactly the point at which this dictionary analogy completely collapses. After all, I don't tell my office employees how to open their web browser or what search term to type. Yes, that would be absurd too. You expect him to find the way to the goal himself. And technically, the agent does this through a concept called reasoning in a loop. Reasoning in a loop. OK. How exactly does this work in practice? So, the agent takes a huge macro goal and breaks it down into tiny, manageable sub-tasks completely independently. He then begins to complete these tasks step by step. He accesses a website, reads the text, compares it with his target. And what happens if an error occurs now? That's the crucial thing. If a website is not accessible or the information is behind a payment barrier, then it doesn't just stop. He doesn't come back to you crying. So he doesn't immediately ask me what he should do now. No. He analyzes the failure himself, he corrects his own strategy in real time and tries an alternative path. He really only turns to you when an absolutely essential piece of information is missing. Or if a security policy requires your explicit approval. Understand. Because this agent acts like an independent digital employee, it is actually completely absurd to lock it in an isolated browser window. Exactly. If he works independently, we want to reach him exactly where we spend half the day anyway. Even. We're talking about channels like Telegram, Discord, Slack, Signal, Matrix, good old email and of course WhatsApp. Basically, we want to be able to just send him a quick voice message in the morning while we're making coffee. That's the dream, yes. But the technical hurdle to get it exactly there is really immense. Imagine you are the developer of such a system. OK. If you had to write completely unique code for each of these platforms, taking into account all the quirks of Discord, the data structures of email, and the encryption of Signal, you would have created an unmaintainable nightmare. Because it's constantly changing, right? Exactly. Every time Telegram rolls out an update, your agent would completely collapse. That's why modern systems rely on a so-called gateway architecture. A gateway. In this case, it acts like a gigantic universal telephone exchange, right? It's right in the middle between me as the user and the agent's brain. A switchboard with a built-in simultaneous translator, I would say. The gateway accepts all messages from outside, regardless of their origin or format. It strips away all the platform-specific baggage. So when I send a voice message via Telegram, the gateway picks up this audio file. Correct. In the background, it forwards them to specialized speech recognition models, transcribes what is spoken into pure text and formats this text into a standardized system protocol. And only this clean task then goes to the agent. Exactly. In the end, the agent himself has no idea whether you were speaking or typing or which app you came from. What is fascinating here is the actual added value that is created by the memory of this headquarters. You mean because the gateway sits in the middle, it can capture the status of my conversation across platforms? Exactly that. The gateway manages the user’s identity across all channels. This means that in the morning on the way to work I can initiate a complex data analysis via Slack and in the afternoon, when I'm on the train, I simply write to the agent via Signal and ask what's next with this morning's analysis. Yes, exactly this continuity is the absolute key. It brings together the threads of Slack, Signal and Telegram into a single database. This is presented to the agent as a unified context. To the agent, you are always the same entity, no matter which door you enter the building through. That sounds incredibly elegantly solved. But no matter how well the gateway solves the translation problem, it doesn't solve the landlord's problem, I would say. You allude to closed systems. Correct. When we try to integrate this architecture into the Meta system, specifically into WhatsApp, we suddenly run into a solid concrete wall. Meta is known for maintaining an extremely closed ecosystem. Completely different from the open interfaces of Discord, for example. Oh yes. WhatsApp is truly the ultimate stress test for any agent developer. We are essentially moving in two completely separate worlds. Which are these? The first world is the official architecture over the cloud from Meta. This is the prescribed path that corporations must take. This architecture is based on event-driven signals, so-called webhooks. Webhooks. So like a digital bouncer that lets you know when something happens? Something like that, yes. The agent's system is actually idle. When you as a user write a message, Meta fires a wake-up signal to your server. Sounds efficient at first. It is, but now comes the massive problem. Meta dictates a merciless time frame. Your server has a maximum of 20 seconds to respond to this wake-up signal with a ready response. 20 seconds? That might be enough for a simple chatbot that somehow spits out a greeting phrase. But we're talking about an autonomous agent here? Exactly. An agent who searches the Internet, who draws conclusions and corrects errors. It takes minutes, maybe even half an hour for a complex market analysis. What happens when these 20 seconds have simply expired and the agent is still calculating? Then Meta registers a failure. The system assumes that your server has crashed. It will immediately terminate the connection and classify your platform as faulty. Cool. This means that the agent continues to work in the background, but I never receive the answer. Even worse. Meta may send the message over and over again because it thinks it hasn't been received. This often leads to your server completely collapsing under the load of constant restarts. This official route is effectively unusable for autonomous agents. And how do you solve that then? You can't just ignore WhatsApp. For exactly this reason, developers of systems like the Hermes Agent often resort to unofficial bridges. Wait, an unofficial bridge? But that sounds to me like a gigantic liability risk. That's what it is if you're not careful. I'm not going to tie my company's expensive system to an unofficial solution that probably violates all the terms of use. But isn't such an unofficial bridge against the rules? What about the risk of being banned? My number is blocked faster than the agent can say hello. Your skepticism is absolutely justified. I'll briefly explain to you how this technically works. Such bridges emulate a completely normal human session via WhatsApp's web interface. So the system acts as if it were a human at the browser. Exactly. You scan a QR code in your command line, just like you would in the browser on your laptop. It requires no complicated corporate account, no credit cards, no bureaucratic process. But the risk of a permanent ban from Meta remains astronomically high, doesn't it? Yes, it is if you don't design the architecture with extreme caution. So how do the developers specifically protect the system from being exposed? Through two very fundamental safety precautions. First, strict network isolation. Nobody in their right mind uses their private main number or the official company number for such agent bridges. So you get a disposable number? Exactly. You rent isolated, dedicated numbers, which are often generated via Voice over IP services. This is the first protection case. And the second? Second, and actually more critical, is the agent's behavioral pattern. The agent must be so extremely restricted by software that it only behaves in a conversational manner. Conversational means he only answers when asked. Correct. Under no circumstances should he send proactive messages to people who have not previously interacted with him. No mass messages, no unsolicited status updates. Because otherwise Meta would immediately recognize it as spam. Exactly. As soon as an agent initiates unsolicited conversations, Meta's algorithms immediately recognize this machine pattern. The spam filter then strikes mercilessly and the number is blocked immediately and irreversibly. Okay, that makes sense. But if we have now overcome this hurdle and the agent is actually running safely on the channel, then we land directly on the most pressing question of our consideration today. The blocking. Correct. Imagine I write a huge task to the agent via this WhatsApp connection. I say please download the annual reports of these 50 companies, read them in their entirety and extract all sustainability statements. That takes hours. Definitely, yes. What happens to my chat during this time? Is the window simply blocked for me? Can I add a second, urgent task to the agent in the meantime or is the system stuck in an eternal loading loop? This is a super important question. In a primitive, linearly programmed system the channel would now be completely dead. You would really have to wait until the report is ready. That would be a catastrophe for the workflow. Absolutely. But intelligent architectures avoid this bottleneck through asynchronous task processing and so-called message queues. The secret is simply that the system rigorously decouples the acceptance of your command from the actual execution of the work. Ah, this is where things get really interesting. It's a bit like being in an excellent restaurant. What do you mean? Well, the waiter, who is our gateway in this case, comes to your table and takes the order for an extremely elaborate seven-course menu. But he doesn't go to the kitchen himself afterwards, he stands at the stove and spreads the meat. True. In your field of vision. The communication channel, i.e. the table, is never blocked. This is a perfect illustration. Technically, this is exactly what happens. The gateway's main process saves your task in a database at lightning speed and immediately sends you a tiny, asynchronous confirmation of receipt to a phone. Something like, understood the task, processing has started. Exactly. And at that exact moment, the communication link between your phone and the server is closed cleanly. Meta is happy, the 20 seconds are far from exceeded and your chat is immediately free again. And the actual work? Deep in the background, a completely isolated work process grabs this piece of paper from the kitchen, i.e. from the database, and starts working. This is brilliant. But how do I stop him when he basically cooks the wrong dish? What do you mean specifically? Suppose I realize five minutes later that I wrote sustainability in my text, but actually meant profitability. The agent is now in the background analyzing 50 false documents. If I now text him in the chat, Stop, look for profitability, how does the system manage this conflict in real time? This leads us to the absolutely supreme discipline of system architecture. The system usually offers two different modes for this. The queue mode and the active interruption. Okay, let's start with the queue. Gentle queue mode is technically quite trivial. The agent continues to work calmly on sustainability. Your new message with the stop command is simply passed to the kitchen as the next piece of paper. This means that he only reads the piece of paper when he has finished with the 50 documents. Exactly. Once it's finished after hours, it reads your new command, discards the old result and starts all over again. This is extremely safe for the system because nothing crashes. But that costs me an incredible amount of time and computing power. That's exactly what I want to prevent. If I see him slipping into a complete hallucination, I want to be able to pull the emergency brake immediately. And that's exactly what interrupt mode is for. Technically, however, this mode is a real balancing act. If you send stop, the gateway must fire a hard abort signal to the running work process. Sounds dangerous. That's it too. The massive danger here is that if you simply kill the process, the agent will lose all of its short-term memory. In the second he forgets which of the 50 websites he has already read. Oh, that's bad. And how do you prevent that? To prevent this, the system must freeze the so-called execution graph. Execution graph? What is that exactly? This is basically the map of his thoughts and steps so far. The system stops the calculations at a precisely defined safe point. It takes all the variables that the agent is currently holding in memory, freezes them, and writes this millisecond-precise snapshot to disk. Craziness! So he makes a complete backup of his own brain on the fly. Exactly. It preserves its current state. Then the core system reads your new instructions regarding profitability, injects this new parameter directly into the frozen snapshot and restarts the agent process. And then he remembers what he did before. Yes! The agent wakes up, has retained his memory of the 20 documents he has already read, but from that second he knows that he has to completely change his focus to profitability. This is brilliant. This saves immense amounts of computing resources and, above all, prevents us from having to pay twice for expensive calls to a programming interface, i.e. external server queries. Absolutely. This is a huge economic factor. So if we can now safely stop and start the agent and the channel always remains free anyway, the question of scaling inevitably arises. You mean the amount of tasks? Exactly. If he's working in the background, why would he only do one thing? How autonomously and, above all, how parallel can such a system really work? Can I give him 100 commands at the same time? Whether the system can do 100 things at the same time depends largely on where the physical bottleneck lies. We have to differentiate between tasks that wait for external answers and those that really use up local computing power. Can you give an example? Clear. If your agent queries 50 websites, the system is hardly under load locally. It sends 50 requests out into the world via a programming interface and simply waits for external servers to respond. A well-written system can handle this for hundreds of processes almost simultaneously because the waiting itself does not cost any performance. OK. And the other case? The situation is different if the agent on your machine has to mathematically analyze gigantic amounts of data, for example when calculating huge tables. Then the architecture must be able to physically divide the processes between the different cores of your processor. So that's the hard limitation of the hardware. But what does it look like architecturally? The Hermes agent uses a so-called subagent architecture for such complex cases. So he doesn't handle complex things as a monolithic block, but delegates the work to himself. Right? Correct. This is the principle of isolation through delegation. If you try to load a single large agent into his working memory with ten completely different problems at the same time, he will lose track incredibly quickly. His context window is practically overflowing. Exactly. He then mixes information and begins to hallucinate. To get around this, the main agent creates completely isolated sub-agents for each individual sub-task. So he's basically cloning himself? He clones himself, yes. But he creates severely dumbed-down clones that come with a massive tool limitation. Dumbed-down clones? How should I imagine this? Suppose you have a gigantic document directory and the agent is supposed to find three specific logic errors in the program code. The main agent then creates three subagents. It assigns each of these clones its own tiny folder on the hard drive. So everyone gets their own little box. Exact? And now comes the kicker. Each sub-agent only gets exactly the tools that he absolutely needs for his small goal. They don't have access to the big, long chat history between you and the main agent. You don't even know the meta level. So they really just have total tunnel vision on their specific task. Correct. These three sub-agents now rummage through the files in their respective folders completely in parallel. And the crucial point is probably that after the work is done, they don't send all their data garbage, all their attempts, error messages and drafts back to the main agent. Surely you're just submitting a highly condensed summary, right? Something like bug number one found and fixed, here is the changed line. That's exactly how it works. This protects the focus and the work spokesman of the main agent extremely. Problem. But when we combine this with the bigger picture, we have to issue a huge warning. To what extent? Parallelism always sounds wonderful in theory, but in practice it is extremely dangerous. When you have tasks that are completely unrelated to each other, it's a dream. But what happens when these isolated sub-agents suddenly become dependent on each other? Yes, that's exactly the point. If subagent A needs subagent B's result to even continue, then you suddenly have a synchronization nightmare. Because one then has to wait for the other. Yes, the agents block each other. They wait for each other. And a tiny error in Agent B's data causes Agent A to crash completely. Real, efficient parallelism requires an outstanding system design that razor-sharply separates dependencies in advance. This leads me straight to the elephant in the room we have here. You just mentioned in passing that these sub-agents work completely autonomously on my computer. They write program code, they change files, they search for solutions on the Internet. Yes, they do. That sounds like the ultimate security risk to me. We allow an artificial intelligence that is based on probabilities and can hallucinate at any time to work freely on our operating system. This is a very legitimate objection. In the developer scene this is cynically called the YOLO mode. You only live once. Oh God. And developers who run unprotected agents directly on their main operating system are clearly playing Russian roulette. What's the worst that can happen? Well, an agent with the simple task of cleaning up disk space could, based on a logical misconception, generate the command line command that irretrievably formats your entire file system. Everything deleted just like that. Just like that. Even worse, it could inadvertently read a deeply hidden file containing your most sensitive, unencrypted passwords and transmit this data to an external server the next time you search. Blind trust is absolutely out of place here. But if I can't trust him, how do we tame the system without having to manually tell him every single thing to do? You want to keep the comfort. Exactly. If I have to proofread and approve every line of code that it wants to execute, I lose the entire speed advantage. Then I actually no longer need an autonomous agent at all. The technical answer to exactly this dilemma is local Docker sandboxes. A sandbox, i.e. a sandbox. Yes, a sandbox is, just as the German word sandkasten suggests, a strictly limited playground. When the agent starts, Docker uses tiny, extremely lightweight virtual machines in the background. So the system simulates a completely separate computer within the computer. Exactly. These virtual machines create a hard, insurmountable boundary at the hardware level of your computer. So the agent is assigned a room that is completely decoupled from my actual computer. Basically walls made of steel that he can't see through. He is completely isolated. The operating system the agent wakes up in shares absolutely nothing with your main system. The agent really has no idea your computer even exists. How does he even get his job then? From the outside, the gateway only passes exactly one folder through a tiny slot into this sandbox that the agent is supposed to process. So he doesn't see all my private documents? No. The agent doesn't see your company's network shares, it doesn't see any hidden system files, it has absolutely no administrator rights over your life, it's the absolute king in its little box and has maximum freedom of action to try, fail and run code on the command line. But the box itself is absolutely tight. This is brilliant. And what happens when it's finished? That's the most elegant aspect of it. As soon as the agent reports that the task is completed, this entire virtual machine is completely destroyed without leaving any residue within milliseconds. Everything is thrown away? Everything. There is no cash, no temporary file, nothing left. For the next task, the agent gets a brand new, pristine sandbox. In this way, you give it maximum autonomy without endangering your actual system for even a single second. This really calms my paranoia a lot. Let's summarize the broad lines of our consideration today. We have seen that autonomous agents like Hermes have moved beyond constantly waiting for human input. They really act like independent employees. That's what they do. They integrate unnoticed into our everyday communication channels through gateways. Whether that is Signal, Slack or, indirectly, WhatsApp. They don't block us from working thanks to asynchronous systems and queues. They delegate complex problems to highly constrained sub-agents while working completely securely in the encapsulated sandboxes of these virtual machines. So what does this all mean for us in the end? A whole lot. We are at a turning point where the invisible infrastructure around artificial intelligence, i.e. the communication channels and security barriers, has become just as important as the intelligence of the models themselves. Let us think one step further into the future. Today we analyzed the architecture of the Hermes agent in depth. A prominent feature of this particular system is its cyclical, recursive learning process. Recursive learning process? What does that mean for us? When Hermes has solved a highly complex task in the sandbox, he stops briefly. He then goes into a reflection phase, he analyzes his own logic steps, extracts the knowledge he has gained and, completely autonomously, programs himself a new, reusable tool in the form of program code. He saves this tool permanently. So he continually teaches himself new skills. Exactly. If these agents now act day after day through our everyday channels and program tools in the background that are becoming increasingly inscrutable and complex - tools whose intermediate steps we humans will soon no longer be able to cognitively understand, what will actually happen to our role? That is a frightening idea. In a few years, will we still be the rational clients of these systems that really control what is happening? Or will we inevitably degrade into purely passive recipients of finished results, without yet understanding the machine's path? That is the question we must ask ourselves. A really massive idea that will definitely keep us busy for a long time. That was our detailed analysis for this week. Thanks for listening and see you next time.

Dieser Podcast ist ein Projekt der KI-Gilde. Die Inhalte und Stimmen sind mit KI erzeugt und dienen der Information und Demonstration. Viel Spaß beim Hören! Willkommen zum KI-Gilde Podcast. Wir sind heute bei der 11. Folge unserer Freitagsserie Agenten verstehen angekommen. Wir schauen uns heute ganz genau an, wie wir mit unseren KI-Agenten eigentlich kommunizieren. Richtig. Wir haben ja mittlerweile verschiedene Agenten zur Verfügung, wie beispielsweise den Hermes-Agenten. Und der ganz große Unterschied zu einem klassischen Chat ist eben die Wahl der Kommunikationskanäle. Genau. Und wir besprechen heute, welche Kanäle da mittlerweile Standard sind und vor allem, wie so eine Anbindung an externe Netzwerke funktioniert, wie zum Beispiel an WhatsApp. Das ist ein riesiges Thema. Und eine ganz wichtige Frage dabei ist ja auch, ob man eine Aufgabe über einen Kanal senden kann, wenn der Agent gerade etwas anderes bearbeitet. Oder ist der Kanal dann blockiert? Das klären wir alles im Detail. Wir schauen uns auch an, wie autonom und parallel so ein Agent in einer isolierten Umgebung, also etwa in Docker oder auf einem dedizierten Rechner arbeiten kann. Aber bevor wir zu der Technik kommen, stell dir mal vor, du hast einen brillanten neuen Mitarbeiter eingestellt. Okay, ich stelle es mir vor. Du bittest ihn, eine tiefgehende Marktanalyse für dich durchzuführen. Er nickt, dreht sich um, fängt an zu arbeiten und nach exakt 20 Sekunden wird er von deinem internen Kommunikationsnetzwerk fristlos gefeuert. Einfach nur, weil er nicht schnell genug geantwortet hat. Das klingt natürlich völlig absurd. Aber das ist exakt die Situation, die passiert, wenn man versucht, moderne Agenten an alltägliche Chat-Plattformen anzubinden. Ja, weil dieser Mitarbeiter, den ich da beschrieben habe, der scheitert ja nicht an seiner Intelligenz. Einfach noch nicht verkraften. Wir müssen uns da wirklich völlig von dem Gedanken verabschieden, wie wir bisher mit großen Sprachmodellen interagiert haben. Okay, lass uns das mal aufdröseln. Ein klassisches Sprachmodell ist im Grunde ja wie ein extrem schlaues Lexikon. Ja, genau das ist es. Du schlägst etwas nach, es generiert dir einen Text und dann schläft es sozusagen sofort wieder ein. Es wartet einfach ab. Wenn du den nächsten Schritt willst, musst du halt zwingend die nächste Eingabe machen. Und wenn das Modell einen Fehler macht, bleibt es stehen. Richtig. Es zuckt virtuell mit den Schultern und wartet darauf, dass du ihm sagst, wie es diesen Fehler korrigieren soll. In der Systemarchitektur nennen wir das den zustandslosen Konversationsmodus. Also einen Modus, wo der Mensch die volle Kontrolle über die Prozesskette hat. Exakt. Du hast die Kontrolle, aber du musst eben auch jeden einzelnen Schritt mühsam diktieren. Bei einem echten autonomen Agenten, wie jetzt dem Hermes-Agenten, reden wir aber von etwas völlig anderem. Da geht es um zielgerichtetes Handeln. Das heißt, ich gebe ihm morgens ein übergeordnetes Makro-Ziel. Ich sage also nicht mehr, suche auf einer Suchmaschine nach dem ersten Wettbewerber und fasse mir den ersten Absatz zusammen. Nein, überhaupt nicht. Du formulierst das viel freier. Du sagst stattdessen, recherchiere die Preismodelle unserer drei größten Wettbewerber auf dem europäischen Markt. Vergleiche die versteckten Posten und erstelle mir eine fundierte Tabelle. Und das ist genau der Punkt, an dem diese Lexikon-Analogie komplett in sich zusammenbricht. Meine Mitarbeiter im Büro sage ich schließlich auch nicht, wie er seinen Webbrowser öffnen soll oder welchen Suchbegriff er eintippen muss. Ja, das wäre ja auch absurd. Du erwartest, dass er den Weg zum Ziel selbst findet. Und technisch setzt der Agent das durch ein Konzept um, das Schlussfolgern in einer Schleife genannt wird. Schlussfolgern in einer Schleife. Okay. Wie genau funktioniert das in der Praxis? Also, der Agent nimmt ein gewaltiges Makro-Ziel und zerlegt es völlig selbstständig in winzige, überschaubare Teilaufgaben. Er beginnt dann, diese Aufgaben Schritt für Schritt abzuarbeiten. Er ruft eine Webseite ab, liest den Text, vergleicht ihn mit seinem Ziel. Und was passiert, wenn da jetzt ein Fehler auftritt? Das ist das Entscheidende. Wenn eine Webseite nicht erreichbar ist oder die Information hinter einer Bezahlschranke liegt, dann bricht er eben nicht einfach ab. Er kehrt nicht weinend zu dir zurück. Er fragt mich also nicht sofort, was er jetzt tun soll. Nein. Er analysiert den Fehlschlag selbst, er korrigiert seine eigene Strategie in Echtzeit und probiert einen alternativen Weg. Er wendet sich wirklich nur dann an dich, wenn eine absolut essentielle Information fehlt. Oder eben, wenn eine Sicherheitsrichtlinie deine explizite Freigabe verlangt. Verstehe. Weil dieser Agent also wie ein eigenständiger digitaler Mitarbeiter agiert, ist es ja eigentlich völlig widersinnig, ihn in ein isoliertes Browserfenster einzusperren. Ganz genau. Wenn er selbstständig arbeitet, wollen wir ihn doch genau dort erreichen, wo wir ohnehin den halben Tag verbringen. Eben. Wir sprechen hier von Kanälen wie Telegram, Discord, Slack, Signal, Matrix, der guten alten E-Mail und natürlich WhatsApp. Wir wollen ihm ja im Grunde morgens beim Kaffeekochen einfach eine schnelle Sprachnachricht schicken können. Das ist der Traum, ja. Aber die technische Hürde, ihn genau dorthin zu bekommen, ist wirklich immens. Stell dir vor, du bist der Entwickler von so einem System. Okay. Wenn du für jede dieser Plattformen einen völlig eigenen Programmcode schreiben müsstest, der die ganzen Eigenheiten von Discord, die Datenstrukturen von E-Mails und die Verschlüsselung von Signal berücksichtigt, du hättest einen unwartbaren Albtraum erschaffen. Weil sich das ja auch ständig ändert, oder? Exakt. Jedes Mal, wenn Telegram ein Update ausrollt, würde dein Agent komplett zusammenbrechen. Deshalb greifen moderne Systeme auf eine sogenannte Gateway-Architektur zurück. Ein Gateway. Das fungiert in diesem Fall dann wie eine gigantische universelle Telefonzentrale, oder? Es steht genau in der Mitte zwischen mir als Nutzer und dem Gehirn des Agenten. Eine Telefonzentrale mit eingebautem Simultanübersetzer, würde ich sagen. Das Gateway nimmt sämtliche Nachrichten von außen an, völlig unabhängig von ihrer Herkunft oder ihrem Format. Es streift all den plattformspezifischen Ballast ab. Also, wenn ich über Telegram eine Sprachnachricht schicke, greift das Gateway diese Audiodatei auf. Richtig. Es leitet sie im Hintergrund an spezialisierte Modelle zur Spracherkennung weiter, transkribiert das Gesprochene in reinen Text und formatiert diesen Text in ein genormtes Systemprotokoll. Und nur diese saubere Aufgabe geht dann an den Agenten. Genau. Der Agent selbst hat am Ende keine Ahnung, ob du gerade gesprochen oder getippt hast oder über welche App du gekommen bist. Was hier faszinierend ist, ist nämlich der eigentliche Mehrwert, der durch das Gedächtnis dieser Zentrale entsteht. Du meinst, weil das Gateway in der Mitte sitzt, kann es den Status meiner Unterhaltung plattformübergreifend festhalten? Exakt das. Das Gateway verwaltet die Identität des Nutzers über alle Kanäle hinweg. Das heißt, ich kann morgens auf dem Weg zur Arbeit über Slack eine komplexe Datenanalyse anstoßen und am Nachmittag, wenn ich im Zug sitze, schreibe ich dem Agenten einfach über Signal und frage, wie weiter mit der Analyse von heute Morgen ist. Ja, genau diese Kontinuität ist der absolute Schlüssel. Es führt die Fäden aus Slack, Signal und Telegram in einer einzigen Datenbank zusammen. Dem Agenten wird das als einheitlicher Kontext präsentiert. Für den Agenten bist du immer dieselbe Entität, egal durch welche Tür du das Gebäude betrittst. Das klingt wahnsinnig elegant gelöst. Aber so gut das Gateway das Übersetzungsproblem auch löst, es löst ja nicht das Problem des Hausherrn, sage ich mal. Du spielst auf die geschlossenen Systeme an. Richtig. Wenn wir versuchen, diese Architektur in das System von Meta, also konkret in WhatsApp, zu integrieren, rennen wir doch plötzlich gegen eine massive Betonwand. Meta ist ja bekannt dafür, ein extrem geschlossenes Ökosystem zu pflegen. Völlig anders als die offenen Schnittstellen von Discord zum Beispiel. Oh ja. WhatsApp ist wirklich der ultimative Stresstest für jeden Agentenentwickler. Wir bewegen uns da quasi in zwei völlig separaten Welten. Welche sind das? Die erste Welt ist die offizielle Architektur über die Cloud von Meta. Das ist der vorgeschriebene Weg, den Konzerne gehen müssen. Diese Architektur basiert auf ereignisgesteuerten Signalen, sogenannte Webhooks. Webhooks. Also wie ein digitaler Türsteher, der Bescheid gibt, wenn was passiert? So ähnlich, ja. Das System des Agenten ist eigentlich im Ruhezustand. Wenn du als Nutzer eine Nachricht schreibst, feuert Meta ein Wecksignal an deinen Server. Klingt ja erstmal effizient. Ist es auch, aber jetzt kommt das massive Problem. Meta diktiert ein gnadenloses Zeitfenster. Dein Server hat maximal 20 Sekunden Zeit, um auf dieses Wecksignal mit einer fertigen Antwort zu reagieren. 20 Sekunden? Das mag für einen simplen Chatbot reichen, der irgendwie eine Begrüßungsfloskel ausspuckt. Aber wir reden hier doch von einem autonomen Agenten? Genau. Ein Agent, der das Internet durchsucht, der Schlussfolgerungen zieht und Fehler korrigiert. Der braucht Minuten, vielleicht sogar eine halbe Stunde für eine komplexe Marktanalyse. Was passiert denn dann, wenn diese 20 Sekunden einfach abgelaufen sind und der Agent noch rechnet? Dann registriert Meta einen Ausfall. Das System geht knallhart davon aus, dass dein Server abgestürzt ist. Es bricht die Verbindung sofort ab und stuft deine Plattform als fehlerhaft ein. Krass. Das heißt, der Agent arbeitet im Hintergrund weiter, aber die Antwort kommt nie bei mir an. Noch schlimmer. Meta sendet die Nachricht unter Umständen immer und immer wieder, weil es denkt, sie ist nicht angekommen. Das führt dann oft dazu, dass dein Server unter der Last der ständigen Neustarts komplett kollabiert. Für autonome Agenten ist dieser offizielle Weg also faktisch unbrauchbar. Und wie löst man das dann? Man kann ja WhatsApp nicht einfach ignorieren. Aus genau diesem Grund weichen Entwickler von Systemen wie eben dem Hermes-Agenten oft auf inoffizielle Brücken aus. Warte mal, eine inoffizielle Brücke? Das klingt für mich jetzt aber nach einem gigantischen Haftungsrisiko. Das ist es auch, wenn man nicht aufpasst. Ich binde doch nicht das teure System meines Unternehmens an eine inoffizielle Bastellösung an, die wahrscheinlich gegen sämtliche Nutzungsbedingungen verstößt. Aber verstößt so eine inoffizielle Brücke nicht gegen die Regeln? Was ist mit dem Risiko, gesperrt zu werden? Da ist doch meine Nummer schneller gesperrt, als der Agent Hallo sagen kann. Deine Skepsis ist absolut berechtigt. Ich erkläre dir kurz, wie das technisch funktioniert. Solche Brücken emulieren eine völlig normale, menschliche Sitzung über die Web-Oberfläche von WhatsApp. Also das System tut so, als wäre es ein Mensch am Browser. Exakt. Du scannst einen QR-Code in deiner Kommandozeile, genau wie du es im Browser an deinem Laptop tun würdest. Es erfordert kein kompliziertes Unternehmenskonto, keine Kreditkarten, keinen bürokratischen Prozess. Aber das Risiko einer permanenten Sperrung durch Meta bleibt doch astronomisch hoch, oder nicht? Ja, das ist es, wenn du die Architektur nicht mit extremer Vorsicht designst. Also wie schützen die Entwickler das System dann konkret davor, aufzufliegen? Durch zwei ganz fundamentale Sicherheitsvorkehrungen. Erstens strikte Netzwerksisolation. Niemand mit Verstand nutzt für solche Agentenbrücken seine private Hauptnummer oder die offizielle Firmennummer. Man holt sich also eine Wegwerfnummer? Genau. Man mietet sich isolierte, dedizierte Nummern, die oft über Voice-over-IP-Dienste generiert werden. Das ist der erste Schutzfall. Und der zweite? Zweitens, und das ist eigentlich noch viel kritischer, ist das Verhaltensmuster des Agenten. Der Agent muss softwareseitig so extrem eingeschränkt werden, dass er sich ausschließlich konversationell verhält. Konversationell heißt, er antwortet nur, wenn er gefragt wird. Richtig. Er darf unter gar keinen Umständen proaktive Nachrichten an Personen schicken, die nicht vorher mit ihm interagiert haben. Keine Massennachrichten, keine ungefragten Status-Updates. Weil Meta das sonst sofort als Spam erkennt. Ganz genau. Sobald ein Agent von sich aus unaufgefordert Gespräche initiiert, erkennen die Algorithmen von Meta dieses maschinelle Muster sofort. Der Spam-Filter schlägt dann erbarmungslos zu und die Nummer wird sofort und unumkehrbar gesperrt. Okay, das leuchtet ein. Aber wenn wir diese Hürde jetzt genommen haben und der Agent tatsächlich sicher auf dem Kanal läuft, dann landen wir direkt bei der drängendsten Frage unserer heutigen Betrachtung. Der Blockierung. Richtig. Stell dir vor, ich schreibe dem Agenten über diese WhatsApp-Verbindung eine riesige Aufgabe. Ich sage, bitte lade die Jahresberichte dieser 50 Unternehmen herunter, lies sie komplett durch und extrahiere alle Aussagen zur Nachhaltigkeit. Das dauert ja Stunden. Definitiv, ja. Was passiert in dieser Zeit mit meinem Chat? Ist das Fenster für mich dann einfach blockiert? Kann ich dem Agenten in der Zwischenzeit eine zweite, eilige Aufgabe dazwischen schieben oder hängt das System in einer ewigen Ladeschleife fest? Das ist eine super wichtige Frage. Bei einem primitiven, linear programmierten System wäre der Kanal jetzt komplett tot. Du müsstest wirklich warten, bis der Bericht fertig ist. Das wäre ja eine Katastrophe für den Arbeitsfluss. Absolut. Aber intelligente Architekturen umgehen dieses Nadelöhr durch asynchrone Aufgabenverarbeitung und sogenannte Nachrichten-Warteschlangen. Das Geheimnis liegt einfach darin, dass das System die Annahme deines Befehls rigoros von der eigentlichen Ausführung der Arbeit entkoppelt. Ah, hier wird es wirklich interessant. Das ist ja ein bisschen wie in einem exzellenten Restaurant. Wie meinst du das? Naja, der Kellner, das ist in diesem Fall unser Gateway, der kommt an deinen Tisch und nimmt die Bestellung für ein extrem aufwendiges Sieben-Gänge-Menü auf. Er geht aber danach nicht selbst in die Pöche, stellt sich an den Herd und breit das Fleisch. Stimmt. In deinem Sichtfeld. Der Kommunikationskanal, also der Tisch, ist niemals blockiert. Das ist eine perfekte Veranschaulichung. Technisch passiert da exakt Folgendes. Der Hauptprozess des Gateways speichert deine Aufgabe blitzschnell in einer Datenbank ab und schickt dir sofort eine winzige, asynchrone Empfangsbestätigung auf ein Telefon. So etwas wie, habe die Aufgabe verstanden, die Verarbeitung wurde gestartet. Ganz genau. Und in exakt diesem Moment wird die Kommunikationsverbindung zwischen deinem Telefon und dem Server sauber geschlossen. Meta ist glücklich, die 20 Sekunden sind bei weitem nicht überschritten und dein Chat ist sofort wieder frei. Und die eigentliche Arbeit? Tief im Hintergrund schnappt sich nun ein völlig isolierter Arbeitsprozess diesen Zettel aus der Küche, also aus der Datenbank, und fängt an zu arbeiten. Das ist brillant. Aber wie halte ich ihn denn auf, wenn er quasi das falsche Gericht kocht? Wie meinst du das konkret? Angenommen, ich merke fünf Minuten später, dass ich in meinem Text Nachhaltigkeit geschrieben habe, aber eigentlich Profitabilität meinte. Der Agent ist jetzt im Hintergrund dabei, 50 falsche Dokumente zu analysieren. Wenn ich ihm jetzt zum Chat schreibe, Stopp, such nach Profitabilität, wie steuert das System diesen Konflikt dann in Echtzeit? Das führt uns zur absolut Königsdisziplin der Systemarchitektur. Das System bietet hierfür in der Regel zwei verschiedene Modi an. Den Warteschlangenmodus und die aktive Unterbrechung. Okay, fangen wir mit der Warteschlange an. Der schonende Warteschlangenmodus ist technisch recht trivial. Der Agent arbeitet in aller Ruhe an der Nachhaltigkeit weiter. Deine neue Nachricht mit dem Stopp-Befehl wird einfach als nächster Zettel in die Küche gereicht. Das heißt, er liest den Zettel erst, wenn er mit den 50 Dokumenten fertig ist. Exakt. Sobald er nach Stunden fertig ist, liest er deinen neuen Befehl, verwirft das alte Ergebnis und fängt komplett von vorne an. Das ist für das System extrem sicher, weil nichts abstürzt. Aber das kostet mich doch wahnsinnig viel Zeit und Rechenleistung. Genau das will ich ja verhindern. Wenn ich sehe, dass er sich in eine völlige Halluzination verrennt, will ich sofort die Notbremse ziehen können. Und genau dafür gibt es den Unterbrechungsmodus. Dieser Modus ist technisch allerdings ein echter Drahtseilakt. Wenn du Stopp schickst, muss das Gateway ein hartes Abbruchssignal an den laufenden Arbeitsprozess feuern. Klingt gefährlich. Das ist es auch. Die massive Gefahr dabei ist nämlich, wenn du den Prozess einfach abschießt, verliert der Agent sein gesamtes Kurzzeitgedächtnis. Er vergisst in der Sekunde, welche der 50 Webseiten er schon gelesen hat. Oh, das ist schlecht. Und wie verhindert man das? Um das zu verhindern, muss das System den sogenannten Ausführungsgrafen einfrieren. Ausführungsgraf? Was ist das genau? Das ist im Grunde die Landkarte seiner bisherigen Gedanken und Schritte. Das System stoppt die Berechnungen an einem exakt definierten sicheren Punkt. Es nimmt alle Variablen, die der Agent gerade im Arbeitsspeicher hält, friert sie ein und schreibt diesen millisekundengenauen Schnappschuss auf die Festplatte. Wahnsinn! Er macht also im laufenden Betrieb ein vollständiges Backup seines eigenen Gehirns. Ganz genau. Er konserviert seinen aktuellen Zustand. Dann liest das Kernsystem deine neue Anweisungen bezüglich der Profitabilität, injiziert diesen neuen Parameter direkt in den eingefrorenen Schnappschuss und startet den Agentenprozess neu. Und dann weiß er noch, was er vorher getan hat. Ja! Der Agent wacht auf, hat seine Erinnerung an die bereits gelesenen 20 Dokumente behalten, weiß aber ab dieser Sekunde, dass er seinen Fokus komplett auf Profitabilität ändern muss. Das ist genial. Das spart ja immense Mengen an Rechenressourcen und verhindert vor allem, dass wir teure Aufrufe an eine Programmierschnittstelle, also externe Serverabfragen, doppelt bezahlen müssen. Absolut. Das ist ein enormer wirtschaftlicher Faktor. Wenn wir den Agenten jetzt also gefahrlos stoppen und starten können und der Kanal ohnehin immer frei bleibt, stellt sich mir unweigerlich die Frage der Skalierung. Du meinst die Menge der Aufgaben? Genau. Wenn er im Hintergrund arbeitet, warum sollte er nur eine einzige Sache tun? Wie autonom und vor allem wie parallel kann so ein System wirklich arbeiten? Kann ich ihm 100 Befehle gleichzeitig geben? Ob das System 100 Dinge gleichzeitig tun kann, hängt maßgeblich davon ab, wo der physikalische Flaschenhals liegt. Wir müssen hier zwingend zwischen Aufgaben unterscheiden, die auf externe Antworten warten und solchen, die wirklich lokale Rechenleistung verschlingen. Kannst du da ein Beispiel geben? Klar. Wenn dein Agent 50 Webseiten abfragt, ist das System lokal kaum ausgelastet. Es schickt 50 Anfragen in die Welt hinaus über eine Programmierschnittstelle und wartet einfach darauf, dass fremde Server antworten. Das kann ein gut geschriebenes System für hunderte Prozesse nahezu zeitgleich abwickeln, weil das Warten an sich keine Leistung kostet. Okay. Und der andere Fall? Anders sieht es aus, wenn der Agent auf deiner Maschine gigantische Datenmengen mathematisch analysieren muss, also beispielsweise riesige Tabellen verrechnet. Dann muss die Architektur in der Lage sein, die Prozesse physisch auf die verschiedenen Kerne deines Prozessors aufzuteilen. Das ist dann also die harte Limitierung der Hardware. Aber wie sieht das architektonisch aus? Der Hermes-Agent nutzt ja für solche komplexen Fälle eine sogenannte Subagentenarchitektur. Er bewältigt komplexe Dinge also nicht als monolithischer Block, sondern delegiert die Arbeit an sich selbst. Richtig? Richtig. Das ist das Prinzip der Isolation durch Delegation. Wenn du nämlich versuchst, einem einzelnen großen Agenten zehn völlig verschiedene Probleme gleichzeitig in sein Arbeitsgedächtnis zu laden, wird er unglaublich schnell den Faden verlieren. Sein Kontextfenster quillt quasi über. Genau. Er vermischt dann Informationen und beginnt zu halluzinieren. Um das zu umgehen, erschafft der Hauptagent für jede einzelne Teilaufgabe völlig isolierte Unteragenten. Er klont sich also im Grunde selbst? Er klont sich, ja. Aber er erschafft stark verdummte Klone, die mit einer massiven Werkzeugeinschränkung versehen sind. Verdummte Klone? Wie muss ich mir das vorstellen? Angenommen, du hast ein gigantisches Dokumentenverzeichnis und der Agent soll drei spezifische Logikfehler im Programmcode finden. Der Hauptagent erzeugt dann drei Unteragenten. Jedem dieser Klone weist er einen eigenen winzigen Ordner auf der Festplatte zu. Jeder bekommt also seinen eigenen kleinen Zandkasten. Exlakt? Und jetzt kommt der Clou an der Sache. Jeder Unteragent bekommt nur exakt die Werkzeuge, die er zwingend für sein kleines Ziel braucht. Sie haben keinen Zugriff auf die große, lange Chat-Historie zwischen dir und dem Hauptagenten. Sie kennen die Meta-Ebene gar nicht. Sie haben also wirklich nur einen totalen Tunnelblick auf ihre spezifische Aufgabe. Richtig. Diese drei Unteragenten wühlen sich nun völlig parallel durch die Dateien in ihren jeweiligen Ordnern. Und der entscheidende Punkt ist ja dann wahrscheinlich, dass sie nach getaner Arbeit nicht ihren kompletten Datenmüll, all ihre Versuche, Fehlermeldungen und Entwürfe an den Hauptagenten zurückschicken. Sie übermitteln doch sicher nur eine stark komprimierte Zusammenfassung, oder? So etwas wie Fehler Nummer eins gefunden und behoben, hier ist die geänderte Zeile. Ganz genau so läuft das. Das schützt den Fokus und den Arbeitssprecher des Hauptagenten extrem. Problem. Aber wenn wir das mit dem Großen Ganzen verbinden, müssen wir da eine gewaltige Warnung aussprechen. Inwiefern? Parallelität klingt in der Theorie immer wunderbar, ist in der Praxis aber hochgefährlich. Wenn du Aufgaben hast, die völlig unabhängig voneinander sind, ist es ein Traum. Aber was passiert, wenn diese isolierten Unteragenten plötzlich voneinander abhängig sind? Ja, genau das ist der Punkt. Wenn Unteragent A das Ergebnis von Unteragent B braucht, um überhaupt weiterzumachen, dann hast du auf einmal einen Synchronisations-Albtraum. Weil der eine dann auf den anderen warten muss. Ja, die Agenten blockieren sich gegenseitig. Sie warten aufeinander. Und ein winziger Fehler in den Daten von Agent B lässt Agent A komplett abstürzen. Echte, effiziente Parallelität erfordert also ein herausragendes Systemdesign, das die Abhängigkeiten im Vorfeld messerscharf trennt. Das führt mich direkt zum Elefanten im Raum, den wir hier haben. Du hast ja gerade im Nebensatz ganz beiläufig erwähnt, dass diese Unteragenten völlig autonom auf meinem Rechner arbeiten. Sie schreiben Programmcode, sie verändern Dateien, sie suchen im Internet nach Lösungen. Ja, das tun sie. Das klingt für mich nach dem ultimativen Sicherheitsrisiko. Wir lassen eine künstliche Intelligenz, die auf Wahrscheinlichkeiten basiert und jederzeit halluzinieren kann, frei auf unserem Betriebssystem herum vorwerken. Das ist ein sehr berechtigter Einwand. In der Entwicklerszene nennt man das zynisch den YOLO-Modus. You only live once. Oh Gott. Und Entwickler, die Agenten ungeschützt direkt auf ihrem Hauptbetriebssystem ausführen, spielen sehenden Auges russisches Roulette. Was kann denn im schlimmsten Fall passieren? Naja, ein Agent, der den simplen Auftrag hat, Speicherplatz zu bereinigen, könnte aus einer logischen Fehlannahme heraus den Befehl für die Kommandozeile generieren, der dein gesamtes Dateisystem unwiederbringlich formatiert. Alles gelöscht einfach so. Einfach so. Und noch schlimmer, er könnte unabsichtlich eine tief verborgene Datei auslesen, in der deine sensibelsten, unverschlüsselten Passwörter liegen und diese Daten bei der nächsten Suchanfrage an einen externen Server übermitteln. Blindes Vertrauen ist hier also absolut fehl am Platz. Aber wenn ich ihm nicht vertrauen kann, wie bändigen wir das System dann, ohne ihm jeden einzelnen Handgriff manuell feigeben zu müssen? Du willst ja den Komfort behalten. Genau. Wenn ich jede Zeile Code, die er ausführen will, erst gegenlesen und abnicken muss, verliere ich ja den gesamten Geschwindigkeitsvorteil. Dann brauche ich eigentlich überhaupt keinen autonomen Agenten mehr. Die technische Antwort auf exakt dieses Dilemma sind lokale Docker-Sandboxen. Eine Sandbox, also ein Sandkasten. Ja, eine Sandbox ist, genau wie das deutsche Wort Sandkasten vermuten lässt, ein strikt begrenzter Spielplatz. Wenn der Agent gestartet wird, nutzt Docker im Hintergrund winzige, extrem leichtgewichtige virtuelle Maschinen. Also simuliert das System einen komplett eigenen Computer im Computer. Ganz genau. Diese virtuellen Maschinen ziehen eine harte, unüberwindbare Grenze auf der Hardware-Ebene deines Computers. Der Agent bekommt also einen Raum zugewiesen, der von meinem eigentlichen Computer komplett entkoppelt ist. Quasi Mauern aus Stahl, durch die er nicht hindurch sehen kann. Er ist vollkommen isoliert. Das Betriebssystem, in dem der Agent aufwacht, teilt absolut nichts mit deinem Hauptsystem. Der Agent hat wirklich keine Ahnung, dass dein Computer überhaupt existiert. Wie kriegt er dann überhaupt seine Aufgabe? Das Gateway reicht von außen nur exakt den einen Ordner durch einen winzigen Schlitz in diesen Sandkasten, den der Agent bearbeiten soll. Er sieht also nicht meine ganzen privaten Dokumente? Nein. Der Agent sieht keine Netzwerkfreigaben deiner Firma, er sieht keine versteckten Systemdateien, er hat absolut keine Administratorenrechte für dein Leben, er ist in seiner kleinen Box der absolute König und hat maximale Handlungsfreiheit, um zu probieren, zu scheitern und Code in der Kommandozeile auszuführen. Aber die Box selbst ist absolut dicht. Das ist genial. Und was passiert, wenn er fertig ist? Das ist der eleganteste Aspekt daran. Sobald der Agent meldet, dass die Aufgabe erledigt ist, wird diese gesamte virtuelle Maschine innerhalb von Millisekunden komplett und rückstandslos zerstört. Alles wird weggeworfen? Alles. Es bleibt kein Cash, keine temporäre Datei, gar nichts übrig. Bei der nächsten Aufgabe bekommt der Agent einen nagelneuen, blütenreinen Sandkasten. So ermöglichst du ihm maximale Autonomie, ohne dein eigentliches System auch nur für eine einzige Sekunde zu gefährden. Das beruhigt meine Paranoia gerade wirklich erheblich. Lass uns die großen Linien unserer heutigen Betrachtung einmal zusammenziehen. Wir haben gesehen, dass autonome Agenten wie Hermes das ständige Warten auf menschliche Eingaben hinter sich gelassen haben. Sie agieren wirklich wie selbstständige Mitarbeiter. Das tun sie ja. Sie integrieren sich unbemerkt durch Gateways in unsere alltäglichen Kommunikationskanäle. Ob das nun Signal, Slack oder über Umwege WhatsApp ist. Sie blockieren uns dank asynchroner Systeme und Warteschlangen nicht bei der Arbeit. Sie delegieren komplexe Probleme an stark eingeschränkte Unteragenten und arbeiten dabei absolut sicher in den gekapselten Sandkästen dieser virtuellen Maschinen. Also, was bedeutet das alles am Ende für uns? Eine ganze Menge. Wir stehen an einem Wendepunkt, an dem die unsichtbare Infrastruktur um die künstliche Intelligenz herum, also die Kommunikationswege und Sicherheitsbarrieren, genauso wichtig geworden ist wie die Intelligenz der Modelle selbst. Wir noch einen Schritt weiter in die Zukunft denken. Wir haben heute ja die Architektur des Hermes-Agenten tiefgehend analysiert. Ein herausragendes Merkmal dieses speziellen Systems ist sein zyklischer, rekursiver Lernprozess. Rekursiver Lernprozess? Was heißt das für uns? Wenn Hermes eine hochkomplexe Aufgabe im Sandkasten gelöst hat, stoppt er kurz. Er geht dann in eine Reflexionsphase, er analysiert seine eigenen Logikschritte, extrahiert das gewonnene Wissen und programmiert sich völlig autonom ein neues, wiederverwendbares Werkzeug in Form von Programmcode. Dieses Werkzeug speichert er dauerhaft ab. Er bringt sich also kontinuierlich selbst neue Fähigkeiten bei. Genau. Wenn diese Agenten nun Tag für Tag über unsere alltäglichen Kanäle agieren und im Hintergrund Werkzeuge programmieren, die immer undurchschaubarer und komplexer werden Werkzeuge, deren Zwischenschritte wir Menschen bald kognitiv gar nicht mehr nachvollziehen können, was passiert dann eigentlich mit unserer Rolle? Das ist eine erschreckende Vorstellung. Sind wir dann in ein paar Jahren überhaupt noch die rationalen Auftraggeber dieser Systeme, die das Geschehen wirklich kontrollieren? Oder degradieren wir unweigerlich zu den rein passiven Empfängern von fertigen Ergebnissen, ohne den Weg der Maschine noch zu verstehen? Das ist die Frage, die wir uns stellen müssen. Ein wirklich massiver Gedanke, der uns definitiv noch länger beschäftigen wird. Das war unsere ausführliche Analyse für diese Woche. Danke fürs Zuhören und bis zum nächsten Mal.