KI Picks der 41. KW

Mit dem Thema Decision Model in Form von Jev hat TypeSafe anscheinend echt ein Fass aufgemacht. Die Dinger sprießen nun förmlich aus dem Boden, und zweieinhalb Kandidaten haben es auch in die Picks geschafft (OpenAI zähle ich nur so halb dazu, weil die eigentlich mehr auf den Zug aufgesprungen sind und an der API geschraubt haben, weniger am Modell). Ansonsten wieder keine Hardware, dafür behauptet Ars Technica, MCP sei kaputt. Na dann, kann ja nur besser werden.

Auf in die KI Picks der 41. Kalenderwoche – santé!

Claude Haiku 5.5

Nach Opus und Sonnet hat Anthropic am 7. Oktober auch Claude Haiku 5.5 nachgezogen, das neue kleine Modell für genau die Arbeiten, für die Opus schlicht Verschwendung wäre: Klassifikation, Extraktion, Zusammenfassungen, Compaction oder eng umrissene Subagent-Jobs. Dazu gibt es 1 Mio. Tokens Kontext, bis zu 128.000 Output-Tokens und erstmals bei Haiku einen einstellbaren Effort, samt Adaptive Thinking anstelle eines festen Thinking-Budgets. Der spannendere Wert steht aber auf der Rechnung. Bis 100.000 Prompt-Tokens kostet Haiku 5.5 nur 0,10 $ Input und 0,50 $ Output pro Million Tokens, jeweils ein Zehntel von Haiku 4.5, und Anthropic spricht im Durchschnitt von rund 75 % geringeren Kosten.

Der Haken sitzt bei den 100.000 Tokens: liegt ein Request darüber, zahlt er komplett den höheren Satz von 0,50 $ beziehungsweise 2,50 $, also auch für den Output und für gecachte Tokens, die laut Preisdoku zur Schwelle mitzählen. Groß ist das 1-Million-Context-Window, richtig billig bleibt es aber nur, solange der einzelne Prompt klein bleibt. Auch die starken Launch-Werte würde ich nicht überbewerten, denn sie gelten für Max-Effort. Voreingestellt ist Medium, und dort misst Artificial Analysis 34 statt 43 Punkte im Intelligence Index (Haiku 4.5 kam auf 17, der Sprung bleibt ordentlich).

Haiku hat laut Anthropic eine ganz klar umrissene Rolle: Opus oder Sonnet koordinieren, Haiku erledigt den Kleinkram in Masse. Für Agenten-Pipelines ist das vermutlich relevanter als die Frage, ob das kleine Claude irgendwo noch zwei Benchmark-Punkte mehr einsammelt.

Aleph Alpha Kolibri

Hier hatte ich lange überlegt, ob Kolibri nicht sogar einen eigenen Artikel wert ist. Der wäre es sicherlich auch gewesen, wenn ich denn nur die Muße gehabt hätte, das Ding selbst zu testen. Dazu hätte ich aber erstens einen Zugang zu einem Inference-Server gebraucht oder mir über Hugging Face eine Quantisierung besorgen müssen, die in 48 GB Shared Memory passt. Zweitens fehlt mir gerade ein richtig konkreter Anwendungsfall dafür. Vielleicht sollte ich mir einfach mal ein Standard-Testset stricken – so für verregnete Sonntagnachmittage. Weiteres Problem an der Nummer: Ganz ohne Bastelei wird das eh nichts. Eine 4-Bit-Fassung liegt bei rund 44 bis 47,5 GB und passt damit nicht, eine 3-Bit-MLX-Variante mit gut 35 GB schon, wenn man macOS mehr GPU-Speicher zugesteht. Stock-llama.cpp, Ollama und LM Studio kennen die Architektur aber noch nicht, ohne Patch oder Fork läuft da nichts.

