Zum Hauptinhalt springen
Connic

Was wir im Mai 2026 veröffentlicht haben

Testframework für Agenten, Deployment Gates mit Pull-Request-Tests, detaillierteres Tracing für ausgelöste und untergeordnete Runs, Usage- und Budget-Dashboards, eigene Domains für Verbindungen und Reasoning Effort pro Agenten mit vererbten Standardwerten.

1. Juni 20267 Min. LesezeitAutor: Connic Engineering

Im Mai ging es um Sicherheit vor dem Release. Mit einem neuen Testframework lassen sich Tests für Agenten schreiben und ausführen. Deployment Gates halten ein Deployment zurück, bis alle Tests erfolgreich sind, und Pull-Request-Tests erkennen Regressionen vor dem Merge. Außerdem haben wir das Tracing für ausgelöste und untergeordnete Runs erweitert, Token-Nutzung und Budgets genauer aufgeschlüsselt, Verbindungen um eigene Domains ergänzt und Reasoning Effort pro Agenten mit vererbbaren Projekt-Defaults eingeführt.

Das Testframework für Agenten

Agenten lassen sich jetzt wie jeder andere Code testen. Testfälle werden in einer Datei unter tests/ definiert. Jeder Testfall enthält Input und Assertions; Connic führt ihn gegen die Agenten aus und speichert das Ergebnis.

tests/order-manager.yaml
tests:
  - name: refunds_small_orders
    payload: '{"message": "Refund order A123, $40"}'
    expected_result: output.status == "refunded"
    expected_tool_calls:
      - process_refund

  - name: escalates_large_refunds
    payload: '{"message": "Refund order B456, $500"}'
    expected_result: output.status == "pending_approval"
    expected_child_agents:        # assert on a triggered child agent
      manager-approval:
        expected_triggered: 1
  • Überall ausführen: Ad-hoc-Test-Runs im Dashboard starten oder während der Entwicklung interaktiv mit connic dev testen
  • Ausgelöste Agenten prüfen: Assertions können statt nur der Response auf oberster Ebene auch die von einem Run ausgelösten Child-Agenten prüfen
  • Coverage Reports: Erkennen, welche Agenten und Tools die Tests tatsächlich abdecken
  • Teilmenge ausführen: Mit connic test --filter nur passende Testfälle starten

Den vollständigen Ablauf erklärt unser Leitfaden zum Testframework.

Deployment Gates und Pull-Request-Tests

Deployment Gates binden die Testergebnisse in den Release-Ablauf ein: Ein Deployment wartet, bis seine Testsuite erfolgreich ist. Die Konfiguration erfolgt pro Environment, damit Staging und Produktivbetrieb unabhängig voneinander abgesichert werden können.

Connic führt die Tests außerdem bei jedem Pull Request aus und meldet das Ergebnis als Status-Check zurück, inklusive direktem Link zum Deployment und seinen Run-Traces.

Pull request checks
connic/pr-tests   All tests passed   Details

24 passed, 0 failed.
  • Steuerung pro Environment: Gating pro Environment aktivieren oder deaktivieren und Tests bei Bedarf gegen ein separates Test-Environment ausführen
  • PR Status Checks: Ein einzelner Check connic/pr-tests zeigt Erfolg oder Fehler im Pull Request und verlinkt das zugrunde liegende Deployment
  • Vor der Ausführung eingeplant: Runs des Deployment Gates werden vor dem Deployment eingeplant, sodass ein fehlerhafter Build das Environment nie erreicht

Tracing für ausgelöste und untergeordnete Runs

Wenn ein Agent einen anderen auslöst, ist jetzt die gesamte Kette nachvollziehbar. Ein Child Run öffnet sich in einem Drawer über seinem Parent. Von dort lässt sich die Kette nach oben verfolgen und zwischen Trigger und gestartetem Run wechseln, ohne die Position in der Run History zu verlieren.

  • Stacked Drawers: Child Runs öffnen sich über ihrem Parent und ermöglichen die Navigation nach unten und wieder nach oben in einer Ansicht
  • Verknüpfte Navigation: Jeder ausgelöste Run speichert den auslösenden Run; Inline-Links verbinden beide Richtungen
  • Trigger Source: Eine neue Trigger Source zeigt bei jedem Run sofort, ob er von einer Verbindung, einem anderen Agenten, einem manuellen Run oder einem Deployment Gate stammt

Usage- und Budget-Dashboards

Das Usage-Dashboard zeigt jetzt Token-Verbrauch und Ausgaben pro Agenten neben dem Budget-Reporting. Damit lassen sich Kosten direkt den verursachenden Agenten zuordnen.

Judges unterstützen Filter-Expressions zur präzisen Auswahl der zu evaluierenden Runs:

Judge run selection
context.tier == 'enterprise' and output.priority >= 3
  • Token- und Budget-Metriken: Token-Nutzung und Ausgaben pro Agenten; Agenten ohne Nutzung werden aus Budget-Berichten ausgeschlossen
  • Input Widgets: Dropdowns und Inputs zu einem Dashboard hinzufügen, um alle Widgets gleichzeitig zu filtern
  • Companion Metrics: Einen sekundären Vergleichswert neben der primären Kennzahl eines Widgets anzeigen

Eigene Domains für Verbindungen

Verbindungs-URLs müssen nicht mehr unter einer von Connic gehosteten Adresse liegen. Eine eigene Domain kann auf die Verbindungen verweisen; Connic stellt deren Webhook- und WebSocket-Endpoints dort bereit. So entsprechen die URLs für Partner der Marke des Unternehmens.

