connic Apps: Frontends für deine KI-Agenten hosten

Ab heute gibt es connic Apps: Hosting für die Frontends von KI-Agenten. Ein Chatfenster, ein Posteingang für Freigaben oder ein Kundenportal liegt jetzt im selben Projekt wie die Agenten dahinter, geht mit demselben Deployment live und kann Personen anmelden, bevor die erste Datei lädt.

Ein Projekt für die Agenten und ihr Frontend

Früher oder später braucht ein Agent eine Oberfläche, mit der Menschen arbeiten: einen Chat auf einer Website, einen Posteingang, in dem jemand freigibt, was der Agent tun will, ein Portal, in dem Kunden Dokumente hochladen und das Ergebnis verfolgen. Bisher lag diese Oberfläche außerhalb von connic. Sie brauchte eigenes Hosting, ein Backend, das API-Schlüssel vom Browser fernhielt, einen Login und eine eigene Deployment-Pipeline, die leicht aus dem Takt mit den Agenten geriet.

Mit Apps zieht das Frontend ins Projekt. Es geht mit demselben Deployment live wie die Agenten, bekommt im Staging und in der Produktivumgebung je eine eigene URL und lässt sich zusammen mit den Agenten, die es aufruft, per Rollback zurücksetzen. Ein connic-Projekt enthält damit die Agenten, die Connectors, die sie starten, die Daten, die sie speichern, und die Oberfläche, mit der Menschen arbeiten.

Was du mit Apps bauen kannst

Eine App hat dein eigenes Design und entsteht mit dem Framework, das dein Team ohnehin nutzt. Daten und Antworten kommen von den Agenten und dem Speicher im selben Projekt. Die Mockups unten zeigen drei Apps für fiktive Unternehmen.

Ein Schadenportal für eine Versicherung

Versicherte melden einen Wasserschaden, laden Fotos und die Reparaturrechnung hoch und verfolgen den Fall, während ein Agent ihn bewertet. Sie melden sich mit dem Kundenlogin der Versicherung an, und jede Person sieht nur ihre eigenen Schadensmeldungen.

Vertragsprüfung für eine Rechtsabteilung

Juristinnen und Juristen laden einen Vertrag hoch und bekommen Befunde pro Klausel, nach Risiko bewertet und in der Datenbank gespeichert. Rückfragen gehen in einem Chat neben dem Dokument an den Agenten.

Eine Ops-Konsole für die Agenten selbst

Das Ops-Team sieht Runs, Fehler und offene Freigaben aller Agenten und bricht hängende Runs ab. Die App liest die Run-Statistik der Umgebung über die Daten-API. Das Team meldet sich mit dem Firmen-Login an und braucht kein connic-Konto.

Eine App neben den Agenten anlegen

Jede App besteht aus einer YAML-Datei in apps/ und einem Ordner mit ihrem Quellcode. Der Dateiname ist der Key der App: apps/portal.yaml baut aus apps/portal/.

my-agent-project/
├── agents/
│   └── support.yaml
├── connectors/
│   └── portal-chat.yaml
└── apps/
    ├── portal.yaml          # Einstellungen der App; der Dateiname ist ihr Key
    └── portal/              # Quellcode der App
        ├── package.json
        ├── package-lock.json
        └── src/

Vite mit React, Vue, Svelte oder Solid funktioniert, ebenso Angular, Astro, SvelteKit, Nuxt und andere Frameworks, die statische Dateien erzeugen. Bei jedem Deployment installiert connic die Abhängigkeiten aus dem Lockfile, führt den Build-Befehl aus und liefert das Ergebnis aus. Server-Rendering und API-Routen laufen nicht; diese Arbeit übernehmen Agenten und die Daten-API.

In der App-Datei steht, wie die App gebaut wird, wer sie öffnen darf, welche Agenten sie aufrufen kann und welche Daten sie verwenden darf:

name: Supportportal
build:
  command: npm run build
  output: dist