Lange Rede, kurzer Sinn: Kolibri kommt von Aleph Alpha aus Heidelberg, einer deutschen Bude, die außerhalb der Branche eigentlich niemand kennt, obwohl sie 2023 mit einer halben Milliarde Dollar Finanzierung Schlagzeilen machte und gerade mit Cohere fusioniert (laut Pressemitteilung steht die behördliche Freigabe noch aus). Rund 200 Leute arbeiten dort an vier Standorten, von Heidelberg über Bayreuth und München bis Berlin. Die technischen Daten klingen erst mal gar nicht so spektakulär, eher nach solidem 2026-Standard: MoE, 78 Mrd. Parameter, davon rund 3,5 Mrd. aktiv, optimiert für mehrstufiges Reasoning, Tool-Calling und RAG. Die beworbene 1 Mio. Tokens Kontext erreicht Kolibri per Extrapolation. Nativ trainiert sind 256.000 Tokens, und genau diese Grenze empfiehlt Aleph Alpha selbst für den Betrieb.

Das Ding wurde gezielt zweisprachig trainiert. Gut ein Fünftel der Pre-Training-Tokens ist Deutsch, dazu kommt ein eigener deutsch-englischer Tokenizer. Die besondere Spezialität ist das Reasoning auf Deutsch, in der Model Card heißt es dazu:

We trained our model to reason in German to make it easier for our users to follow along.

Als Beispielanwendung nennt der Hersteller u. a. Bürgeranfragen und amtlichen Schriftverkehr „auf Verwaltungsdeutsch mit derselben Qualität, die man auf Englisch erwartet“. Bestes Bürokratiedeutsch also, jetzt auch maschinell erzeugbar.

Die Model Card erwähnt auch noch Coding-Fähigkeiten, der Launch-Post nur ganz nebenbei, die Produktseite gar nicht.

Wer das in vollem Umfang ausprobieren möchte, sollte ein bisschen Dampf unterm Blech im Serverraum haben: 2× A100 80 GB, 2× H100 SXM5, 1× H200, 1× B200 oder 1× B300, und wir reden hier von den Minimalanforderungen für die FP8-Gewichte (eine kleinere offizielle Variante gibt es nicht). Dafür gibt es die Open Weights über Hugging Face unter Apache-2.0-Lizenz. Alternativ muss man bei Aleph Alpha direkt vorsprechen, denn bei anderen Providern wie OpenRouter oder den Hugging Face Inference Providern ist Kolibri derzeit nicht zu bekommen. Externe Benchmarks habe ich ebenfalls keine gefunden, auch Artificial Analysis führt das Modell noch nicht. Sämtliche Zahlen in der Model Card stammen aus Aleph Alphas eigenem Eval-Framework.

Mistral Large 4 „Le Chonk“

Mistral hat am 6. Oktober Mistral Large 4 vorgestellt, intern ML4, offiziell und mit Augenzwinkern „le Chonk“. Dazu gab es ein humoriges Teaser-Video: Eine pummelige orange Katze tapst durch einen Museumssaal mit Louvre-Gemälden, schubst eine riesige Pixel-„4“ um und legt sich drauf. Das Modell läuft seit dem Launch als Public Preview über die API, die Gewichte sollen Ende Oktober folgen. Unter welcher Lizenz, verrät Mistral noch nicht.

Was bekommen wir denn da:

• 1 Billion Parameter, nativ multimodal (Text und Bild rein, Text raus), davon 52 Mrd. aktiv (im X-Post stehen 49 Mrd., Blog und Doku sagen 52)
• kombiniertes Instruct und Reasoning in einem Modell
• Support für mehr als 160 Sprachen, alle EU-Amtssprachen inklusive
• 1 Mio. Tokens Kontext laut Doku

Trainiert wurde es laut Mistral von Grund auf, und zwar auf 3.800 Grace-Blackwell-GPUs in den eigenen europäischen Rechenzentren. Der Listenpreis der API liegt bei 1,36 $ pro Million Input- und 4,18 $ pro Million Output-Tokens, zum Start halbiert Mistral das aber auf 0,68 $ beziehungsweise 2,09 $.

Mistral positioniert ML4 vor allem für Coding, Agenten (oh Wunder), Cybersecurity und komplexe Wissensarbeit. Die veröffentlichten Ergebnisse sehen, vorsichtig formuliert, recht optimistisch aus, wobei der Blogtext euphorischer klingt als die Diagramme daneben. In Mistrals eigenen Grafiken liegt Kimi K3 bei DeepSWE vorn (68 zu 62 Punkten) und GLM-5.3 bei Terminal-Bench 4 (40 zu 28). Klar vorn ist ML4 im Cyber-Index von Artificial Analysis, auch weil Opus 5.5 und GPT-6 Astra dort viele Aufgaben aus Sicherheitsgründen verweigern. Einige Evals stammen von Mistral selbst, andere hat Artificial Analysis vor der Veröffentlichung des jeweiligen Harness privat gemessen. Im öffentlichen Intelligence Index von Artificial Analysis landet die Preview bei 38 Punkten, Rang 64 von 226 – zum Vergleich, Haiku 5.5 schafft auf Max 43. Und auch Mistral selbst bezeichnet das Modell ausdrücklich als Preview, das RL-Training läuft laut Blog noch.

