Zum Hauptinhalt springen
Connic

Entwickle Agenten.
Connic übernimmt den Betrieb.

Versioniere die Betriebseinstellungen zusammen mit deinem Agent-Code in Git. Connic übernimmt Builds und Deployments, steuert parallele Ausführungen und Wiederholungen und stellt Ausführungsprotokolle sowie Rollbacks bereit.

Starte kostenlosDeployment-Leitfaden ansehen
Deployment-Dokumentation lesen
  1. 1

    Package

  2. 2

    Build

  3. 3

    Test

  4. 4

    Activate

  • customer_acme
    tool: ledger.lookup
    running
  • customer_acme
    waits for the active key
    queued
  • customer_north
    waits for the agent-wide slot
    queued

Der Agent ist nur ein kleiner Teil des Systems, das ihn ausführt.

Wenn Modellaufrufe und Python-Tools funktionieren, fehlen für den Produktivbetrieb oft noch Builds, Tests vor der Veröffentlichung, Regeln für parallele Ausführungen, Wiederholungen, Sessions und Rollbacks. Connic verwaltet diese Funktionen zusammen mit den Runs und Deployments.

Release
Image erstellen, erforderliche Tests ausführen und eine bereitstellbare Version aktivieren
Ausführen
Iterationen, Zeit, Retries und gleichzeitige Runs begrenzen
Koordinieren
Weitere Runs mit demselben Schlüssel in eine Queue stellen oder verwerfen
Wiederherstellen
Die aktive Version verarbeitet weiter Anfragen; ein früheres Deployment lässt sich erneut aktivieren

Lege fest, wie deine Agenten ausgeführt werden

Konfiguriere Ausführungslimits und parallele Verarbeitung je Schlüssel direkt in der Agent-Datei. So bleiben die Einstellungen versioniert und im Review nachvollziehbar.

agents/invoice-processor.yaml
version: "1.0"

name: invoice-processor
type: llm
model: connic/gpt-5.6-sol
description: "Validates and routes incoming invoices."
system_prompt: "Validate the invoice, look up its ledger state, then assign its review queue."

tools:
  - ledger.lookup
  - routing.assign_queue

max_concurrent_runs: 1
max_iterations: 40
timeout: 120

retry_options:
  attempts: 5
  initial_delay: 10
  max_delay: 60

concurrency:
  key: "data.customer_id"
  on_conflict: queue
  • customer_acme
    tool: ledger.lookup
    running
  • customer_acme
    waits for the active key
    queued
  • customer_north
    waits for the agent-wide slot
    queued
  • customer_orbit
    waits for the agent-wide slot
    queued
  • customer_south
    waits for the agent-wide slot
    queued
Different keys can run in parallel when max_concurrent_runs is above 1. The setting on_conflict: drop cancels duplicate work instead of queueing it.

  • Loop begrenzen

    Gleichzeitige Runs, LLM-Iterationen und die gesamte verstrichene Zeit je Agent begrenzen.

  • Fehlgeschlagene Operation wiederholen

    Modellanfragen werden am einzelnen Aufruf wiederholt; die Runtime spielt nicht den gesamten LLM-Agenten erneut ab.

  • Runs mit demselben Schlüssel nacheinander ausführen

    Verhindere parallele Runs mit demselben Schlüssel. Das übergreifende Limit gleichzeitiger Runs je Agent gilt weiterhin.

Prüfe neue Versionen, bevor sie aktiv werden

Nutze Git oder die CLI für dein Deployment. Connic führt vorhandene Tests aus und aktiviert nur eine Version, die bereit für den Betrieb ist. Fehlgeschlagene Versuche bleiben nachvollziehbar. Bei einem manuellen Deployment lassen sich Tests über die CLI oder im Dashboard überspringen.

  1. 1

    Package

    Agent spec + Python

  2. 2

    Build

    Dependencies installed

  3. 3

    Test

    Deploy gate passed

  4. 4

    Activate

    Traffic moved

Neues Deployment fehlgeschlagen

Ein Fehler im Build oder Deploy Gate markiert dieses Deployment als fehlgeschlagen.

Die aktive Version verarbeitet weiter Anfragen

Der Traffic bleibt ohne Unterbrechung auf dem zuletzt aktiven Deployment.