auth:
  mode: oidc
  issuer: ${PORTAL_ISSUER}
  client_id: ${PORTAL_CLIENT_ID}
  client_secret: ${PORTAL_CLIENT_SECRET}
  allowed_domains: [example.com]
connectors:
  - portal-chat
access:
  database:
    tickets:
      read: doc.author_id == user.id
      insert: true
      set:
        author_id: user.id

Jede Umgebung bekommt eine eigene App mit eigener Adresse, etwa https://portal-1a2b3c4d.connic.app. Ein Block environments kann jeder Umgebung eine eigene Anmeldung und Domain geben, etwa connic-Konten im Staging und den Firmen-Login unter portal.example.com in der Produktivumgebung. Ein fehlgeschlagener Build lässt das Deployment scheitern, und das aktive Deployment liefert weiter die letzte funktionierende Version aus. Jedes Deployment behält seinen eigenen Build, ein Rollback bringt das ältere Frontend zusammen mit den älteren Agenten zurück.

Anmeldung ohne eigenes Auth-Backend

Jede App hat einen von drei Anmeldemodi. Er steht in der App-Datei oder im Dashboard auf dem Tab Settings der App, wo eine Änderung ohne Deployment gilt:

Bei Apps mit Anmeldung prüft connic die Session, bevor es überhaupt eine Datei ausliefert. Wer keinen Zugang hat, bekommt nicht einmal das JavaScript der App zu sehen. Eine Session hält bis zu 12 Stunden. Bei connic-Konten prüft connic Projektmitgliedschaft und Berechtigungsgruppen alle zehn Minuten neu. Wer aus dem Projekt entfernt wird, verliert den Zugang also innerhalb von Minuten.

Agenten direkt aus dem Browser aufrufen

Agenten erreicht der Browser über Connectors auf dem Host der App. Ein synchroner Webhook- oder WebSocket-Connector mit apps_only: true nimmt nur Anfragen von den Apps an, die ihn auflisten. Im Code der App steht weder ein Secret noch ein API-Schlüssel. Mit eingeschaltetem Streaming zeigt ein Chat die Antwort, während das Modell sie noch schreibt:

type: websocket
apps_only: true      # nur Apps, die diesen Connector auflisten, erreichen ihn
config:
  streaming: true
agents:
  - support

An jeden Run, den die App startet, hängt connic die Angaben zum Besucher: ID, E-Mail, Name und Gruppen landen im Run-Kontext, von connic aus der Anfrage gesetzt und nie aus der Nachricht. Ein Agent kann so die Bestellungen des Besuchers über dessen E-Mail nachschlagen oder über die Anmeldung pro Nutzer das eigene Konto jeder Person mit einem MCP-Server verbinden.

Zugriffsregeln entscheiden, was jeder Besucher sieht

Viele Ansichten zeigen nur Daten an: eine Liste von Tickets, die Dateien, die ein Kunde hochgeladen hat, die Runs, die jemand gestartet hat. Dafür sollte niemand auf einen Agenten-Run warten. Die Daten-API gibt dem Browser Zugriff auf Datenbank, Dateien, Runs, Sessions und Freigaben der Umgebung der App und dazu die Suche in Retrieval-Namespaces. Diese Anfragen lesen und schreiben direkt und starten nie einen Agenten-Run.

In diesem IT-Desk schicken eine Mitarbeiterin und das IT-Team dieselbe Anfrage und bekommen unterschiedliche Antworten:

Dafür sorgt der Block access in der App-Datei, mit einer Regel pro Ressource und Operation:

access:
  database:
    tickets:
      read: doc.author_id == user.id or "it-support" in user.groups
      insert: user.signed_in == true
      set:
        author_id: user.id

connic hängt die Regeln an die Abfrage selbst. Listen, Zählungen, Updates und Löschvorgänge erfassen deshalb nur Datensätze, die die Regeln erlauben. Alles ohne Regel lehnt connic ab. set trägt bei jedem Einfügen die Autorin oder den Autor ein, egal was der Browser geschickt hat. Eine Regel, die connic nicht durchsetzen kann, lässt das Deployment fehlschlagen, und jeder Schreibvorgang landet mit App und Besucher im Audit-Log.

