KI-Agenten, die man betreiben kann.
Ein Agent, der Werkzeuge bedient, braucht dieselben Dinge wie jeder andere Dienst: eine Identität, Grenzen, ein Protokoll und eine Rechnung. Genau das liefern wir.
Das Wichtigste auf einen Blick
- Geeignet für
- Unternehmen, die KI-Agenten produktiv betreiben wollen — nicht als Prototyp, sondern mit Verantwortung im Betrieb
- Ausgangssituation
- Der Prototyp funktioniert. Die Produktion ist etwas anderes: Wer sieht, was der Agent getan hat, wer hält ihn an, wer haftet?
- Wir übernehmen
- Betrieb der Agenten-Plattform mit Protokollierung jedes Laufs, Freigaben, Kostenkontrolle je Lauf und Mandant, Rufbereitschaft
- Ihr Ergebnis
- Sie sehen, was Ihre Agenten tun. Jeder Lauf ist nachvollziehbar, jede Freigabe dokumentiert
- Preisrahmen
- ab 690 € im Monat (Einstiegsklasse)Business 1.490 €, Enterprise 3.900 € — dazu nutzungsabhängige Anteile, getrennt ausgewiesen
- Reaktionszeit
- 99,95 % zugesicherte Verfügbarkeit der Plattform
- Dauer
- Erst ein Lauf, dann ein Pilot, dann ein VertragDer erste Schritt kostet Sie 45 Minuten
- Erster Schritt
- 45 Minuten für einen ersten Lauf an Ihrem Anwendungsfall
Was Sie am ersten Tag bekommen.
Sechs Bestandteile, alle im Vertrag benannt. Was nicht enthalten ist, steht auf der Preisseite.
Konsole
Läufe, Agenten, Werkzeuge, Policies und Kosten in einer Oberfläche. Zugang für Ihr Team, Rechte nach Rolle.
Angebundene Systeme
Wir binden Ihre Systeme als MCP-Server an — Datenbank, M365, Ticketsystem, ERP. Sieben Server sind Standardkatalog.
Policies und Freigaben
Betragsgrenzen, Scopes und Freigabeschwellen als versionierte Regeln. Jede Entscheidung landet im Audit-Log.
Traces und Kostenausweis
Jeder Tool-Call als Span, Kosten je Lauf, Use Case und Mandant. Export in Ihr eigenes Monitoring.
Monatlicher Betriebsreport
Verfügbarkeit, Erfolgsquote, Kosten je Task, Vorfälle und Änderungen — als Dokument, das ein Auditor lesen kann.
Ansprechpartner
Benannte Personen statt Ticket-Warteschlange. Ab Klasse Business mit 4-Stunden-Reaktion, Enterprise mit 24/7-Rufbereitschaft.
Eine Konsole, in der Sie sehen, was Ihre Agenten tun
Kein Framework zum Selbstbauen und kein Beratungsprojekt: Sie bekommen eine betriebsbereite Oberfläche, Ihre Systeme angebunden und einen Betrieb mit Namen dahinter.
Wo der Unterschied sichtbar wird.
Der Lauf überlebt Ihr Deployment
Ein Agent, der 40 Minuten arbeitet, verliert bei einem Neustart nichts. Er setzt auf dem letzten Checkpoint auf — und bucht die Erstattung nicht ein zweites Mal.
Sie können jede Aktion erklären
Wer hat was womit ausgelöst, mit welcher Begründung, wann freigegeben? Steht im Audit-Log, nicht in der Erinnerung eines Kollegen.
Die Rechnung überrascht Sie nicht
Budget-Cap je Lauf, Rate-Limit je Werkzeug, Kosten je erfolgreichem Task. Eine Retry-Schleife läuft ins Limit, nicht in Ihre Kostenstelle.
Der Prototyp funktioniert. Die Produktion nicht.
Fast nie ist das Modell das Problem. Es sind vier Betriebsfragen, die im Notebook nicht existieren.
Erst ein Lauf, dann ein Pilot, dann ein Vertrag
In dieser Reihenfolge — nicht umgekehrt. Sie entscheiden nach dem ersten echten Lauf, nicht nach einer Präsentation.
Sandbox mit Ihrem Prozess
Wir binden ein System an, schreiben eine Policy und lassen einen echten Vorgang durchlaufen. Sie sehen Trace, Latenzen und Kosten.
Pilot mit einem Use Case
Ein Prozess geht produktiv — zunächst lesend, dann mit eng begrenztem Aktionsrecht. Eval-Suite und Freigabewege stehen am Ende.
Betrieb mit SLA
Wir betreiben, überwachen und dokumentieren. Neue Use Cases kommen kontrolliert dazu.
Schritt 1 kostet Sie 45 Minuten
Wir brauchen dazu ein System, das der Agent lesen darf, und einen Prozess, den Sie heute manuell erledigen.
Wie der Betrieb technisch abgesichert ist.
Für die Entscheidung reicht der erste Lauf. Wer die Schichten, den Weg eines Laufs und die Verantwortlichkeiten prüfen will:
/01Fünf Schichten, die den Unterschied zwischen Demo und Betrieb ausmachen+
Jede Schicht ist einzeln nutzbar. Wer nur ein Tool-Gateway braucht, bekommt ein Tool-Gateway — nicht die ganze Plattform.
Durable Execution
Event-Sourcing des Laufzustands, Checkpoints an jeder Tool-Grenze, Idempotenz-Keys für Seiteneffekte, Wiederaufnahme statt Neustart.
Multi-Agent-Muster
Planner-Worker-DAGs, Fan-out und Fan-in, Human-in-the-Loop als Wartezustand, A2A-Handoffs an externe Agenten mit signierter Agent Card.
MCP-Hosting und Gateway
Gehostete MCP-Server, Registry mit Laufzeit-Discovery, Schema-Validierung auf Ein- und Ausgabe, Auth, Rate-Limiting und Audit je Call.
Traces, Evals, Replay
OpenTelemetry-Spans je Tool-Call mit Agenten-Identität und Token-Verbrauch, deterministisches Replay, Eval-Harness in der CI, Kosten je Lauf.
Identität, Policy, Sandbox
Der Agent als eigener Principal, OAuth 2.1 mit Resource Indicators, Policy-Entscheid je Tool-Call, Egress-Allowlists, isolierte Ausführung.
Wie das System gebaut ist
Control Plane und Data Plane, Execution-Modell, Memory-Layer, Protokolle, Kostenmodell, Benchmark mit offengelegter Methodik — und die Grenzen.
/02Klicken Sie sich durch den Weg eines Laufs+
Zwölf Bausteine, drei Pfade: der Lauf selbst, die Kontrollebene darüber und die Telemetrie darunter. Jeder Baustein führt in die passende Tiefe.
Der Weg eines Laufs
Von links nach rechts: Ein Ereignis startet den Lauf, der Orchestrator plant, die Runtime führt zustandsbehaftet aus, die Policy Engine entscheidet über jeden Tool-Call, das Gateway spricht mit Ihren Systemen. Wählen Sie oben einen Pfad — dann bleiben nur die Bausteine stehen, die daran hängen.
- Zwölf Bausteine, drei Pfade
- Lauf: vom Ereignis bis zu Ihren Systemen
- Kontrolle und Telemetrie liegen darüber und darunter
Auslöser
Ein Lauf beginnt mit einem Ereignis aus Ihrer Welt: ein Webhook aus dem Shop, ein Ticket, ein Zeitplan, eine Nachricht aus der Queue. Ab diesem Moment existiert eine Run-ID, an der später alles hängt — Trace, Kosten, Audit-Eintrag.
- webhook · rest · zeitplan · queue
- Run-ID ab dem ersten Ereignis
- Idempotenz-Key verhindert Doppelstarts
Orchestrator
Der Planner zerlegt die Aufgabe und verteilt sie auf Sub-Agenten — Fan-out und Fan-in als DAG, nicht als Endlosschleife. Teilaufgaben, die ein fremder Agent besser kann, gehen per A2A-Handoff mit signierter Agent Card raus.
- Planner-Worker-DAG statt freier Schleife
- A2A-Handoff, Agent Card signiert
- Human-in-the-Loop als Wartezustand
Durable Execution
Der Laufzustand liegt außerhalb des Prozesses. Fällt ein Node aus oder deployen Sie mitten im Lauf, setzt die Runtime auf dem letzten Checkpoint auf statt neu zu starten. Tool-Calls mit Seiteneffekt werden über Idempotenz-Keys nicht zweimal ausgeführt.
- Checkpoint an jeder Tool-Grenze
- Recovery unter 5 Sekunden
- Läufe von Sekunden bis Tagen
Event-Log und Checkpoints
Jeder Schritt wird als Ereignis geschrieben, nicht als überschriebener Status. Daraus lässt sich ein Lauf jederzeit rekonstruieren — für die Wiederaufnahme wie für das deterministische Replay im Nachhinein.
- Event-Sourcing statt Statusfeld
- Verschlüsselt, Aufbewahrung nach Vorgabe
- Grundlage für Replay und Audit
Modell-Gateway
Offene Modelle auf eigener GPU über vLLM oder externe Anbieter über eine OpenAI-kompatible API — beides hinter derselben Schnittstelle. Kleine Modelle machen die Routinearbeit, große nur die schweren Schritte.
- self-hosted oder extern, eine API
- Routing klein → groß, Prompt-Cache
- Modell austauschbar, Verträge bleiben
Policy Engine
Vor jedem Tool-Call fällt eine Entscheidung: erlauben, ablehnen oder zur Freigabe geben. Betragsgrenzen, Scopes und Zeitfenster stehen als versionierte Regel, nicht im Prompt. Jede Entscheidung landet im Audit-Log.
- Entscheid je Tool-Call, nicht je Sitzung
- Betragsgrenze, Scope, Zeitfenster
- Regel versioniert, Entscheid protokolliert
Tool-Gateway ( MCP )
Ein Weg nach draußen, statt Zugangsdaten in jedem Agenten. Das Gateway validiert Ein- und Ausgabe gegen das Schema, authentifiziert, begrenzt die Rate und protokolliert jeden Call.
- Registry mit Laufzeit-Discovery
- Schema-Validierung, Auth, Rate-Limit
- 8 ms Zusatzlatenz im p95
Ihre Systeme
Datenbank, M365, Ticketsystem, ERP, Fileshare: als MCP-Server angebunden, mit eigenem Dienstkonto je Server statt geliehener Admin-Rechte. Sieben Server sind Standardkatalog, weitere binden wir an.
- 7 MCP-Server im Standardkatalog
- Eigenes Konto und Scope je System
- Ausgehender Verkehr nur auf Allowlist
Traces, Evals, Kosten
Jeder Tool-Call ist ein Span mit Agenten-Identität, Dauer und Token-Verbrauch. Damit lässt sich ein Lauf im Nachhinein Schritt für Schritt nachvollziehen — und jeder Euro einem Use Case zuordnen.
- OpenTelemetry, Export in Ihr Monitoring
- Deterministisches Replay eines Laufs
- Kosten je Lauf, Mandant und Use Case
Mensch im Lauf
Was über der Grenze liegt, wird nicht abgebrochen, sondern angehalten. Der Lauf wartet als Zustand — bis zu 24 Stunden — und läuft nach der Freigabe an derselben Stelle weiter.
- Wartezustand statt Abbruch
- Freigabe in der Konsole oder per Mail
- Wer wann freigegeben hat, steht im Log
Konsole, Policies, Audit
Die Ebene, auf der Ihr Team arbeitet: Läufe ansehen, Policies ändern, Freigaben erteilen, Audit-Log exportieren. Rechte nach Rolle — wer freigeben darf, muss nicht deployen dürfen.
- Läufe, Agenten, Werkzeuge, Kosten
- Policies versioniert und nachvollziehbar
- Monatlicher Betriebsreport als Dokument
Alles davon läuft in Deutschland
Primär im Rechenzentrum der SÜC Coburg, mit Disaster-Recovery-Standort bei der SWN Neustadt. Auf Wunsch on-premise auf Ihrer Infrastruktur — dieselbe Karte, Ihr Blech.
- ISO/IEC 27001 :2022 zertifiziert
- AVV nach Art. 28 DSGVO
- Unterauftragsverarbeiter offengelegt
- Stand Mitte 2026 — MCP ist der De-facto-Standard für die Tool-Anbindung; die Registry verschiebt die Werkzeugauswahl von der Startzeit in die Laufzeit.
- Protokolle konsolidiert — A2A steht unter neutraler Governance der Linux Foundation, ACP ist darin aufgegangen. Signierte Agent Cards sind Baseline-Schutz.
- Neue Risikoklasse — Agentische Lieferkette: Ein MCP-Server, ein Connector oder ein Prompt-Template kann sich zur Laufzeit anders verhalten als deklariert.
/03Wer den Betrieb verantwortet, muss ihn auch belegen können+
Im DACH-Markt entscheidet häufig nicht das Feature, sondern die Frage, wer bei einem Vorfall mit welchen Nachweisen haftet.
Zertifikate, Datenresidenz, Subunternehmer
ISO/IEC 27001:2024, Verarbeitung ausschließlich in Deutschland, AVV nach Art. 28 DSGVO, offengelegte Unterauftragsverarbeiter, Einordnung zum EU AI Act.
Was der Betrieb kostet
Betriebspauschale plus nutzungsabhängige Komponenten, mit Rechner für Läufe, Tool-Calls und Tokens — und der Kennzahl, auf die es ankommt: Kosten je erfolgreichem Task.
In fünf Minuten zum ersten Lauf
Projekt anlegen, MCP-Server registrieren, Policy schreiben, Agent starten, Trace lesen. Lokal oder direkt in der Sandbox.
/04Ehrliche Vergleiche+
Drei Wege führen zum selben Ziel. Wir sagen auf jeder Seite dazu, wann der andere Weg der bessere ist.
Vier Szenarien — und wo Agenten wirklich tragen.
Jedes mit Ausgangslage, Agenten-Design, Architektur, Code und Ergebnis — inklusive der Fälle, in denen es nicht funktioniert.
Support-Deflection mit Aktionsrecht
Der Agent liest das Ticket, prüft die Bestellhistorie, führt Rückerstattungen bis zu einem Limit selbst aus und eskaliert darüber an einen Menschen.
Incident Response mit Freigabe
Alerts korrelieren, Logs lesen, Rollback vorschlagen, nach Freigabe ausführen, Postmortem schreiben — mit vollständiger Aktionshistorie.
Rechnungs- und Belegverarbeitung
Extraktion, Abgleich gegen das ERP, Routing von Klärfällen, Buchungsvorschlag — jeder Schritt mit Audit-Trail und Beleg-Referenz.
Codebase-Migration über Tage
Ein langlaufender Agent über tausende Dateien, mit Checkpointing, Batch-weiser PR-Erzeugung und maschinell prüfbarem Erfolgskriterium: die Tests.
Agenten funktionieren dort, wo sich Ergebnisse maschinell prüfen lassen
Das ist das belastbarste Muster aus zwei Jahren Praxis — und die wichtigste Frage bei der Auswahl Ihres ersten Use Case.
Maschinell prüfbares Ergebnis
Tests laufen durch, Summen stimmen, Schema validiert, Datensatz existiert. Hier arbeiten Agenten zuverlässig und der Nutzen ist messbar.
Nur menschlich beurteilbar
Freitext mit Außenwirkung, Ermessensentscheidungen, offene Recherche. Machbar — aber mit Freigaben, und mit deutlich geringerem Ertrag.
Was technische Käufer zuerst fragen
Die Betriebsschicht zwischen Modell und Fachanwendung. Sie führt Agenten-Läufe zustandsbehaftet aus, überlebt Neustarts durch Checkpointing, autorisiert jeden Tool-Call einzeln, protokolliert jeden Schritt als Trace und ordnet Tokens und Kosten dem einzelnen Lauf zu. Das Modell selbst ist dabei austauschbar.
Weil die Fehlerquellen nicht im Modell liegen, sondern in der Infrastruktur: nicht-deterministische Retries, Zustandsverlust bei Neustarts, Tool-Calls ohne Autorisierungsgrenze, fehlende Traces beim Debuggen und Token-Kosten ohne Deckel. Ein Notebook-Lauf hat keine dieser Anforderungen, ein Produktivsystem alle.
Dass der Fortschritt eines Laufs außerhalb des Prozesses persistiert wird. Fällt der Node aus, wird der Lauf auf dem letzten Checkpoint fortgesetzt statt neu gestartet. Bereits ausgeführte Tool-Calls mit Seiteneffekten werden über Idempotenz-Keys nicht wiederholt. Details im Runtime-Kapitel.
Ja. Betrieb und Datenhaltung erfolgen in deutschen Rechenzentren — primär im Rechenzentrum der SÜC Coburg, mit Disaster-Recovery-Standort bei der SWN Neustadt. Alternativ betreiben wir die Plattform on-premise auf Ihrer Infrastruktur. HostSpezial ist nach ISO/IEC 27001 :2022 zertifiziert. Details auf der Trust-Seite.
Modellseitig offene, selbst hostbare Modelle über vLLM sowie externe Anbieter über ein Gateway mit OpenAI-kompatibler API. Protokollseitig MCP für die Tool-Anbindung und A2A für die Kommunikation zwischen Agenten, einschließlich signierter Agent Cards unter /.well-known/agent-card.json.
Die Betriebspauschalen entsprechen den Managed-KI-Klassen: 690 €, 1.490 € und ab 3.900 € pro Monat, jeweils zzgl. USt. Dazu kommen nutzungsabhängige Komponenten je Lauf, je Tool-Call und je Million Tokens. Aussagekräftig ist nicht der Preis je Token, sondern der Preis je erfolgreich abgeschlossenem Task — inklusive der Fehlversuche. Rechner auf der Preisseite.
Nicht für Echtzeit-Inferenz unter 50 Millisekunden, nicht für Training oder Feintuning großer Modelle und nicht für Agenten, die ungeprüft in offenen Web-Oberflächen klicken. Sie ist auf serverseitige, mehrstufige Tool-Nutzung mit maschinell prüfbaren Ergebnissen ausgelegt. Der vollständige Abschnitt steht in der Architektur.
Eine Sandbox mit einem Ihrer echten Prozesse
Wir richten eine Sandbox mit einem Ihrer echten Prozesse ein — ein Tool, eine Policy, ein Trace. Danach wissen Sie, ob der Use Case trägt. Ohne Vorleistung Ihrerseits.
Die Serie zur Betriebsschicht
Zwölf Beiträge zu den Fragen, die vor dem ersten produktiven Agenten stehen — jeweils mit Rechenbeispiel und ehrlicher Grenze.
Passend dazu bei HostSpezial
Anwendungsfall besprechen.
Schicken Sie uns einen Prozess, der heute schon Zeit kostet. Wir sagen Ihnen, ob er sich für einen Agenten eignet.
30 Minuten, unverbindlich und direkt mit einem technischen Ansprechpartner.