Cloudflare Clef: Decision Models werden plötzlich hip

Decision Model Nummer eins dieser Picks: Kaum ist Jev gut zwei Wochen alt, legt Cloudflare am 1. Oktober mit Clef und Clef-flash nach. Das Prinzip bleibt ähnlich. Die Modelle liefern typisierte Entscheidungen samt Wahrscheinlichkeiten, die sich direkt in Workflows und Agent-Loops verwenden lassen, und sparen sich den Umweg über generierten Text. Technisch geht Cloudflare aber ein Stück weiter als TypeSafe. Clef verarbeitet auch Bilder, bietet 64.000 Tokens Kontext (Jev kommt auf 32.000) und ist mit der Jev-API kompatibel. Unter der Haube stecken Qwen-Modelle, Qwen3.8-27B für Clef und Qwen3.5-9B für Clef-flash, ergänzt um eigene Routing-Heads und LoRA-Adapter. Die Entscheidung selbst läuft ohne Token-für-Token-Generierung, nach einem einzigen Prefill-Durchgang bewertet das Modell alle zulässigen Schema-Optionen parallel.

Beide Modelle stehen unter Apache 2.0 auf Hugging Face und laufen zugleich über Workers AI, dort für 0,24 $ beziehungsweise 0,09 $ pro Million Input-Tokens. Drumherum baut Cloudflare noch einen RL-Fine-Tuning-Service, mit dem Unternehmen Clef auf eigene Entscheidungsprobleme zuschneiden sollen. Vorerst läuft das als betreuter Service mit Cloudflares Forward-Deployed Engineers, Self-Service soll später kommen. Am Rande noch ein kleines Detail. Cloudflare nennt sein Trainingsverfahren „Reinforcement Learning for Calibrated Decisions (RLCD)“. Exakt so heißt auch TypeSafes Methode aus dem Jev-Launch, ein Hinweis darauf fehlt im Blogpost.

Bei den eigenen Evals liegt Clef häufig vor Jev, in TypeSafes Workflow-Evals etwa in drei von vier Bereichen, wenn auch knapp. Bei Wissens- und Reasoning-Tests wie GPQA Diamond oder MMLU-Pro liegt laut Model Card dagegen Jev deutlich vorn. Dazu meldet Cloudflare erheblich niedrigere Latenzen, im Median 209 ms für Clef und 39 ms für Clef-flash gegenüber 524 ms für Jev. Das sind allerdings Cloudflares eigene Messungen, und wo und wie gemessen wurde, legt Cloudflare nicht offen. Dass die Modelle auf Cloudflares eigenem Edge-Netz laufen, führt der Blog selbst als zusätzlichen Latenzvorteil an. Ein bisschen Heimvorteil gehört vermutlich zum Kleingedruckten.

Decision 2.0 vom vLLM Semantic Router

Decision Models (Nummer 2 in dieser Woche) sind ja anscheinend gerade hip. Da dachte man sich beim vLLM: Mensch, wir haben doch schon eines, aktualisieren wir das mal und hängen eine 2.0 hinten dran. „Schon eines“ heißt in dem Fall „seit knapp zwei Wochen“. Decision 1.0 erschien am 22. September, eine Woche nach Jev, und nutzt ausdrücklich TypeSafes System-One-Request-Format. Am 3. Oktober folgte dann Decision 2.0, ebenfalls auf Hugging Face mit Apache-2.0-Lizenz und gleich in sechs Varianten von 0,6B bis 27B. Mit anderen Worten: Das Ding läuft quasi auch auf einem besseren Taschenrechner, die kleinste Variante Kai-0.6B lässt sich laut Doku sogar auf der CPU betreiben. Für das große Vega-27B braucht es dagegen eine ordentliche GPU.

