Jeder Tool-Call autorisiert.
Jeder Lauf wiederherstellbar.
Jeder Euro zugeordnet.
Die HostSpezial Agent Runtime ist die Betriebsschicht zwischen Modell und Fachanwendung: zustandsbehaftete Läufe, ein Gateway vor jedem Tool, Traces je Span — betrieben in deutschen Rechenzentren.
- < 5 sRecovery
- 8 msGateway p95
- 100 %Daten in DE
npx @hostspezial/agentctl init
- ISO/IEC 27001:2022 zertifiziert
- Rechenzentren in Deutschland
- AVV nach Art. 28 DSGVO
mail.send und Wiederaufnahme auf dem letzten Checkpoint.Agentic AI Infrastruktur ist 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 bleibt austauschbar.
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.
Konsole · Ansicht „Läufe“ mit offener Freigabe Daten im Bild sind Beispielwerte
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.
Drei Situationen, in denen der Unterschied auffällt
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.
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.
Der Prototyp funktioniert. Die Produktion nicht.
Fast nie ist das Modell das Problem. Es sind vier Betriebsfragen, die im Notebook nicht existieren.
Fü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.
Klicken 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. Klicken Sie einen Baustein an — Sie sehen, woran er hängt.
- Zwölf Bausteine, drei Pfade
- Klick, Tab-Taste, Pfeiltasten
- Esc hebt die Auswahl auf
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
Klick oder Tab-Taste wählt einen Baustein · Pfeiltasten wechseln · Esc hebt die Auswahl aufKarte seitlich scrollbar · Tippen wählt einen Baustein, Details erscheinen darunter
- Stand Mitte 2026MCP ist der De-facto-Standard für die Tool-Anbindung; die Registry verschiebt die Werkzeugauswahl von der Startzeit in die Laufzeit.
- Protokolle konsolidiertA2A steht unter neutraler Governance der Linux Foundation, ACP ist darin aufgegangen. Signierte Agent Cards sind Baseline-Schutz.
- Neue RisikoklasseAgentische Lieferkette: Ein MCP-Server, ein Connector oder ein Prompt-Template kann sich zur Laufzeit anders verhalten als deklariert.
Vier Szenarien, die wir konkret gerechnet haben
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.
Szenario ansehen IT-BetriebIncident Response mit Freigabe
Alerts korrelieren, Logs lesen, Rollback vorschlagen, nach Freigabe ausführen, Postmortem schreiben — mit vollständiger Aktionshistorie.
Szenario ansehen FinanzenRechnungs- und Belegverarbeitung
Extraktion, Abgleich gegen das ERP, Routing von Klärfällen, Buchungsvorschlag — jeder Schritt mit Audit-Trail und Beleg-Referenz.
Szenario ansehen EngineeringCodebase-Migration über Tage
Ein langlaufender Agent über tausende Dateien, mit Checkpointing, Batch-weiser PR-Erzeugung und maschinell prüfbarem Erfolgskriterium: die Tests.
Szenario ansehenAgenten 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.
Agenten, die frei in fremden Web-Oberflächen klicken. Entscheidungen mit rechtlicher Außenwirkung ohne menschliche Freigabe. Prozesse ohne definiertes Erfolgskriterium. In allen drei Fällen ist der Betriebsaufwand höher als der Ertrag — unabhängig von der Plattform.
Wer 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:2022, Verarbeitung ausschließlich in Deutschland, AVV nach Art. 28 DSGVO, offengelegte Unterauftragsverarbeiter, Einordnung zum EU AI Act.
Trust-Seite PreiseWas 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.
Preise und Rechner QuickstartIn fünf Minuten zum ersten Lauf
Projekt anlegen, MCP-Server registrieren, Policy schreiben, Agent starten, Trace lesen. Lokal oder direkt in der Sandbox.
Quickstart öffnenEhrliche Vergleiche
Drei Wege führen zum selben Ziel. Wir sagen auf jeder Seite dazu, wann der andere Weg der bessere ist.
Was technische Käufer zuerst fragen
Was ist Agentic AI Infrastruktur?
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.
Warum scheitern Agenten in Produktion, obwohl der Prototyp funktioniert?
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.
Was bedeutet Durable Execution bei KI-Agenten?
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.
Läuft die Plattform in Deutschland?
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.
Welche Modelle und Protokolle werden unterstützt?
Was kostet der Betrieb von KI-Agenten?
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.
Wofür ist die Plattform nicht gebaut?
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.
Erst ein Lauf, dann ein Vertrag
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.