Was wir im Oktober 2026 veröffentlicht haben

Im September sind connic Voice, der Playground und die Browser-Tools erschienen. Im Oktober haben Agenten ein Frontend und einen Ort für ihre Dateien bekommen. connic Apps hostet die Web-Apps, mit denen Menschen Agenten nutzen, und connic Dateien bewahrt auf, was Agenten von einem Run zum nächsten erzeugen. Verbindungen lassen sich jetzt im Code neben den Agenten deklarieren, die sie starten. Run-Drains leiten jeden abgeschlossenen Run samt Trace an Monitoring-Tools weiter. Die Browser-Tools lesen Seiten, führen Skripte aus, zeichnen Netzwerkverkehr auf und melden sich mit Passkeys an. Neu im Katalog der verwalteten KI-Modelle sind unter anderem GPT-6, Claude 5.5 und Gemini 4 Argon.

Frontends für Agenten mit connic Apps

connic Apps hostet die Oberflächen, über die Menschen mit Agenten arbeiten: einen Chat auf der Website, ein Postfach für Freigaben, ein Kundenportal. Jede App besteht aus einer YAML-Datei in apps/ und einem Ordner mit ihren Quellen. Jedes Deployment baut sie zusammen mit den Agenten, jedes Environment stellt sie unter einer eigenen connic.app-Adresse bereit, und ein Rollback holt das ältere Frontend mit den älteren Agenten zurück. Geeignet sind Frameworks, die statische Dateien bauen, etwa Vite mit React oder Vue, Angular, Astro, SvelteKit und Nuxt.

name: Support portal
build:
  command: npm run build
  output: dist
auth:
  mode: connic
connectors:
  - portal-chat
access:
  database:
    tickets:
      read: doc.author_id == user.id
      insert: true
      set:
        author_id: user.id

Apps rufen Agenten über synchrone Webhook- oder WebSocket-Connectors mit apps_only: true auf. Der Code der App enthält deshalb keinen API-Schlüssel. Runs, die eine App startet, tragen ID, E-Mail-Adresse, Name und Gruppen des Besuchers im Run-Kontext. Apps lassen sich auch unter einer Custom Domain erreichen und sind im Pro- und Enterprise-Tarif enthalten.

Die Ankündigung von connic Apps zeigt Beispiel-Apps, die Apps-Dokumentation beschreibt jede Einstellung.

Dauerhafter Speicher mit connic Dateien

connic Dateien gibt jedem Environment einen Ordnerbaum, in dem Agenten Dateien über Runs hinweg aufbewahren. Ein Agent speichert einen Bericht oder einen Browser-Download, und ein späterer Run oder ein anderer Agent greift wieder darauf zu. Fünf Datei-Tools arbeiten mit dem Baum: file_list, file_read, file_write, file_update und file_delete. Eigene Tools importieren dieselben Funktionen aus connic.tools. Dateiinhalte sind im Ruhezustand verschlüsselt, mit einem eigenen Schlüssel für jedes Environment.

Ohne weitere Konfiguration kann ein Agent den ganzen Baum nutzen. Ein Block files beschränkt ihn auf bestimmte Ordner, verbietet Schreiben oder Löschen oder begrenzt ihn auf die Dateien seiner aktuellen Session:

session:
  key: input.customer_id

files:
  session_only: true          # only files written in this customer's session
  prevent_delete: true
  folders:
    cases: {}
    templates:
      session_only: false     # shared by every session
      prevent_write: true

Die Ankündigung von connic Dateien enthält ein Beispiel mit Rechnungen, die Dokumentation zu Dateien nennt Limits und Abrechnung.

Verbindungen im Code deklarieren

Verbindungen lassen sich jetzt in connectors/<key>.yaml deklarieren, direkt neben den Agenten, die sie starten. Sobald ein Deployment aktiviert wird, legt connic die Verbindungen des Environments an, aktualisiert sie oder legt sie still, sodass sie den Dateien entsprechen. Ein Rollback stellt die Verbindungen des älteren Deployments wieder her. Bis auf Slack lässt sich jeder Verbindungstyp so deklarieren.