Als Input hätte Decision 2.0 gern Text oder JSON, dazu die Fragen, die das Modell beantworten soll. Zurück kommt je nach Fragetyp eine Auswahl aus mehreren Optionen, ein Ja/Nein oder ein Skalenwert, jeweils mit Wahrscheinlichkeiten für alle möglichen Antworten. Laut vLLM auf X beantwortet das Modell bis zu 64 Fragen in einem einzigen Forward-Pass. Die Benchmarks sind Eigenmessungen und vergleichen nur mit offenen Modellen gleicher Größe, gegen Jev oder Clef tritt Decision 2.0 dort nicht an.

OpenAI Decisions API

Decision Model zum Dritten: OpenAI hat die Decisions API am 6. Oktober in die Public Beta geschickt, nachdem sie auf dem DevDay noch als Limited Preview angekündigt war. Der eigene Endpoint frisst Text oder Bilder und beantwortet eine oder mehrere klar definierte Fragen als predicate, choice oder score, also beispielsweise „Ist das Bild beschädigt?“, „Welche Abteilung ist zuständig?“ oder „Wie kritisch ist dieses Problem?“. Zurück kommen Wahrscheinlichkeiten, Confidence-Werte und die definierte Auswahl. Einen Absatz, aus dem man anschließend wieder JSON herausoperieren muss, gibt es nicht. Aktuell läuft das Ganze ausschließlich mit GPT-6 Luna, die allgemeine Verfügbarkeit soll „in the coming weeks“ folgen.

Kommen wir zum Preis. OpenAI verlangt 0,10 $ pro Million Input-Tokens, Output-Tokens werden nicht berechnet (Aufschläge für regionale Verarbeitung und lange Kontexte kommen noch dazu). Geworben wird außerdem mit rund zehnfach höherer Geschwindigkeit gegenüber der Responses API, das sagt allerdings OpenAI selbst. Was die API liefert, sind Wahrscheinlichkeiten. Wo daraus eine Entscheidung wird, muss man selbst festlegen, und die Doku empfiehlt dafür ausdrücklich eigene gelabelte Beispiele:

Use labeled examples from your application to set thresholds for routing, filtering, or review. Choose thresholds based on the cost of false positives and false negatives.

Und, das sage ich jetzt mal: Wenn if x > 10 reicht, braucht es dafür weiterhin kein Modell. Das sah n8n beim Jev-Node für n8n übrigens genauso.

Anthropic legt Max und Team monatliche API-Credits dazu

Anthropic packt seit dieser Woche monatliche API-Credits in die Max- und Team-Abos. Max 5x bekommt 100 $, Max 20x 200 $ pro Abrechnungszeitraum. Bei Team sind es 20 $ je Standard- und 100 $ je Premium-Seat, gemeinsam in einem Pool und bei 500 $ gedeckelt. Die Credits funktionieren mit allen Modellen auf der Claude Platform, außerdem mit Messages API, Message Batches, Agent SDK, Managed Agents und im Playground der Console. Laut @ClaudeDevs gehen sie auch „in third-party harnesses“, sofern die mit einem API-Key aus der verknüpften Console-Organisation laufen. Über Bedrock, Google Cloud oder Foundry gelten sie nicht. Für Max-Nutzer ist das schon eine ziemlich nette Dreingabe, zumindest auf dem Papier entspricht das API-Guthaben jeweils dem monatlichen Abo-Preis.

Aber: Die Credits verlängern nicht die Limits in Claude oder Claude Code und lassen sich auch nicht für interaktive Claude-Code-Sessions verbraten. Wer gehofft hatte, damit nach Erreichen des Wochenlimits einfach weiterschrauben zu können, kann den Gedanken also wieder einpacken. Ganz zu ist die Tür aber nicht, denn claude -p und das Agent SDK sind mit einem API-Key aus der verknüpften Organisation abgedeckt. Nicht verbrauchtes Guthaben verfällt am Ende des Abrechnungszeitraums, und Pflicht ist, eine Console-Organisation fest mit dem Abo zu verknüpfen (wechseln geht nur über den Support). Eine Kreditkarte braucht es nicht. Sind die Credits aufgebraucht und ist kein gekauftes Guthaben da, stoppen die API-Requests einfach bis zum nächsten Monat. Für eigene Agenten, kleine API-Projekte oder Experimente mit Haiku 5.5 ist das gut brauchbar. Erheblich sinnvoller als der nächste „100 Dollar Startguthaben, aber nur wenn Vollmond ist“-Promo-Code ist es allemal.

