KI-Agenten-Architektur für kleine Teams – wo die Grenze sinnvollerweise liegt

KI-Agenten können planen, Tools bedienen und Aufgaben an andere Agenten weitergeben. In großen Organisationen wächst darum ein eigener Governance-Apparat: Wer darf was freigeben, wer haftet, wer prüft nach. Ein Team aus drei bis fünf Personen kann das nicht nebenbei tragen.

Grenzen braucht ein kleines Setup trotzdem. Ein einziger falsch konfigurierter Tool-Zugriff reicht, um aus einer überschaubaren Automatisierung ein Betriebsrisiko zu machen — und in einem Team ohne eigene Plattformrolle fällt so etwas oft erst auf, wenn jemand von außen nachfragt. Die sinnvolle Architektur ist deshalb bewusst klein: wenige klar abgegrenzte Agenten, enge Berechtigungen, ein sichtbarer Weg zurück zum Menschen.

Das ist unspektakulär. Es funktioniert aber eher.

Welche Aufgaben sich eignen

Kleine Teams haben kurze Entscheidungswege und wenig Puffer für Fehlersuche. Agenten lohnen sich vor allem bei Arbeit, die drei Eigenschaften erfüllt:

• Sie wiederholt sich: etwa Datenaufbereitung, Ticket-Vorsortierung oder regelmäßige Reports.
• Sie lässt sich eindeutig beschreiben: Eingaben, erwartetes Ergebnis und Abbruchbedingungen stehen fest.
• Fehler bleiben billig: Ein Mensch kann das Ergebnis prüfen und mit überschaubarem Aufwand korrigieren.

Die dritte Eigenschaft entscheidet. Was passiert bei einem plausibel klingenden Fehler? Muss jemand nur eine Kategorie berichtigen, eignet sich der Vorgang. Kann derselbe Fehler Geld bewegen, Daten löschen oder Kunden verbindlich informieren, braucht der Ablauf zusätzliche Freigaben — unabhängig davon, wie zuverlässig das Modell in den ersten Wochen gewirkt hat.

Marktprognosen helfen bei dieser Entscheidung nicht. Der eigene Prozess entscheidet: Wie häufig tritt er auf, wie viel Zeit bindet er, wie teuer wird ein falsches Ergebnis?

Autonomie passend zum Risiko wählen

Der Autonomiegrad sollte vor der technischen Umsetzung feststehen. Eine brauchbare Einteilung reicht von festen Abläufen bis zu weitgehend selbstständigen Systemen:

1. Chain: Regelbasierte Schritte in fester Reihenfolge.
2. Workflow: Der Ablauf verzweigt anhand von Logik oder Modellergebnissen.
3. Teilautonom: Ein Agent plant Teilschritte, führt sie aus und fordert bei definierten Fällen Hilfe an.
4. Weitgehend autonom: Das System verfolgt Ziele über längere Zeit und entscheidet mit wenig Aufsicht.

Tragfähig sind für kleine Teams die ersten drei Stufen, und die dritte nur mit eng gezogenen Eskalationsfällen. Jeder zusätzliche Freiheitsgrad verlangt nämlich jemanden, der das Verhalten beobachtet, neue Fälle nachtestet und Freigaben pflegt — dauerhaft, nicht einmalig zum Start. Vollständige Autonomie ist keine Produktfunktion, die man einschaltet. Sie ist eine Betriebsverpflichtung.

Warum der Alleskönner selten trägt

Ein monolithischer Agent wirkt zum Einstieg bequem: ein Prompt, viele Tools, ein zentraler Gesprächsverlauf. Mit jedem neuen Zugriff wird jedoch schwerer nachvollziehbar, warum eine Entscheidung gefallen ist und welche Berechtigung den Fehler überhaupt ermöglicht hat.

Eine robuste Architektur zerlegt den Ablauf nach Verantwortung:

• Spezialisierte Agenten bearbeiten klar definierte Aufgaben wie Transkription, Prüfung oder Klassifikation.
• Tool-Schichten kapseln Zugriffe auf Kalender, Ticketsysteme oder Datenbanken.
• Ein Orchestrator verteilt Aufgaben, sammelt Ergebnisse und entscheidet anhand fester Regeln über Wiederholung oder Eskalation.