type: kafka
mode: inbound
name: Order events                # optional, defaults to the file name
connection: orders-kafka-staging  # saved Connection, by name or ID; it holds the bridge too
config:                           # connector settings, as in the REST API and connic MCP
  topic: ${ORDER_EVENTS_TOPIC}
agents:
  - order-processor
  - name: audit-logger
    files_required: true
environments:                     # omit to deploy to every environment
  Staging: {}
  Prod:
    connection: orders-kafka-prod   # another Connection, with the production bridge
    config:
      group_id: connic-orders-prod

environments überschreibt Einstellungen pro Environment, und ${NAME} liest beim Start des Deployments eine Variable des Ziel-Environments. Secrets bleiben so aus den Dateien heraus. Das Deployment-Log nennt jede Änderung an Verbindungen, und vor einem Rollback zeigt der Aktivierungsdialog, welche Verbindungen angelegt, geändert, zurückgeholt oder stillgelegt werden. Eine Verbindung, die der Code nicht mehr deklariert, wird pausiert und behält URL, Secrets und Run-Historie. connic lint prüft die Verbindungsdateien vor dem Upload.

Die Dokumentation zu Verbindungen im Code beschreibt Overrides, Variablen und fehlgeschlagene Änderungen. Veraltete API-Felder funktionieren noch bis zum 30. April 2027, wie die REST-API-Referenz erklärt.

Run-Drains und OpenTelemetry-Export

Run-Drains leiten Agenten-Runs an die Monitoring-Tools weiter, die ein Team bereits nutzt. Ein Drain sendet für jeden abgeschlossenen Run ein Ereignis mit Input, Output und Kontext, jeden Span seines Traces und einmal pro Minute einen Health-Snapshot jedes Environments. Nichts davon wird gekürzt.

Run-Drains werden auf der Seite Agent Runs unter More actions → Run Drains eingerichtet. Wie Log- und Audit-Drains sind sie Teil des Enterprise-Tarifs.

Die Dokumentation zu Drains beschreibt die Ereignisformate und jeden Channel.

Browser-Tools lesen Seiten, führen Skripte aus und melden sich an

Zu den Browser-Tools aus dem September sind fünf neue hinzugekommen. web_browser_read liefert die gerenderte Seite als Markdown, auch Inhalte hinter einem Login. web_browser_eval führt JavaScript auf der Seite aus, direkt angegeben oder als Skript aus connic Dateien. web_browser_console liefert Konsolenmeldungen und Seitenfehler, web_browser_network zeichnet Anfragen auf und speichert sie bei Bedarf als HAR-Datei, und web_browser_pdf speichert die Seite als PDF. web_browser_act kann jetzt mit der Maus über Elemente fahren, Checkboxen setzen, ein Element in den sichtbaren Bereich scrollen und auf Text, eine URL, einen Selektor oder ruhendes Netzwerk warten. Screenshots erfassen auf Wunsch die ganze Seite.

from connic.tools import web_browser_eval

await web_browser_eval(
    "[...document.querySelectorAll('h2')].map(h => h.textContent.trim())"
)

await web_browser_eval(
    script_path="scripts/collect-rows.js", save_to="exports/rows.json"
)

Außerdem können sich Agenten auf Websites anmelden, die Passkeys akzeptieren. Passkeys werden pro Environment in den Projekteinstellungen verwaltet: Ein neuer Passkey wird gespeichert, sobald der Browser des Agenten zum ersten Mal einen auf seiner Domain registriert, oder ein vorhandener Passkey wird importiert. Der Agent listet die Passkeys auf, die er nutzen darf:

tools:
  - web_browser_*

browser:
  passkeys:
    - supplier-portal

Die Referenz der Web-Tools dokumentiert jedes Browser-Tool. Unser Leitfaden zur Browser-Automatisierung behandelt jetzt auch Standort, Zeitzone und das Öffnen des Browsers aus Middleware.

MCP-Server pro Endnutzer