Claude vor ChatGPT beim Abo-Gegenwert – mit ziemlich großem Sternchen

Womit wir beim Abo-Gegenwert wären. Claude bietet derzeit deutlich mehr API-Gegenwert als ChatGPT, zumindest wenn man genau den von SemiAnalysis vermessenen Workload betrachtet. Beim 200-Dollar-Abo kommen die Autoren für Opus 5.5 auf rund 11.700 $ API-Gegenwert, GPT-6.1 Sol landet bei gut 2.000 $. Gemessen wurde mit einem agentischen Workload, der fast komplett aus gecachtem Input besteht. Dazu hat OpenAI am 29. September die Limits seines 200-Dollar-Tarifs für Neukunden quasi halbiert (Bestandsabos behalten die alten bis zum 29. Oktober), und der neue 500-Dollar-Plan liefert bei Astra für zweieinhalbmal so viel Geld nur 21 % mehr Tokens als der alte 200-Dollar-Tarif. Anthropic subventioniert seine Abos damit derzeit großzügiger, jedenfalls in der Mittelklasse. Bei den Topmodellen liegen Claude Fable 5.1 (2.485 $) und GPT-6 Astra (2.897 $) fast gleichauf.

Der Haken, den All-AI.de im Einstieg ziemlich elegant wegkürzt: SemiAnalysis selbst warnt davor, einem Abo einen Dollar-Gegenwert zuzuschreiben, ohne Plan, Modell und Workload dazuzusagen. Derselbe Max-20x-Plan ist je nach Modell und Workload zwischen rund 2.500 und 12.500 $ „wert“. Noch interessanter ist, dass die Anbieter diese Limits offenbar jederzeit still verändern können.

They can also silently change limits whenever they want by tweaking credit costs.

SemiAnalysis erwischte bei seinen Messungen sogar einen von drei identischen Accounts in einem A/B-Test mit rund 20 % niedrigeren Limits. Welcher Anbieter das war, verrät der Text nicht. Daraus lässt sich ableiten, dass KI-Abos mittlerweile ziemlich undurchsichtige Kreditsysteme sind, deren Preis auf der Rechnung deutlich stabiler ist als die Leistung dahinter.

Claude Projects: Der Projektordner bekommt einen Koordinator

Die neuen Claude-Projekte mit Koordinator und Threads haben mit dem alten „Projektordner mit Wissen und Anweisungen“ nur noch am Rande etwas zu tun. Im Zentrum sitzt jetzt ein Koordinator, dem man (optional) ein Ziel gibt. Der zerlegt die Arbeit in einzelne Threads, schickt sie parallel in Claude-Code-Cloud-Sessions und sammelt die Ergebnisse wieder ein. In meinem Beitrag gehe ich daher mal auf das ein, was man vor dem ersten Run tatsächlich klären sollte: wo die Arbeit läuft (Cloud-Threads sehen keine lokalen MCP-Server, lokal geht es nur per Remote Control), Ziel und Projektanweisungen, CLAUDE.md und Memory, Repositories, Connectors und Modell. Wer einfach nur zehn Agenten gleichzeitig losschickt, hat schließlich noch keinen Workflow gebaut.

Der neue Field Guide zu Cloud-Sessions von Addy Osmani auf claude.dev ergänzt dazu ein paar Details, die unter der Oberfläche wichtig werden. Jeder Cloud-Thread läuft in einer eigenen VM mit eigenem Branch, Repository-Clone und isolierter Umgebung, mehrere Jobs können damit tatsächlich parallel laufen, ohne sich um Dateien oder Ports zu prügeln. Repository-weite CLAUDE.md, Skills, Agents und Commands reisen mit in die Cloud. Die MCP-Server aus der .mcp.json des Repos lädt ein Projekt laut Doku nur, wenn genau ein Repository im Spiel ist, und die persönliche ~/.claude bleibt ohnehin zu Hause. Parallel heißt erwartbar auch parallel beim Verbrauch:

Parallel sessions draw on your plan limits in parallel, so five sessions use them about five times as fast as one.

Immerhin schreibt Anthropic das selbst dazu. Verkauft wird das Ganze trotzdem als bequemes Arbeiten im Hintergrund, ich würde es eher Agent-Orchestrierung mit eingebautem Verbrauchsbeschleuniger nennen. Der Einstiegskredit für Cloud-Sessions gilt für Projekte übrigens nicht.

Anthropic zieht damit Projektkontext, Delegation und isolierte Ausführung in einer Oberfläche zusammen. Das nimmt einiges von dem manuellen Gefummel weg, das man sich bisher mit mehreren Claude-Code-Sessions, Worktrees und eigener Orchestrierung gebaut hat. Wie gut der Koordinator Aufgaben wirklich schneidet und wieder zusammensetzt – schauen wir mal.

Ars Technica sagt: MCP ist kaputt

Ein unabhängiger Sicherheitsforscher, Syed Anas Mohiuddin, hat bei mehreren Organisationen Lücken in MCP-Servern gefunden, die inzwischen bestätigt und gefixt sind. Bei Google, JPMorgan Chase, Weaviate und der französischen Digitalbehörde DINUM waren es Server-Side-Request-Forgery-Lücken (SSRF), bei Rapid7 eine GraphQL-Injection mit niedriger Einstufung. Spannender ist das Angriffsmuster, das er darauf aufbaut und „Protocol Pivoting“ nennt. Ein Agent liest fremden Inhalt, reicht daraus abgeleitete Instruktionen weiter, und der nächste Agent behandelt sie als vertrauenswürdige interne Aufgabe. Besonders unschön wird das, wenn dabei MCP, Googles A2A oder andere Agentenprotokolle miteinander verkettet werden und Berechtigungen unterwegs faktisch verloren gehen.

Ars Technica sprach in der ursprünglichen Überschrift von einem „structural flaw in MCP“ (inzwischen entschärft), das war mir aber auch etwas zu weit ausgeholt. Die neue Überschrift beschreibt MCP als Protokoll für die Kommunikation zwischen Agenten. Gedacht ist es vor allem für die Verbindung von Agent und Tool, für Agent zu Agent gibt es A2A. Markus Vervier von X41 D-Sec ordnet das im selben Artikel weniger reißerisch ein:

For me this is indirect prompt injection.

Klassische Prompt Injection, nur eben über mehrere Agenten und Protokolle hinweg. Der eigentlich bekannte Fehler dahinter heißt „internes System = vertrauenswürdig“, und genau das sollte bei Agenten nicht gelten. Tool-Aufrufe brauchen weiterhin Least Privilege, Eingabevalidierung, Allow-Lists und saubere Autorisierung an jeder Grenze. Douglas McKee von Rapid7 sagt es bei Ars so:

The bugs underneath are old friends like injection and SSRF, and the fixes haven’t changed in 20 years.

Oder kürzer: Nur weil zwei KI-Agenten miteinander reden, wird aus fremdem Text noch lange kein vertrauenswürdiger Befehl.

Connecting AI agents to enterprise knowledge

Nur rund ein Drittel (34 %) der Agenten-Projekte schafft laut MIT Technology Review Insights im Schnitt den Sprung in die Produktion, befragt wurden 300 Führungskräfte aus Daten, KI und Technik. Den Engpass sieht der Report oft in der Datenbasis. Fragmentierte Daten (für 55 % die größte Hürde), Legacy-Systeme, Sicherheits- und Datenschutzbedenken sowie fehlendes Wissen und fehlender Kontext bremsen Agenten aus. Die Unternehmen, bei denen es besser läuft (dort schaffen im Schnitt 61 % der Projekte den Sprung), haben vor allem ihre Daten semantisch besser erschlossen, wobei der Report hier eine Korrelation beschreibt und keinen Kausalzusammenhang belegt.