Die Aufteilung begrenzt Fehler und kostet dafür Koordination: Jede zusätzliche Komponente braucht Konfiguration, Tests und einen Übergabevertrag, den im Zweifel jemand unter Zeitdruck verstehen muss. Mehr Agenten ergeben deshalb nicht automatisch ein besseres System. Drei reichen für den Start.

Ein Ablauf für Kunden-Onboarding

Ein Onboarding lässt sich beispielsweise in vier prüfbare Schritte zerlegen:

1. Ein Daten-Agent liest freigegebene Kundendaten aus dem CRM.
2. Ein Verifikations-Agent prüft Pflichtfelder und Widersprüche.
3. Ein Dokumenten-Agent erstellt das Willkommensdokument.
4. Ein Versand-Agent bereitet die Nachricht vor.

Der Versand ist die kritische Grenze. Solange ein Mensch die Nachricht freigibt, bleibt ein Fehler sichtbar und korrigierbar; darf der Agent selbst senden, bekommt eine generierte Aussage unmittelbare Außenwirkung, die sich nicht zurückholen lässt.

Protokolle wie das Model Context Protocol standardisieren den Zugriff auf Tools und Datenquellen. Eine Berechtigungsentscheidung ersetzen sie nicht. Ein sauber angebundenes Tool kann weiterhin zu viel dürfen.

Vier Regeln für den Aufbau

1. Berechtigungen am Tool begrenzen

Agenten-Sicherheit beginnt bei den verfügbaren Aktionen. Ein Lesetool kann einen schlechten Bericht erzeugen; ein Tool mit Schreib- oder Löschrecht verändert zusätzlich den Zustand, auf den sich alle folgenden Schritte verlassen.

Der Zugriff startet deshalb mit minimalem Scope, und Schreibrechte kommen einzeln hinzu, nachdem die bekannten Fehlerfälle einmal absichtlich provoziert und beobachtet wurden. Für jede neue Aktion braucht es drei Antworten: Was darf verändert werden? Woran erkennt der Mensch einen Fehler? Wie kommt der vorherige Zustand zurück?

2. Den Orchestrator klein halten

Der Orchestrator verteilt Arbeit und behandelt Fehler. Dafür muss er die Fähigkeiten und Rückgabewerte der spezialisierten Agenten kennen — mehr nicht. Geschäftslogik gehört nur hinein, wenn sie mehrere Schritte betrifft.

Technisch reicht ein überschaubares Skript, das Modellaufrufe und Tool-Nutzung steuert. OpenClaw unterstützt solche Agenten- und Tool-Abläufe; die konkrete Umsetzung richtet sich trotzdem nach den eigenen Übergaben und Abbruchbedingungen.

3. Fehlerwege vor dem Normalfall beschreiben

Agenten scheitern gelegentlich. Gefährlich sind die Fehler, die wie brauchbare Ergebnisse aussehen.

Ein Meeting-Workflow benötigt Audio-Extraktion, Speech-to-Text und Zusammenfassung. Fällt die Transkription teilweise aus, darf die Zusammenfassung nicht mit lückenhaftem Material weiterlaufen und ein Ergebnis liefern, dem niemand die fehlenden zwanzig Minuten ansieht. Der Workflow muss den fehlenden Schritt erkennen, abbrechen und die Aufgabe mit verständlichem Status übergeben.

Ein sichtbarer Abbruch schlägt glatten Unsinn.

4. Tool-Aufrufe nachvollziehbar protokollieren

Ein Logeintrag wie „Aufgabe fehlgeschlagen“ hilft bei der Diagnose kaum. Nötig sind mindestens der ausgeführte Schritt, der verwendete Tool-Zugriff, der Status und eine Referenz auf Eingabe und Ergebnis. Sensible Inhalte gehören dabei weder unmaskiert ins Log noch in Fehlermeldungen.

Ob ELK-Stack oder Cloud-Logging-Dienst, ist zweitrangig. Wichtig ist, dass sich nach einem Vorfall rekonstruieren lässt, welche Entscheidung zu welcher Aktion geführt hat.

Drei Risiken im Betrieb

Kaskadierende Berechtigungen