Manche MCP-Server handeln im Namen einer Person und zeigen jedem Nutzer nur seine eigenen Daten. Ein Agent kann einen solchen Server jetzt mit dem Konto des jeweiligen Endnutzers aufrufen. Der Nutzer meldet sich einmal über einen Link an, connic speichert seinen Zugang, und jeder spätere Run für diesen Nutzer verwendet ihn. Ein Kontextwert, den Middleware setzt, etwa context.user_id, bestimmt den Nutzer. Für Nutzer, die sich noch nicht angemeldet haben, lassen Runs den Server weg.

mcp_servers:
  - name: crm
    url: https://crm.example.com/mcp
    oauth:
      app: crm                # sign-in app, set up per environment in Project Settings
      user: context.user_id   # set by middleware for every run
      connect_tool: true      # adds connect_crm for conversational agents

Ein Chat-Agent kann den Anmeldelink über das generierte Tool connect_crm selbst verschicken. Andere Systeme erzeugen Links über die REST API oder connic MCP.

MCP-Server akzeptieren außerdem condition, das einen Server nur anbindet, wenn ein Ausdruck über context oder input zutrifft, und optional: true, das einen nicht erreichbaren Server überspringt, statt den Run scheitern zu lassen. Tool-Hooks gelten jetzt auch für MCP-Tools: before kann Argumente umschreiben oder den Aufruf stoppen, after kann das Ergebnis kürzen oder ersetzen, bevor das Modell es sieht.

Die MCP-Dokumentation beschreibt die Anmeldung pro Nutzer und bedingte Server. Die Referenz der Tool-Hooks zeigt Hooks für MCP-Tools.

Anrufweiterleitung und Fortschritt im Live-Chat

Voice-Agenten können einen Anruf jetzt an einen Menschen übergeben. Ein Tool löst TransferCall mit einer Rufnummer im E.164-Format aus. Was der Agent gerade sagt, wird noch zu Ende gesprochen, dann wird der Anrufer verbunden. Die erlaubten Nummern stehen unter Transfer numbers in der Verbindung Twilio Voice oder Telnyx Voice. Eine Fallback number übernimmt den Anruf, wenn der Run fehlschlägt oder der Anruf nicht weitergehen kann.

from connic import TransferCall


def transfer_to_sales(context: dict) -> str:
    """Transfer the caller to the sales team."""
    raise TransferCall("+4930123456789")

voice_config.keypad ordnet Telefontasten Tools zu. Ein Tastendruck startet sein Tool sofort und ohne Modellaufruf, auch während der Begrüßung. Bis der Agent sprechen kann, hören Anrufer ein Freizeichen, und der Run-Input enthält die Anrufdaten, etwa die Nummer des Anrufers und die gewählte Nummer.

Chats über den WebSocket-Connector können zeigen, woran der Agent gerade arbeitet. Mit progress_events sendet der Connector neben dem Antworttext auch Ereignisse, wenn ein Modellaufruf beginnt, wenn ein Tool-Aufruf beginnt und endet (nur mit dem Namen des Tools) und wenn eine Freigabe wartet oder entschieden ist. Der Gesprächsverlauf übersteht mit session.key auch einen Verbindungsabbruch. Text, der vor einer Pause für eine Freigabe gestreamt wurde, bleibt erhalten, wenn der Run weiterläuft.

Die Voice-Dokumentation beschreibt Weiterleitung und Tasteneingaben. Unser Tutorial zum Streaming-Chat baut Schritt für Schritt einen Chat mit Fortschrittsereignissen.

Rate Limits und Absenderprüfung für Verbindungen

Verbindungen vom Typ Webhook, WebSocket und MCP können Anfragen jetzt pro Minute begrenzen: insgesamt, pro Client-IP und pro Wert eines Felds im Payload, etwa einer Kunden-ID. Eine Anfrage über dem Limit wird abgelehnt, bevor ein Run startet, und verbraucht kein Projektguthaben.

type: webhook
mode: inbound              # or sync
config:
  require_auth: true
  rate_limit:
    per_ip: 60