Beispiel: ein Posteingang für Erstattungen

Ein Support-Agent schlägt Erstattungen vor und muss auf eine Freigabe warten, bevor er eine auszahlt. Das Finanzteam entscheidet in einer eigenen kleinen App, mit Bestellung, Betrag und Begründung der Kundin direkt neben den Buttons:

Mitglieder der Berechtigungsgruppe Finance melden sich mit ihrem connic-Konto an und dürfen über Erstattungen unter 5.000 entscheiden. Über größere Erstattungen kann die App nicht entscheiden; sie brauchen eine Entscheidung an anderer Stelle, etwa im Dashboard. Eine Freigabe setzt den wartenden Run fort.

name: Erstattungsfreigaben
build:
  command: npm run build
  output: dist
auth:
  mode: connic
  groups: [Finance]
access:
  approvals:
    read: '"Finance" in user.groups'
    decide: '"Finance" in user.groups and approval.tool == "issue_refund" and approval.params.amount < 5000'

Die App lokal mit connic dev bauen

connic dev baut jede App lokal und liefert sie unter ihrer URL in der Dev-Umgebung aus. Dort läuft sie gegen die Agenten der Dev-Session, mit derselben Anmeldung, denselben Connectors und denselben Zugriffsregeln wie nach einem Deployment. Jedes Speichern einer Quelldatei baut die App neu. Schlägt ein Build fehl, bleibt der letzte funktionierende live, bis der nächste gelingt.

Eigene Domains, Statistiken und connic MCP

Jede App ist unter ihrer connic.app-Adresse erreichbar. Zusätzlich kann eine verifizierte eigene Domain des Projekts sie ausliefern, festgelegt in der App-Datei oder im Dashboard. Wird die connic.app-Adresse im Dashboard oder über connic MCP abgeschaltet, leitet sie auf die eigene Domain weiter. Alte Links funktionieren dann weiter, und Suchmaschinen indexieren nur die eigene Domain.

Im Dashboard listet die Seite Apps alle Apps einer Umgebung mit URL, Anmeldung und den Besuchern, Seitenaufrufen, Anmeldungen und Datenanfragen der letzten sieben Tage. Die Details einer App zeigen 30 Tage Statistik, in der fehlgeschlagene Anmeldungen und abgelehnte Anfragen gesondert zählen, sowie die bereitgestellten Zugriffsregeln. Coding-Agenten bekommen dasselbe über connic MCP, das auch Domain und Anmeldung einer App ändern kann.

Verfügbarkeit

Apps sind Teil der Tarife Pro und Enterprise. Im Pro-Tarif liefert jede Umgebung bis zu 5 Apps aus, jede mit bis zu 25 MiB Build-Ausgabe. Enterprise-Tarife können andere Limits festlegen. Runs, die eine App startet, werden wie jeder andere Agenten-Run abgerechnet. Die Tarife im Vergleich zeigt die Seite Preise.

So legst du los

1. 1

   Aktualisiere das composer SDK. Ab Version 0.1.59 sind Apps und alle Zugriffsregeln aus diesem Artikel enthalten:

   Copy

   pip install --upgrade connic-composer-sdk

2. 2

   Lege die App an. Erstelle apps/<key>.yaml und lege das Frontend mit package.json und Lockfile in apps/<key>/ ab. Für Aufrufe an Agenten fügst du einen Connector mit apps_only: true hinzu und trägst ihn unter connectors ein.

3. 3

   Starte connic dev. Installiere vorher die Abhängigkeiten der App, etwa mit npm install in apps/<key>/. Öffne dann die URL, die connic dev ausgibt, und bearbeite die App. Jedes Speichern baut sie neu.

4. 4

   Starte ein Deployment. connic deploy baut die App zusammen mit den Agenten, und die Seite Apps zeigt ihre URL. Alle Einstellungen beschreibt die Apps-Dokumentation.