Die interviewten Experten empfehlen dafür einen zusätzlichen „Knowledge Layer“, investieren wollen die Befragten vor allem in RAG, Datenpipelines und Knowledge Graphs. Das ist plausibel, aber nicht neu, und völlig interessenfrei ist es auch nicht. Der Beitrag ist als „Sponsored“ markiert und „in partnership with Neo4j“ entstanden, den vollständigen Report gibt es nur über ein Leadformular bei Neo4j, und Neo4j verkauft selbst ein Produkt namens Knowledge Layer. Die wichtigere Aussage dahinter teile ich trotzdem. Ob ein Agent in Produktion kommt, entscheidet sich häufig an der Unternehmensarchitektur unter dem LLM, und das deckt sich gut mit dem, was ich zu Daten, Scope und Ownership bei KI-Agenten geschrieben habe.

ElevenAgents Architect baut jetzt Agents am Agent

ElevenLabs hat am 6. Oktober mit ElevenAgents Architect einen Assistenten direkt in ElevenAgents eingebaut, der mehr kann, als nur zu erklären, wo welcher Schalter sitzt. Architect untersucht bestehende Agents, zieht dafür echte Conversations, fehlgeschlagene Tests oder Hinweise aus Spotlight heran (das Monitoring für Agent-Gespräche bei ElevenLabs) und ändert anschließend Prompt, Workflow, Tools, Knowledge Base oder Guardrails. Danach schreibt und startet er Tests und legt die Änderung als Draft beziehungsweise Merge Proposal vor. Drafts veröffentlichen darf Architect selbst nicht, das letzte Wort hat der Mensch. Das gilt allerdings nur im Default-Modus. Im Auto-approve-Modus kann Architect ohne Rückfrage Branches mergen und Traffic-Splits ändern, und ein Merge geht sofort live.

Im Kern ist das ein ziemlich tief integrierter Admin- und Debugging-Agent für die eigene ElevenLabs-Plattform, mit „KI baut jetzt selbstständig deine KI“ hat das erfrischend wenig zu tun. Der Assistent arbeitet mit denselben Objekten, Diffs, Branches und Versionsständen, die man auch manuell bearbeiten würde, eine zweite magische Konfiguration gibt es laut Doku nicht. Er handelt mit den Rechten und unter dem Namen des Nutzers, im Audit taucht deshalb nur der Mensch auf. Der kleine Haken (fast nichts ist ohne Haken): Architect ist noch Alpha (bis Ende Oktober kostenlos), wird schrittweise ausgerollt, und seine Chats fallen nicht unter den Zero Retention Mode. ElevenLabs schreibt dazu selbst:

Avoid sharing personal or sensitive information in messages to Architect.

Sensible Daten würde ich dort entsprechend also nicht gedankenlos reinkippen.

Gemini at Work 2026

Google hat am 8. Oktober im Rahmen von Gemini at Work 2026 den neuen Gemini agent vorgestellt (nicht zu verwechseln mit dem gleichnamigen Feature in der Gemini-App). Gemeint ist eine Schicht über dem gesamten Google-Stack, ein neues Modell steckt nicht dahinter. Der Agent soll Aufgaben über Gmail, Drive, Docs, Sheets, Calendar und angebundene Systeme hinweg erledigen, sich auch über Slack oder Microsoft 365 ansprechen lassen, per MCP auf weitere Tools zugreifen und länger laufende Jobs übernehmen. Kontext und Memory bleiben über Geräte und Sessions erhalten. Interessant ist, dass das Modell darunter ausdrücklich austauschbar ist.

Gemini is the agent, and the model underneath it is a separate choice.

Google routet je nach Aufgabe zwischen eigenen Gemini-Modellen (von Argon bis Flash) und bereits heute auch Claude, später sollen weitere proprietäre und offene Modelle dazukommen.

Die Infrastruktur drumherum: Teams können Coworker Agents mit eigener Mailadresse, Kalender, Storage und eigener Identität im Unternehmensverzeichnis anlegen. Berechtigungen laufen per Least Privilege, Aktionen landen im Audit Trail, die Ausführung erfolgt in einer Sandbox, und das Agent Gateway setzt zentral Policies durch. Dazu kommen Smart Routing zwischen Modellen und harte Spend Caps pro Projekt (Letztere hat Google schon im April angekündigt). Also eher the daily stuff. Was im Blogpost fehlt, sind Status, Preis und Termin für den Gemini agent selbst, laut Yahoo Tech steckt er noch in einer Private Preview.

