In Part 1 we argued that the workflow-versus-agent choice is not binary. It is a dial. This piece is about what actually lives at positions two and three on that dial - the workflow patterns that quietly solve most enterprise AI problems while everyone else is trying to build agents.
Core Thesis
There are five patterns. They are not exciting. They are what ships. The gap between "one LLM call" and "a full agent" is where 95% of production value lives - and it is the step most enterprise AI conversations skip straight past.
The pattern gap in most enterprise AI conversations
When a boardroom discusses AI architecture, the conversation tends to jump from "we need an agent" to "which framework should we use." The step in the middle - what pattern actually fits this problem - is rarely named. Which means most enterprise teams end up building either a single-LLM-call chatbot or a full agent, with nothing in between.
That gap is where 95% of production value actually lives.
The five patterns sit between the single call and the autonomous agent. Every one of them is a workflow: the developer controls the route, the model does the reasoning at each step.
Anthropic's engineering team catalogued five compositional patterns in Building Effective Agents. All five are workflows in the strict sense - the developer controls the route, the model does the reasoning at each step. All five are deterministic enough to audit, cheap enough to scale, and simple enough to debug. And all five have been shipping in production for two years while the industry has been distracted by autonomous agents.
This piece describes each in business terms, when to use it, and what it costs when you use it wrong.
01
Prompt chaining: the assembly line
Wins: sequential, one artefactCosts: latency
Prompt chaining is a sequence of LLM calls where each step processes the output of the previous one. One call extracts, the next classifies, the next summarises, the last formats. Each station does one thing well.
The business analogy is the assembly line. Each station performs a specific, repeatable task. The output of one is the input of the next. Nothing is left to interpretation. If the process breaks, you know exactly which station broke it.
Where it wins. Any process with predictable, sequential steps and a clear artefact at the end. Regulatory filings. Onboarding document generation. Multi-stage document translation. BaFin compliance summaries. In our client work, at least 40% of what enterprises call "AI use cases" collapse to this pattern.
Where it costs you. Latency. A five-step chain runs five times slower than a single call. If your use case is user-facing and sub-second matters, chain fewer steps.
Prompt chaining is not a placeholder architecture. It is the pattern most enterprise AI teams should default to and few do.
02
Routing: the triage desk
Wins: broad input, specialised handlingCosts: routing errors compound
A routing workflow sends the input to one of several specialised follow-up paths. A first LLM call reads the request, classifies it, and dispatches it to the right handler. The handler can be another LLM call with a specialised prompt, a different model, or a workflow of its own.
The business analogy is the triage desk in a hospital emergency department. One person makes a fast assessment and sends each patient to the right team. General complaints go to one path. Urgent trauma goes to another. Fraud goes to a third. The triage nurse does not treat the patient. The triage nurse decides where the patient goes.
Where it wins. Customer support inboxes. Multilingual document intake in a DACH enterprise handling German, French, Italian, English and Polish in one queue. Insurance claims that split into fifteen sub-flows depending on policy type. Anywhere the input distribution is broad but each subclass has a well-defined response.
Where it costs you. Routing errors compound. A misrouted request costs you not just the wrong response but the time it takes to detect and re-route. Invest in the classifier prompt. Log the routing decisions. Treat the router as the most critical LLM call in the workflow, not the least.
The router is not a preprocessing step. It is the workflow. Everything else is what happens once the routing decision is made.
03
Parallelisation: the pit crew
Wins: independent subtasksCosts: token spend, coordination
A parallelisation workflow runs multiple LLM calls simultaneously and aggregates the results. It comes in two shapes. Sectioning splits one task into independent subtasks that run in parallel and combine at the end. Voting runs the same task multiple times with different prompts or models and takes the majority answer or the most confident one.
The business analogy is the Formula 1 pit crew. Four wheels, one team, four seconds. No worker waits for another. The result is a car back on the track faster than any sequential process could achieve.
Where it wins. Multi-document review - each contract, each supplier form, each medical record in parallel. Vendor comparison across dimensions. Code review where different prompts check for different vulnerabilities. Content moderation where three checks run simultaneously - sentiment, factual accuracy, brand safety. Anywhere the aggregate answer is stronger than any single answer.
Where it costs you. Coordination overhead and token spend. If your subtasks are not truly independent, parallel execution just multiplies the failure surface without gaining speed. And voting workflows can be expensive - three runs of the same task cost three times as much as one.
Parallelisation is not always faster. It is faster only when the parts are actually parallel.
04
Orchestrator-subagent: the project manager
Wins: complex structured deliverablesCosts: token consumption
An orchestrator-subagent workflow uses a central LLM to break a complex task into subtasks, delegate each to a specialised LLM, and synthesise the results. The orchestrator does not do the work. The orchestrator decides what work needs doing.
The business analogy is a project manager. They receive a brief - "produce a market-entry report for a new geography." They do not write the report. They decompose it into research, financial analysis, competitor mapping, and regulatory review. They assign each to the right specialist. They synthesise the outputs into a single deliverable. The specialists never talk to each other. They talk to the project manager.
Where it wins. Research synthesis across sources. Long-form deliverables that require multiple perspectives. RFP responses. Due diligence reports. Anywhere the deliverable is too complex for a single prompt but too structured for a full agent.
Where it costs you. Token consumption. The orchestrator holds the full context of every subagent's output. That context grows fast. Budget for it.
This pattern is often what teams build when they think they are building an agent. The difference is that here, the developer controls the decomposition. In an agent, the LLM does. Say what you actually built.
05
Evaluator loops: the writer and the editor
Wins: quality over speedCosts: iteration count
An evaluator loop runs one LLM to produce a response and a second LLM to critique it. If the critique passes, the response is returned. If not, the first LLM revises based on the critique. The loop continues until quality criteria are met or a maximum iteration count is reached.
The business analogy is the writer and the editor. The writer drafts. The editor reads with fresh eyes and marks up what needs work. The writer revises. The editor reads again. The final draft is not the writer's alone. It is the product of two minds correcting each other.
Where it wins. Regulated content generation where accuracy matters more than speed. Literary or technical translation where nuance requires iteration. Complex code generation with test-driven validation. Long-form drafting where a single pass rarely produces publication-ready output. Any workflow subject to EU AI Act Article 14 human-oversight expectations, where the evaluator can be a first-line check before the human reviewer.
Where it costs you. Iteration count. Each loop is another two LLM calls. Set a hard cap. Track the average iterations per output in production. If your loops routinely max out, either the evaluator criteria are too strict or the generator model is not strong enough for the task.
The evaluator is not overhead. It is the mechanism by which quality becomes measurable.
How to choose between them
Which pattern fits your problem is usually clear once you write down the shape of the input and the shape of the output.
| Pattern | Shape of the problem | Business analogy | Typical enterprise use |
|---|
| Prompt chaining | Sequential steps, one clear artefact | Assembly line | Regulatory filings, compliance summaries |
| Routing | Broad input, specialised handling | Triage desk | Customer support, multilingual intake |
| Parallelisation | Independent subtasks or repeated checks | Pit crew | Document review, content moderation |
| Orchestrator-subagent | Complex deliverable, structured decomposition | Project manager | Research reports, RFPs, due diligence |
| Evaluator loops | Quality matters more than speed | Writer and editor | Regulated content, translation, code |
Most real enterprise systems combine two or three of these. A supplier-onboarding workflow uses routing at the intake and prompt chaining inside each route. A regulatory reporting system uses orchestrator-subagent for the section-by-section drafting and evaluator loops for final review. The patterns are not exclusive. They compose.
The supplier-onboarding system from Part 1, re-read as patterns. Three of the five, one human checkpoint, no agent anywhere - and none of it needed one.
Where teams go wrong
Three failure modes we see repeatedly in enterprise deployments.
Building an agent when a chain would ship
The most common failure. A team decides they need "an agent" for a task that is genuinely sequential and reasonably predictable. They spend six months building autonomy features they never needed and cannot govern. A prompt chain would have shipped in six weeks with better reliability and one-tenth the cost.
Skipping routing because it feels too simple
Enterprise teams often want the single-LLM-call solution because it is clean. But when the input distribution is broad - multiple languages, multiple document types, multiple regulatory contexts - a single prompt trying to handle everything is what actually fails in production. Routing is not a compromise. It is the pattern.
Treating orchestrator-subagent as an agent
Because the orchestrator makes decisions about task decomposition, teams sometimes describe it to leadership as "our agent." This is a labelling error with real consequences - it changes the governance conversation, the audit conversation, and the risk conversation. If the developer wrote the decomposition logic, it is a workflow. Say so.
Three questions to ask your AI team this week
- For each of our current AI projects, which of the five patterns fits? If the answer is "none," we are probably over-reaching for an agent.
- Where are we running LLM calls sequentially that could run in parallel? What would it cost - in tokens and in latency - to change?
- Are we using evaluator loops in production, or just at pilot? If just at pilot, why not in production?
Key takeaways
→
Five patterns solve most of what enterprise AI is asked to do. Chains, routing, parallelisation, orchestrator-subagent, evaluator loops.
→
The gap between "one LLM call" and "a full agent" is where 95% of production value lives.
→
Patterns compose. Most real enterprise systems use two or three together.
→
The most common failure is not picking the wrong pattern. It is jumping past patterns to agents.
→
If a developer writes the decomposition logic, it is a workflow. If the LLM writes it, it is an agent. Say what you actually built.
Working through this in your organisation? We help European enterprises pick and combine the right patterns for their problem.
Book a 30-min call →
In Teil 1 haben wir argumentiert, dass die Entscheidung zwischen Workflow und Agent keine Binärwahl ist. Sie ist ein Regler. Dieser Beitrag handelt davon, was auf Position zwei und drei dieses Reglers tatsächlich stattfindet - die Workflow-Muster, die stillschweigend die meisten Unternehmens-KI-Probleme lösen, während alle anderen versuchen, Agenten zu bauen.
Kernthese
Es gibt fünf Muster. Sie sind nicht aufregend. Sie sind das, was in Produktion geht. Die Lücke zwischen „einem einzelnen LLM-Aufruf" und „einem vollwertigen Agenten" ist genau dort, wo 95 % des Produktionswerts liegen - und genau dieser Schritt wird in den meisten Unternehmens-KI-Gesprächen übersprungen.
Die Musterlücke in den meisten Unternehmens-KI-Gesprächen
Wenn in einem Vorstandsgespräch über KI-Architektur diskutiert wird, springt die Unterhaltung meist von „wir brauchen einen Agenten" direkt zu „welches Framework nehmen wir." Der Schritt dazwischen - welches Muster tatsächlich zu diesem Problem passt - wird selten benannt. Das führt dazu, dass die meisten Unternehmensteams entweder einen Chatbot mit einem einzigen LLM-Aufruf oder einen vollwertigen Agenten bauen - und nichts dazwischen.
Genau in dieser Lücke liegen 95 % des Produktionswerts.
Die fünf Muster liegen zwischen dem Einzelaufruf und dem autonomen Agenten. Jedes davon ist ein Workflow: Der Entwickler steuert die Route, das Modell übernimmt das Denken an jeder Station.
Anthropics Engineering-Team hat in Building Effective Agents fünf kompositionelle Muster katalogisiert. Alle fünf sind Workflows im strengen Sinne - der Entwickler steuert die Route, das Modell übernimmt das Denken an jeder Station. Alle fünf sind deterministisch genug für eine Prüfung, günstig genug zum Skalieren und einfach genug zum Debuggen. Und alle fünf laufen seit zwei Jahren in Produktion, während die Branche von autonomen Agenten abgelenkt war.
Dieser Beitrag beschreibt jedes Muster in Geschäftssprache: wann man es einsetzt und was es kostet, wenn man es falsch einsetzt.
01
Prompt-Ketten: das Fließband
Stärke: sequenziell, ein ArtefaktKosten: Latenz
Eine Prompt-Kette ist eine Abfolge von LLM-Aufrufen, bei der jeder Schritt die Ausgabe des vorherigen verarbeitet. Ein Aufruf extrahiert, der nächste klassifiziert, der nächste fasst zusammen, der letzte formatiert. Jede Station macht eine Sache gut.
Die Geschäftsanalogie ist das Fließband. Jede Station erfüllt eine spezifische, wiederholbare Aufgabe. Die Ausgabe der einen ist die Eingabe der nächsten. Nichts bleibt der Interpretation überlassen. Bricht der Prozess, wissen Sie genau, welche Station ihn gebrochen hat.
Wo es gewinnt. Jeder Prozess mit vorhersagbaren, sequenziellen Schritten und einem klaren Artefakt am Ende. Regulatorische Meldungen. Erstellung von Onboarding-Dokumenten. Mehrstufige Dokumentübersetzung. BaFin-Compliance-Zusammenfassungen. In unserer Kundenarbeit lassen sich mindestens 40 % dessen, was Unternehmen „KI-Anwendungsfälle" nennen, auf dieses Muster reduzieren.
Was es kostet. Latenz. Eine fünfstufige Kette läuft fünfmal langsamer als ein einzelner Aufruf. Ist Ihr Anwendungsfall nutzerseitig und zählt jede Sekunde, verketten Sie weniger Schritte.
Prompt-Ketten sind keine Übergangsarchitektur. Sie sind das Muster, zu dem die meisten Unternehmens-KI-Teams standardmäßig greifen sollten - und es kaum jemand tut.
02
Routing: die Triage-Station
Stärke: breiter Input, spezialisierte BearbeitungKosten: Routing-Fehler summieren sich
Ein Routing-Workflow leitet die Eingabe an einen von mehreren spezialisierten Folgepfaden weiter. Ein erster LLM-Aufruf liest die Anfrage, klassifiziert sie und übergibt sie an den richtigen Bearbeitungspfad. Dieser Pfad kann ein weiterer LLM-Aufruf mit spezialisiertem Prompt sein, ein anderes Modell oder ein eigener Workflow.
Die Geschäftsanalogie ist die Triage-Station in einer Notaufnahme. Eine Person trifft eine schnelle Einschätzung und schickt jeden Patienten zum richtigen Team. Allgemeine Beschwerden gehen den einen Weg. Akute Traumata einen anderen. Betrugsverdacht einen dritten. Die Triage-Kraft behandelt nicht. Sie entscheidet, wohin der Patient geht.
Wo es gewinnt. Kundenservice-Postfächer. Mehrsprachiger Dokumenteneingang in einem DACH-Unternehmen, das Deutsch, Französisch, Italienisch, Englisch und Polnisch in einer Warteschlange verarbeitet. Versicherungsschäden, die sich je nach Policentyp in fünfzehn Teilprozesse aufspalten. Überall dort, wo die Eingabeverteilung breit ist, jede Unterklasse aber eine klar definierte Antwort hat.
Was es kostet. Routing-Fehler summieren sich. Eine falsch geroutete Anfrage kostet Sie nicht nur die falsche Antwort, sondern auch die Zeit, den Fehler zu entdecken und neu zu routen. Investieren Sie in den Klassifikator-Prompt. Protokollieren Sie die Routing-Entscheidungen. Behandeln Sie den Router als den kritischsten LLM-Aufruf im Workflow, nicht als den unwichtigsten.
Der Router ist kein Vorverarbeitungsschritt. Er ist der Workflow. Alles andere ist das, was nach der Routing-Entscheidung passiert.
03
Parallelisierung: die Boxencrew
Stärke: unabhängige TeilaufgabenKosten: Token-Verbrauch, Koordination
Ein Parallelisierungs-Workflow führt mehrere LLM-Aufrufe gleichzeitig aus und aggregiert die Ergebnisse. Es gibt zwei Ausprägungen. Sectioning teilt eine Aufgabe in unabhängige Teilaufgaben, die parallel laufen und am Ende zusammengeführt werden. Voting führt dieselbe Aufgabe mehrfach mit unterschiedlichen Prompts oder Modellen aus und nimmt die Mehrheitsantwort oder die zuversichtlichste.
Die Geschäftsanalogie ist die Formel-1-Boxencrew. Vier Räder, ein Team, vier Sekunden. Niemand wartet auf jemanden. Das Ergebnis ist ein Auto, das schneller zurück auf der Strecke ist, als es ein sequenzieller Prozess je schaffen könnte.
Wo es gewinnt. Prüfung mehrerer Dokumente - jeder Vertrag, jedes Lieferantenformular, jede Patientenakte parallel. Anbietervergleich über mehrere Dimensionen. Code-Review, bei dem verschiedene Prompts auf verschiedene Schwachstellen prüfen. Content-Moderation, bei der drei Prüfungen gleichzeitig laufen - Tonalität, Faktentreue, Markensicherheit. Überall dort, wo die aggregierte Antwort stärker ist als jede einzelne.
Was es kostet. Koordinationsaufwand und Token-Verbrauch. Sind Ihre Teilaufgaben nicht wirklich unabhängig, vervielfacht die parallele Ausführung nur die Fehlerfläche, ohne Geschwindigkeit zu gewinnen. Und Voting-Workflows können teuer werden - drei Durchläufe derselben Aufgabe kosten dreimal so viel wie einer.
Parallelisierung ist nicht immer schneller. Sie ist nur dann schneller, wenn die Teile wirklich parallel sind.
04
Orchestrator-Subagent: die Projektleitung
Stärke: komplexe, strukturierte ErgebnisseKosten: Token-Verbrauch
Ein Orchestrator-Subagent-Workflow nutzt ein zentrales LLM, um eine komplexe Aufgabe in Teilaufgaben zu zerlegen, jede an ein spezialisiertes LLM zu delegieren und die Ergebnisse zusammenzuführen. Der Orchestrator macht die Arbeit nicht. Der Orchestrator entscheidet, welche Arbeit zu tun ist.
Die Geschäftsanalogie ist eine Projektleitung. Sie erhält ein Briefing - „erstellen Sie einen Markteintrittsbericht für eine neue Region." Sie schreibt den Bericht nicht selbst. Sie zerlegt ihn in Recherche, Finanzanalyse, Wettbewerbsanalyse und regulatorische Prüfung. Sie vergibt jede Aufgabe an die richtige Fachperson. Sie führt die Ergebnisse zu einem einzigen Dokument zusammen. Die Fachleute sprechen nie miteinander. Sie sprechen mit der Projektleitung.
Wo es gewinnt. Rechercheergebnisse über mehrere Quellen zusammenführen. Umfangreiche Dokumente, die mehrere Perspektiven erfordern. Ausschreibungsantworten. Due-Diligence-Berichte. Überall dort, wo das Ergebnis zu komplex für einen einzelnen Prompt, aber zu strukturiert für einen vollwertigen Agenten ist.
Was es kostet. Token-Verbrauch. Der Orchestrator hält den vollständigen Kontext jedes Subagenten-Ergebnisses. Dieser Kontext wächst schnell. Planen Sie ihn ein.
Dieses Muster ist oft das, was Teams bauen, wenn sie glauben, einen Agenten zu bauen. Der Unterschied: Hier steuert der Entwickler die Zerlegung. Bei einem Agenten tut das LLM es. Nennen Sie beim Namen, was Sie tatsächlich gebaut haben.
05
Evaluator-Schleifen: Autor und Lektorat
Stärke: Qualität vor GeschwindigkeitKosten: Anzahl der Durchläufe
Eine Evaluator-Schleife nutzt ein LLM, das eine Antwort erzeugt, und ein zweites LLM, das sie kritisiert. Besteht die Antwort die Kritik, wird sie zurückgegeben. Wenn nicht, überarbeitet das erste LLM auf Basis der Kritik. Die Schleife läuft, bis die Qualitätskriterien erfüllt sind oder eine maximale Durchlaufzahl erreicht ist.
Die Geschäftsanalogie sind Autor und Lektorat. Der Autor schreibt einen Entwurf. Das Lektorat liest mit frischem Blick und markiert, was noch fehlt. Der Autor überarbeitet. Das Lektorat liest erneut. Die Endfassung gehört nicht dem Autor allein. Sie ist das Produkt zweier Köpfe, die sich gegenseitig korrigieren.
Wo es gewinnt. Erstellung regulierter Inhalte, bei denen Genauigkeit wichtiger ist als Geschwindigkeit. Literarische oder technische Übersetzung, bei der Nuancen mehrere Durchläufe brauchen. Komplexe Codegenerierung mit testgetriebener Validierung. Längere Texte, bei denen ein einzelner Durchlauf selten veröffentlichungsreif ist. Jeder Workflow, der unter die Human-Oversight-Anforderungen von Artikel 14 des EU AI Act fällt - hier kann der Evaluator eine erste Prüfinstanz vor dem menschlichen Prüfer sein.
Was es kostet. Die Anzahl der Durchläufe. Jede Schleife bedeutet zwei weitere LLM-Aufrufe. Setzen Sie eine harte Obergrenze. Messen Sie die durchschnittliche Durchlaufzahl pro Ergebnis in Produktion. Läuft Ihre Schleife regelmäßig ins Limit, sind entweder die Evaluator-Kriterien zu streng oder das Generator-Modell für die Aufgabe zu schwach.
Der Evaluator ist kein Overhead. Er ist der Mechanismus, durch den Qualität messbar wird.
Wie man zwischen ihnen wählt
Welches Muster zu Ihrem Problem passt, wird meist klar, sobald Sie die Form der Eingabe und die Form der Ausgabe aufschreiben.
| Muster | Form des Problems | Geschäftsanalogie | Typischer Einsatz |
|---|
| Prompt-Ketten | Sequenzielle Schritte, ein klares Artefakt | Fließband | Regulatorische Meldungen, Compliance-Zusammenfassungen |
| Routing | Breiter Input, spezialisierte Bearbeitung | Triage-Station | Kundenservice, mehrsprachiger Eingang |
| Parallelisierung | Unabhängige Teilaufgaben oder Mehrfachprüfungen | Boxencrew | Dokumentenprüfung, Content-Moderation |
| Orchestrator-Subagent | Komplexes Ergebnis, strukturierte Zerlegung | Projektleitung | Rechercheberichte, Ausschreibungen, Due Diligence |
| Evaluator-Schleifen | Qualität zählt mehr als Geschwindigkeit | Autor und Lektorat | Regulierte Inhalte, Übersetzung, Code |
Die meisten echten Unternehmenssysteme kombinieren zwei oder drei davon. Ein Lieferanten-Onboarding-Workflow nutzt Routing am Eingang und Prompt-Ketten innerhalb jedes Pfads. Ein regulatorisches Berichtssystem nutzt Orchestrator-Subagent für die abschnittsweise Erstellung und Evaluator-Schleifen für die Endprüfung. Die Muster schließen sich nicht aus. Sie lassen sich kombinieren.
Das Lieferanten-Onboarding-System aus Teil 1, neu gelesen als Muster. Drei der fünf, ein menschlicher Kontrollpunkt, nirgends ein Agent - und keiner wurde gebraucht.
Wo Teams falsch abbiegen
Drei Fehlermuster, die uns in Unternehmens-Deployments immer wieder begegnen.
Einen Agenten bauen, wo eine Kette ausgeliefert hätte
Der häufigste Fehler. Ein Team entscheidet, es brauche „einen Agenten" für eine Aufgabe, die eigentlich sequenziell und gut vorhersagbar ist. Sechs Monate gehen in Autonomiefunktionen, die nie gebraucht wurden und nicht regierbar sind. Eine Prompt-Kette wäre in sechs Wochen live gegangen - zuverlässiger und zu einem Zehntel der Kosten.
Routing überspringen, weil es zu simpel wirkt
Unternehmensteams wollen oft die Lösung mit einem einzigen LLM-Aufruf, weil sie sauber wirkt. Aber wenn die Eingabeverteilung breit ist - mehrere Sprachen, mehrere Dokumenttypen, mehrere regulatorische Kontexte - ist genau der eine Prompt, der alles abdecken soll, das, was in Produktion scheitert. Routing ist kein Kompromiss. Es ist das Muster.
Orchestrator-Subagent als Agent verkaufen
Weil der Orchestrator Entscheidungen über die Aufgabenzerlegung trifft, beschreiben Teams ihn gegenüber der Geschäftsführung manchmal als „unseren Agenten." Das ist ein Etikettierungsfehler mit realen Folgen - er verändert das Governance-Gespräch, das Audit-Gespräch und das Risikogespräch. Wenn der Entwickler die Zerlegungslogik geschrieben hat, ist es ein Workflow. Sagen Sie es auch so.
Drei Fragen für Ihr KI-Team diese Woche
- Welches der fünf Muster passt zu jedem unserer aktuellen KI-Projekte? Lautet die Antwort „keines", greifen wir vermutlich zu früh nach einem Agenten.
- Wo führen wir LLM-Aufrufe sequenziell aus, die parallel laufen könnten? Was würde die Umstellung kosten - in Token und in Latenz?
- Nutzen wir Evaluator-Schleifen in Produktion oder nur im Pilotprojekt? Wenn nur im Pilot: warum nicht in Produktion?
Das Wichtigste in Kürze
→
Fünf Muster lösen das meiste, was von Unternehmens-KI verlangt wird. Ketten, Routing, Parallelisierung, Orchestrator-Subagent, Evaluator-Schleifen.
→
Die Lücke zwischen „einem LLM-Aufruf" und „einem vollwertigen Agenten" ist dort, wo 95 % des Produktionswerts liegen.
→
Muster lassen sich kombinieren. Die meisten echten Unternehmenssysteme nutzen zwei oder drei gemeinsam.
→
Der häufigste Fehler ist nicht die Wahl des falschen Musters. Es ist, die Muster zu überspringen und direkt zu Agenten zu greifen.
→
Schreibt ein Entwickler die Zerlegungslogik, ist es ein Workflow. Schreibt das LLM sie, ist es ein Agent. Nennen Sie beim Namen, was Sie tatsächlich gebaut haben.
Working through this in your organisation? We help European enterprises pick and combine the right patterns for their problem.
Book a 30-min call →