Lege fest, was bei Fehlern passiert

Konfiguriere, wie Connic auf Anbieterfehler, konkurrierende Anfragen, erreichte Iterationslimits und fehlgeschlagene Deployments reagiert.

Runtime-Reaktionen auf häufige Fehler
FehlerRuntime-Reaktion
Anfrage an das KI-Modell fehlgeschlagenNach einer Wartezeit erneut versuchen oder zu fallback_model wechseln und die dafür konfigurierte Anzahl von Versuchen nutzen.
Weiterer Run mit demselben SchlüsselDen neuen Run entsprechend der Concurrency-Regel des Agenten in die Queue stellen oder verwerfen.
IterationslimitDen LLM Loop stoppen, statt wiederholte Tool-Aufrufe unbegrenzt zuzulassen.
Release fehlgeschlagenDas aktive Deployment verarbeitet weiterhin Anfragen. Die Logs des fehlgeschlagenen Builds bleiben zur Prüfung erhalten.

  • Rollback ohne erneuten Build

    Ein früheres erfolgreiches Deployment aktivieren und den Traffic zurück zu seinem bestehenden Container leiten.

  • Sessions bleiben über Releases hinweg bestehen

    Ein aktivierter Session-Verlauf bleibt über Neustarts und Deployments hinweg erhalten.

  • Jeden Run vollständig tracen

    Die aktive Runtime erfasst Modellaufrufe, Tools, Middleware, Guardrails und Orchestrierung unter dem Run, der sie ausgeführt hat.

Limits, Wiederholungen, parallele Ausführungen, Sessions und Deployments sind ausführlich dokumentiert. Ausführungseinstellungen ansehen oder den Deployment-Ablauf nachvollziehen.

Entdecke weitere Features

Environments

Konfiguration, Secrets und Releases trennen.

Testing

Jedes Deployment mit realen Test Cases absichern.

Observability

Jeden Schritt jedes Runs nachvollziehen.

Verbindungen

Ereignisse aus Produktivsystemen in die Runtime bringen.

Guardrails

Prüfungen vor und nach der Ausführung durchsetzen.

Dev Server

Änderungen mit Hot Reload in der Cloud testen.

Häufig gestellte Fragen

Bei einem mit Git verbundenen Projekt startet ein Push ein Deployment in der Umgebung, die dem Branch zugeordnet ist. Ein Projekt ohne Git-Verbindung kann Deployments über die Connic CLI starten. Connic stellt die Agent-Dateien zu einem Deployment-Bundle zusammen, baut den Container und führt die vollständige Suite aus, wenn tests/ vorhanden ist. Bei manuellen Deployments lässt sich die Testphase mit --skip-tests in der CLI oder mit Deploy & skip tests im Dashboard überspringen; automatische Git-Deployments führen sie immer aus. Anschließend kann das neue Deployment aktiviert werden, wenn es bereit für den Betrieb ist.

Das neue Deployment erhält den Status Failed. Das aktive Deployment verarbeitet weiterhin Anfragen. Die Build-Logs findest du auf der Detailseite des fehlgeschlagenen Deployments.

Ja. Im Tab Deployments lässt sich ein früheres erfolgreiches Deployment aktivieren. Der Traffic wird an dessen bestehenden Container geleitet, daher ist kein neuer Build erforderlich.

Nicht bei einem LLM-Agenten. Modellanfragen werden am fehlgeschlagenen Aufruf wiederholt, während fehlgeschlagene Tool-Aufrufe an den Agenten zurückgemeldet werden. Tool- und Sequential-Agenten behalten Retries auf Operationsebene; rerun_middleware gilt nur für diese Retries.

Der Concurrency Key wird aus den Eingabedaten des Triggers gelesen. Für denselben Schlüssel ist immer nur ein Run aktiv. Weitere Runs mit diesem Schlüssel warten in einer Queue oder werden verworfen. Runs mit unterschiedlichen Schlüsseln können parallel laufen, begrenzt durch max_concurrent_runs und den Tarif des Projekts.

Ja, wenn der Session-Verlauf aktiviert ist. Er bleibt über Anfragen, Neustarts und Deployments hinweg verfügbar. Die Session endet, wenn die konfigurierte Zeit ohne neue Aktivität abläuft oder sie gelöscht wird.