Ein Agent erhält Zugriff auf E-Mails und erreicht über verlinkte Dokumente weitere Systeme. Seine operative Reichweite wächst, obwohl ihm niemand ausdrücklich zusätzliche Rechte gegeben hat.

Gegenmaßnahme: Zugriffe nach erreichbaren Systemen prüfen, nicht nach vergebenen Rollen. Kurzlebige Autorisierungen verwenden, jeden Scope einzeln vergeben, im Audit den vollständigen Zugriffspfad betrachten.

Optimierung auf falsche Signale

Ein CRM-Agent markiert einen Vorgang zu früh als abgeschlossen, weil bestimmte Wörter oder Felder wie ein Erfolg aussehen. Das Reporting übernimmt den Fehler als gültigen Zustand — und es fällt niemandem auf, bis der Forecast nicht mehr zur Realität passt.

Gegenmaßnahme: Analyse und Ausführung trennen. Ein Agent schlägt eine Änderung vor; ein separater, enger kontrollierter Schritt führt sie nach Validierung aus.

Geteilte Identitäten

Nutzt ein Agent das Konto eines Teammitglieds, erbt er dessen Berechtigungen. Im Protokoll lässt sich später nicht mehr unterscheiden, ob Mensch oder Agent gehandelt hat.

Gegenmaßnahme: Eigene Service-Identitäten mit engen Rollen verwenden und deren Rechte regelmäßig prüfen.

Praxisanker: Ticket-Routing

Ticket-Routing eignet sich als überschaubares Einstiegsszenario. Die Aufgabe wiederholt sich, Kategorien lassen sich prüfen, eine falsche Zuweisung ist korrigierbar.

Ein möglicher Ablauf:

• Ein Classifier schlägt eine Kategorie vor.
• Ein Priority-Agent bewertet die Dringlichkeit anhand freigegebener Merkmale.
• Ein Router schlägt die zuständige Person vor.
• Ein Reporting-Schritt fasst Aufkommen und Korrekturen zusammen.

Zu Beginn erzeugt der Workflow ausschließlich Vorschläge. Das Team misst dann, wie oft Kategorien, Prioritäten und Zuständigkeiten korrigiert werden — über mehrere Wochen, weil die ersten Tage jedes Setups verdächtig gut aussehen. Erst wenn diese Fehler sichtbar und beherrschbar sind, kann eine automatische Zuweisung sinnvoll werden.

Die relevante Kennzahl ist nicht die Automationsquote. Aussagekräftiger ist der Anteil der Vorschläge, die Menschen ohne Änderung übernehmen, getrennt nach Ticketart und Dringlichkeit.

Werkzeuge für ein kleines Setup

Für die Umsetzung kommen unterschiedliche Ebenen infrage:

• OpenClaw für Agentenlaufzeit, Sitzungen und Tool-Anbindung.
• MCP als standardisierte Schnittstelle zu Werkzeugen und Datenquellen.
• Low-Code-Werkzeuge für schnell aufgebaute Prototypen und interne Oberflächen.
• Cloud-Dienste für vorgefertigte Agenten- und Unternehmensintegrationen.

Die Auswahl entscheidet selten über den Erfolg. Wichtiger sind enge Tool-Verträge, verständliche Logs und ein Teammitglied, das den Ablauf im Fehlerfall erklären kann.

Die Grenze

Kleine Teams brauchen keine möglichst große Multi-Agenten-Architektur. Sie brauchen einen Ablauf, dessen Fehlergrenzen sie verstehen.

Ein sinnvoller Start besteht aus einem eng umrissenen Use-Case, wenigen spezialisierten Komponenten und einem Orchestrator mit klaren Abbruchregeln. Neue Schreibrechte werden einzeln vergeben und gegen bekannte Fehlerszenarien geprüft.

Die Mindestregel lautet: Gib einem Agenten eine operative Aktion nur dann frei, wenn du den möglichen Schaden benennen, den Fehler im Log erkennen und den Zustand wiederherstellen kannst.

Weiterführend:

• Deep Dive: Agentic AI Patterns – Planner/Executor, ReAct, Toolformer-Style
• OpenClaw Tutorial Teil 1: Ein KI-Agent in 15 Minuten
• Token-Kosten wirklich verstehen – So kalkulierst du dein Agenten-Budget