Der Blog ist die verschriftlichte Keynote von Google-Cloud-CEO Thomas Kurian und entsprechend voll mit Kundenzahlen, Effizienzgewinnen und „AI transformation“. Die meisten davon sind Fallstudien aus dem eigenen Ökosystem. Auch die Branchenpakete Gemini for Financial Services und Legal sind zunächst Preview. Technisch ist die Richtung trotzdem interessant. Google will offenbar die komplette Betriebsumgebung für Agenten verkaufen, der einzelne beste Agent wird fast zur Nebensache. Das ist deutlich weniger sexy als „AGI für alle“, dafür aber näher an dem, was Unternehmen eigentlich so wirklich brauchen.

Windows entdeckt Hybrid Intelligence

Microsoft baut Windows zur Plattform für „Hybrid Intelligence“ um, so steht es zumindest in Pavan Davuluris Blogpost vom 7. Oktober. Hinter dem angenehm groß geratenen Begriff steckt zunächst etwas ziemlich Bodenständiges: KI-Workloads sollen je nach Aufgabe lokal oder in der Cloud laufen, und Agenten bekommen mit den jetzt allgemein verfügbaren Microsoft Execution Containers (MXC) eine Sandbox. Eigene Agenten-Identität über Entra und zentrales Management über Agent 365 sind laut Developer-Blog dagegen erst „soon“ dran. Dazu kommen experimenteller llama.cpp-Support in Windows ML und GitHubs Modell-Router Project HydraFusion, der ab Ende Oktober als Experimental Preview auch lokale Modelle in der GitHub-Copilot-App, der Copilot CLI und VS Code einbeziehen soll. So weit, so unspektakulär.

Aber: Microsoft zeigt auch, was „lokal“ inzwischen bedeuten kann. MAI Code 1.1 Flash bringt 137 Mrd. Gesamt- und 6,8 Mrd. aktive Parameter per 3-Bit-Quantisierung mit 256K Kontext auf den Rechner, und zwar auf RTX-Spark-PCs wie den Surface Laptop Ultra. Das Modell selbst ist 53 GB groß, bei vollem Kontext misst Microsoft einen Speicher-Peak von 75,5 GB, mit 64 GB RAM wird das also nichts. Der Windows-Copilot soll später lokalen Dateikontext nutzen, Aktionen auf dem Rechner ausführen und zwischen lokalen und Cloud-Modellen wechseln. Das ist aber Roadmap („in the coming months“) und nur für Copilot+ PCs vorgesehen. Und wenn Microsoft Windows gleich in der ersten Kernaussage zur „most secure platform for agents“ erklärt, fehlt dafür außer Microsoft bislang vor allem jemand, der das bestätigt. Dicke Ansage, eher dünne Beweislage.

Google Docs kann jetzt auch echtes Markdown

Google kann jetzt etwas, das eigentlich erstaunlich lange gefehlt hat: Markdown-Dateien, die Markdown-Dateien bleiben. Markdown-Autoformat gibt es in Google Docs zwar seit 2022, Import und Export seit 2024, beides lief aber immer über eine Konvertierung in ein Google-Doc. Laut Workspace Updates lassen sich .md-Dateien jetzt direkt in Google Docs öffnen, bearbeiten und gemeinsam kommentieren, ohne sie vorher umzuwandeln. Die Datei bleibt .md, Drive zeigt wahlweise den Rohtext oder eine gerenderte Vorschau mit Links und Tabellen. Der Rollout läuft seit dem 5. Oktober schrittweise (bis zu 15 Tage) für alle Workspace-Kunden und private Google-Accounts. Begründet wird das übrigens ausdrücklich mit LLMs und Agenten.

Das ist jetzt nicht die oberhammermegageile Funktion, aber eine ziemlich praktische Brücke zwischen menschlicher Zusammenarbeit und Workflows, in denen Markdown ohnehin längst Standard ist (in meinem Obsidian-Vault sowieso). Ganz „Docs, nur als Markdown“ ist es allerdings nicht. Laut Hilfe-Center werden Smart Chips zu Text oder Links und HTML zu Plain Text, Farben, Highlights und Ausrichtung fliegen raus. Wer Markdown als portables Textformat nutzt, dürfte genau damit leben können. Wer ein Google-Doc mit Dateiendung .md erwartet, eher nicht.

Das war’s für diese Woche. Und lasst eure Agenten nicht mit fremdem Text allein.