agents:
  - order-processor

Webhook-Runs geben die ursprüngliche Anfrage jetzt als context["request"] an Middleware weiter: Methode, Header, Query, Rohdaten des Bodys und den Zeitpunkt, zu dem connic sie empfangen hat. So kann Middleware die Signatur eines Absenders prüfen, etwa GitHubs X-Hub-Signature-256, bevor der Agent läuft. In den Run-Details erscheinen der Body und Header mit Zugangsdaten als [REDACTED].

Die Webhook-Dokumentation enthält Signaturprüfungen für GitHub und Microsoft Teams, die Cron-Dokumentation erklärt den Umgang mit der Sommerzeit.

SharePoint, Zendesk und Suche in der Datenbank

Retrieval hat zwei neue synchronisierte Quellen. Die Quelle SharePoint und OneDrive synchronisiert Dokumentbibliotheken über die eigene App-Registrierung des Unternehmens in Entra ID, beschränkt auf ausgewählte Sites, Bibliotheken, Ordner oder Dateien, die sich seit einem Datum geändert haben. Nach der ersten Synchronisierung werden nur geänderte Dateien erneut übertragen. Aus dem Zendesk Help Center holt eine zweite Quelle die veröffentlichten Artikel, die Übersetzungen eines Artikels jeweils als eigene Einträge.

Retrieval liest außerdem Word-, Excel-, PowerPoint-, OpenDocument-, RTF-, HTML- und E-Mail-Dateien (EML und MSG). Datei-Uploads dürfen bis zu 100 MiB groß sein und bis zu 25 Millionen Zeichen Text enthalten, Text-Uploads bis zu 10 Millionen Zeichen. Ein Datei-Upload über die REST API kann eigene Metadaten mitbringen.

from connic.tools import db_find

# Pickup points within 25 km, nearest first
# (each document has "location": {"lat": 48.15, "lng": 11.58})
result = await db_find("pickup_points", filter={
    "location": {"$near": {"lat": 48.137, "lng": 11.575, "maxDistance": 25000}},
})
nearest = result["documents"][0]
nearest["_distance"]          # meters from the point

Die Retrieval-Dokumentation beschreibt die Einrichtung von SharePoint, die Datenbank-Dokumentation Importe und durchsuchbare Felder.

Token-Kosten pro Kunde und in einer Währung

Token-Kosten lassen sich jetzt nach jedem Wert im Run-Kontext gruppieren. Steht eine customer_id im Run-Kontext, zeigt der Tab By Context auf der Seite Token Usage, was jeder Kunde pro Tag kostet. Dashboard-Widgets und die Budget-API gruppieren die Kosten genauso. Unser Leitfaden zu Token-Kosten pro Kunde zeigt die Einrichtung.

Projekte mit Modellpreisen in Euro und in Dollar können alle Token-Kosten in einer Währung anzeigen. Cost Display unter Project Settings → Token Pricing rechnet die Beträge mit den täglichen Referenzkursen der Europäischen Zentralbank um und kennzeichnet sie mit ≈.

Die Dokumentation zur Nutzung erklärt, wie Token-Kosten berechnet werden.

Neue verwaltete KI-Modelle

Im Oktober sind 20 Modelle zum Katalog der verwalteten KI-Modelle hinzugekommen. Jedes hat eine Modell-ID wie connic/claude-sonnet-5.5 und wird über das Projektguthaben abgerechnet, ohne eigenes Konto beim Anbieter.

Verwaltete Modelle wie Claude 5 und 5.5, Gemini 4 Argon, die Gemini-Flash-Modelle und GPT-5.6 lesen angehängte PDFs jetzt direkt. Lehnt ein Modell einen angehängten Dateityp ab, wechselt der Run direkt zum Fallback-Modell. Das Deployment-Log warnt, wenn ein Fallback-Modell weniger Dateitypen annimmt als das primäre Modell.

Der Katalog der verwalteten KI-Modelle nennt aktuelle Preise und die Dateitypen jedes Modells. Unsere Artikel zu Mistral Large 4 und Kolibri 1 stellen zwei der neuen Modelle ausführlich vor.