Verbindungs-URL
# Vorher: von Connic gehostet
https://connect.connic.co/webhook/3b0a9d…

# Nachher: eigene Domain
https://hooks.acme.com/webhook/3b0a9d…
  • Eigene Domain: Verbindungsendpunkte unter einer eigenen Subdomain bereitstellen
  • Automatische Verifizierung: Domain hinzufügen; Connic prüft DNS, stellt ein Zertifikat aus und zeigt den Fortschritt als Status
  • Pro Verbindung: Einzelne Verbindungen mit der jeweils passenden Domain verbinden

Reasoning Effort und vererbte Standardwerte

Zwei Ergänzungen für die Agenten-Konfiguration: Setze reasoning_effort pro Agenten, um zwischen Latenz und Verarbeitungstiefe abzuwägen, und lege eine _defaults.yaml im Verzeichnis agents/ ab, um gemeinsame Konfiguration einmal festzulegen.

agents/_defaults.yaml
# Inherited by every agent in the project
reasoning_effort: medium
timeout: 120

Jeder Agent übernimmt die Defaults und überschreibt nur das Nötige. Ein Research-Agent kann dadurch reasoning_effort: high anfordern, ohne die übrigen Projekt-Settings zu wiederholen.

Weitere Verbesserungen

  • Wiederverwendbare Verbindungen: Eine Verbindung für die zentrale Credential-Verwaltung einmal definieren und aus beliebigen Agenten oder Verbindungen referenzieren, statt Secrets zu wiederholen
  • Conditional Upserts: Das neue Tool db_upsert fügt ein Dokument in einem Call ein oder aktualisiert es; Retrieval-Abfragen unterstützen jetzt Metadatenfilter
  • Authentifizierte Verbindungen: Die neue Option require_auth schützt Inbound-Webhook- und WebSocket-Verbindungen
  • MCP-Header-Kontext: Werte aus dem Run-Kontext für Authentifizierung und Routing in die MCP-Server-Header jeder Anfrage einsetzen
  • Klarere Timeouts: Detailliertere Timeout- und Abbruchmeldungen zeigen bei einem gestoppten Run den genauen Grund
  • Redirects folgen: Das Tool web_read_page kann Redirects jetzt bis zur finalen URL folgen

Mehr aus dem Blog

Changelog

Was wir im Juli 2026 veröffentlicht haben

30 EU-gehostete Connic KI-Modelle, zentrales Prepaid-Projektguthaben, Marketplace, Tests für Human Approvals und Lifecycle Mocks, Retries ohne erneute Ausführung des Agenten, Kontextkomprimierung, automatische Bridge-Routen, A/B Confidence Mode und KI-Governance für den EU AI Act.

1. August 20268 Min. Lesezeit
Changelog

Was wir im Juni 2026 veröffentlicht haben

Anpassbare Permission Groups, teilbare Dashboards mit Zugriffskontrollen, Channels und Drains für Benachrichtigungen und Logs, präzisere Guardrails gegen Prompt Injection und Data Exfiltration, KI-gestützte Filter sowie Deployments, die laufende Runs vor dem Wechsel abschließen.

1. Juli 20267 Min. Lesezeit
Changelog

Was wir im April 2026 veröffentlicht haben

Human-in-the-Loop Approvals, Bridge für Custom Tools und private Services, Tool Hooks, Discoverable Tools, KI-Dashboard-Builder, eigene OpenAI-kompatible Provider und Live-Logs aus Anwendungscode.

3. Mai 20267 Min. Lesezeit
Changelog

Was wir im Februar 2026 veröffentlicht haben

Managed Database, Template-Bibliothek, Evaluation Judges, Telegram-Verbindung, Lesen von Webseiten, persistente Sessions, Conditional Tools und Concurrency Rules.

1. März 20266 Min. Lesezeit
Changelog

Was wir im Januar 2026 veröffentlicht haben

Eigene Observability-Dashboards mit Drag-and-drop-Widgets, KI-Modellpreise zur Kostenkontrolle, überarbeitete Verbindungs- und Runs-UI sowie Unterstützung für llms.txt.

10. Februar 20265 Min. Lesezeit
Changelog

Was wir im Dezember 2025 veröffentlicht haben

Stripe-Verbindung mit Webhook-Signaturprüfung, E-Mail-Verbindung mit regelmäßiger IMAP-Abfrage und Anhängen sowie Verbesserungen an der Dashboard-UI.

2. Januar 20264 Min. Lesezeit
Changelog

Was wir im November 2025 veröffentlicht haben

MCP-Verbindung für Agenten als Tools, Postgres LISTEN/NOTIFY, S3-Datei-Uploads, SQS-Message-Queues, Verbindungslogs und eine einheitliche Oberfläche.

2. Dezember 20255 Min. Lesezeit
Changelog

Was wir im Oktober 2025 veröffentlicht haben

Wir bieten 10 Deployment-Regionen auf 5 Kontinenten; vordefinierte Tools wie trigger_agent, retrieval_query und web_search lassen sich in Python-Code importieren.

3. November 20254 Min. Lesezeit
Changelog

Was wir im September 2025 veröffentlicht haben

Vollständige Audit Logs mit Vorher-Nachher-Diffs, eine wählbare Datenresidenzregion, verteilte Rate Limits für Verbindungen und eine detaillierte Kostenaufschlüsselung im Billing.

1. Oktober 20254 Min. Lesezeit