Zum Inhalt springen
Ryannel
Eigenes Produkt Tavora

Tavora: KI-Agenten in Produktion betreiben — ohne dass jeder Modell-Update Sie pagert.

Tavora ist die Plattform für Software-Teams, die KI-Agenten ausliefern wollen — kontrollierbar, beobachtbar, mit Eval-Gates vor jedem Deployment. Aus dieser täglichen Bau-Realität speist sich auch meine Beratung für Software-Teams.

  • Eval-gated
    Deployment-Modus
  • Sandbox per Run
    Isolation
  • Agent-Level
    Beobachtbarkeit
  • Multi-Tenant
    Architektur

Warum KI-Agenten in Produktion anders schwierig sind

KI-Agenten unterscheiden sich von normaler Software in mindestens vier Punkten gleichzeitig: Sie sind nicht-deterministisch, sie verändern echte Systeme über Tool-Calls, sie kosten pro Aufruf echtes Geld, und sie verhalten sich nach jedem Modell-Update potenziell anders. Jede dieser Eigenschaften für sich ist anstrengend. Zusammen bricht das Standard-Software-Engineering, das die meisten Teams betreiben.

Was passiert in der Praxis, wenn ein Software-Team KI-Agenten naiv deployt: Prompt-Änderungen werden ohne Test in Produktion geschoben. Modell-Updates verschlechtern still die Qualität. Tool-Calls eskalieren in Endlosschleifen und produzieren €1.000 Cost-Spikes über Nacht. Halluzinationen erzeugen Production-Bugs, die niemand reproduzieren kann. Das ist nicht 'KI ist halt unzuverlässig' — das ist fehlende Engineering-Disziplin.

Tavora gibt Software-Teams die Disziplin, ohne dass sie sie selbst von Grund auf bauen müssen. Die Plattform hostet Ihre Agenten in Sandboxes, läuft Eval-Suites bei jeder Änderung, gated Deployments hinter messbaren Qualitätskriterien, und liefert Beobachtbarkeit auf Agent- und Tool-Call-Ebene.

Wie Tavora gebaut ist

Das Kern-Design-Prinzip von Tavora: Ein Agent ist nicht einfach 'ein LLM-Aufruf mit Tools'. Ein Agent ist ein versionierter Software-Artefakt, der durch eine CI/CD-Pipeline läuft, gegen Evals gemessen wird, und nur in Produktion landet, wenn er bestimmte Qualitätskriterien erfüllt. Wie Software-Engineering — nur eben für nicht-deterministische Systeme.

Technisch: Jeder Agent-Run läuft in einer isolierten Sandbox mit klaren Ressourcen-Limits. Tool-Calls werden zentral logged, mit voller Tracability vom User-Request bis zum letzten LLM-Call. Eval-Suites werden gegen einen versionierten Test-Datensatz ausgeführt, mit Diff-Reports zwischen Versionen. Multi-Tenant von Anfang an, mit klaren Isolations-Garantien.

Was wir gelernt haben: Beobachtbarkeit ist nicht Nice-to-Have, sie ist die Voraussetzung für jedes ernsthafte Agent-Deployment. Wer einen Production-Bug bei einem KI-Agenten ohne strukturierte Logs debuggen muss, lernt das nach dem ersten Vorfall.

Was bei Agent-Deployment kontrolliert sein muss

01

Eval-Gates vor jedem Deploy

Kein Agent geht in Produktion ohne dass eine versionierte Eval-Suite gegen ihn läuft. Regressionen werden im PR sichtbar, nicht erst beim User.

02

Sandbox-Isolation pro Run

Jeder Agent-Run läuft in einer eigenen Sandbox mit Ressourcen-Limits. Eskalierende Tool-Calls können kein anderes Tenant erreichen, kein Cost-Spike kann unbeobachtet wachsen.

03

Tool-Call-Tracing end-to-end

Vom User-Request bis zum letzten LLM-Call ist jeder Schritt loggbar und reproduzierbar. Ein Production-Bug ist debugbar, nicht magisch.

04

Versionierte Prompts wie Code

Prompts leben in Git, durchlaufen Code-Review, werden gegen Evals gemessen. Sie sind kein 'mal eben in der UI ändern'-Artefakt.

05

Cost-Tracking auf Agent-Ebene

Sie sehen, welcher Agent welche Kosten produziert, mit welchem Modell, in welchem Tenant. Cost-Anomalien werden früh sichtbar, nicht erst auf der Monatsrechnung.

06

Modell-agnostische Pipeline

Modell-Wechsel sind eine Konfigurations-Änderung, kein Re-Build. Wenn ein günstigeres Modell die Eval-Suite besteht, schalten Sie um — ohne Code-Änderung.

Technologie-Stack

Runtime
TypeScript Node.js Sandboxing
Persistenz
Postgres Object Storage Multi-Tenant
Evals & CI
Custom Eval Engine GitHub Actions Diff-Reports
Beobachtbarkeit
OpenTelemetry Structured Logs Tracing

Was Software-Teams aus Tavora für ihre eigenen Agenten lernen

01

Behandeln Sie Prompts wie Code, nicht wie Konfiguration

Prompts gehören in Git, in PRs, in Code-Review. Wer Prompts in einer UI editiert, macht denselben Fehler wie das Editieren von Production-Code in einer Web-Konsole.

02

Evals sind Tests, nicht Demos

Eine Eval-Suite muss in CI laufen und Regressionen blockieren. Eine 'Eval-Tabelle' im Notion ist keine Eval-Suite — sie ist ein gut gemeintes Dokument.

03

Cost-Spikes sind ein Sicherheits-Thema

Ein Tool-Call, der in einer Endlosschleife endet, kann über Nacht €10.000 kosten. Cost-Limits pro Run, pro Agent, pro Tenant sind kein Optimierungs-Detail — sie sind eine Sicherheits-Anforderung.

Lassen Sie uns 30 Minuten reden.

Ich höre zu, stelle Fragen und sage offen, ob und wie ich helfen kann.

Kostenloses Erstgespräch