Weitere Verbesserungen

• •Runs enden auf ihrem Deployment: Ein neues Deployment unterbricht laufende Agenten nicht mehr. Jeder Run endet auf dem Deployment, auf dem er gestartet ist, wartende Runs starten auf dem neuen. Schlägt ein neues Deployment nach dem Deploy-Schritt fehl, bleibt das vorherige aktiv. Deployment-Dokumentation
• •Einrichtung mit einem Coding-Agenten: Neue Projekte beginnen mit einem Assistenten, der durch die Anbindung eines Coding-Agenten wie Claude Code, Codex oder Cursor und die Bereitstellung des ersten Agenten führt, gefolgt von einer Checkliste für den Produktivbetrieb. connic login gibt einen Link und einen Bestätigungscode aus und wartet, bis der Login im Browser freigegeben ist. So können auch Coding-Agenten den Befehl ausführen. CLI-Referenz
• •Steuerung zur Laufzeit: Der Middleware-Hook cleanup läuft nach jedem abgeschlossenen, fehlgeschlagenen oder abgebrochenen Run, etwa um eine Sperre aus before freizugeben. retry_options.attempt_timeout begrenzt eine einzelne Modellanfrage, standardmäßig auf 120 Sekunden. session.files: false lässt Dateien aus früheren Runs in einem fortgesetzten Gespräch weg. Middleware-Dokumentation
• •Größere Deployments: Ein Deployment darf bis zu 50 MB groß sein, ohne eigenes Limit für Code. connic lint und connic test prüfen Testsuites vor dem Upload auf Schemafehler und unbekannte Agenten.
• •Ansichten im Dashboard: Die Seite Agents bietet eine Ordner- und eine flache Ansicht, eine Suche und Filter nach Typ und Status. Wartende Runs zeigen, warum sie warten, etwa wegen eines Zeitplans, einer Concurrency-Regel oder eines Budgetlimits. Verbindungs-Logs lassen sich durchsuchen, nach Level filtern und bis zu älteren Einträgen zurückscrollen.
• •Guardrails: Der PII-Guardrail erkennt keine Telefonnummern mehr innerhalb von Kartennummern, IBANs oder IP-Adressen, und die Erkennung von Prompt Injection findet mehr Varianten, Anweisungen auszuhebeln. Blockieren die Zugriffseinstellungen eines Agenten einen Aufruf eines Datenbank- oder Retrieval-Tools, erscheint eine Warnung in den Run-Logs. Integrierte Guardrails
• •Große Tool-Ergebnisse: Screenshots und andere Dateien aus Tool-Ergebnissen landen nicht mehr im Session-Verlauf, und ein Tool-Ergebnis, das zu groß zum Speichern ist, lässt den Run nicht mehr scheitern.
• •Private Netzwerke: connic Bridge überträgt große Anfragen und Antworten jetzt auch dann, wenn eine Seite langsam liest, und leitet asynchrone Clients wie httpx und aiohttp weiter. E-Mail-Verbindungen prüfen die Zertifikate des Mailservers und akzeptieren ein Zertifikat einer privaten CA am Kontozugang. Bridge-Dokumentation
• •API und connic MCP: REST-Antworten liefern Verbindungseinstellungen und Trace-Metadaten als Objekte statt als JSON-Strings, und die OpenAPI-Spezifikation beschreibt die Felder und die Berechtigung, die jeder Endpunkt verlangt. connic MCP hat Tools erhalten, die einzelne Freigaben, A/B-Tests, Channels, Budgetwarnungen, Kontozugänge und Dateien lesen. REST-API-Referenz
• •Anmeldung und Support: Die Seiten für Anmeldung und Registrierung haben ein neues Design, und die Registrierung richtet standardmäßig einen Passkey ein, ein Passwort ist einen Klick entfernt. Fragen aus dem neuen Support-Chat auf der Website und im Dashboard werden im Chat und per E-Mail beantwortet.