connic Dateien: Dauerhafter Dateispeicher für KI-Agenten

Ab heute bringt jede connic-Umgebung mit connic Dateien einen eigenen Dateispeicher mit. Ein Bericht oder Download, den ein Agent heute speichert, ist noch da, wenn ihn der Run im nächsten Monat oder ein anderer Agent braucht.

Dateien, die den Run überdauern

Viele Aufgaben von Agenten erzeugen oder sammeln eine Datei: einen Monatsbericht, eine Rechnung aus einem Lieferantenportal, eine aus einer Web-App exportierte Tabelle. Bisher verschwand ein Browser-Download, sobald die Browser-Session endete, und connic hatte keinen festen Ort, an dem der nächste Run oder der nächste Agent eine Datei abholen konnte.

Mit connic Dateien wählen Agenten beim Speichern selbst den Pfad, etwa invoices/2026/acme.pdf, und ein Ordner entsteht, sobald die erste Datei darin liegt. Dateien bleiben erhalten, bis ein Agent, ein Teammitglied oder ein API-Client sie löscht. Jede Umgebung hat ihren eigenen Baum, Runs im Staging berühren also keine Produktivdateien. Die Dateiinhalte sind mit einem eigenen Schlüssel pro Umgebung verschlüsselt gespeichert.

Kein Schreibvorgang ersetzt versehentlich eine vorhandene Datei. Ist ein Pfad schon belegt, wird die neue Datei unter einem nummerierten Namen wie acme (2).pdf gespeichert, außer der Schreibvorgang verlangt ausdrücklich das Überschreiben.

Dateien lesen, schreiben und ordnen

Fünf Datei-Tools geben einem Agenten Zugriff auf den Baum: file_list, file_read, file_write, file_update und file_delete.

Mit file_read liest ein Agent Dateien bis 20 MiB. Textdateien kommen vollständig beim Modell an, nie als gekürzter Auszug, und zählen damit in voller Länge gegen sein Kontextfenster. PDFs sowie PNG-, JPEG-, GIF- und WebP-Bilder erhält das Modell als Anhang, sofern das Modell des Agenten diesen Eingabetyp unterstützt; sonst schlägt die Anfrage an das Modell fehl. Welche Eingaben ein Modell unterstützt, zeigt der Modellkatalog. Bei anderen Formaten liefert das Tool die Angaben zur Datei mit einer Fehlermeldung zurück, damit der Agent den Pfad an den Browser oder ein eigenes Tool weitergeben kann.

Agenten schreiben Textdateien wie Markdown-Berichte, CSV-Exporte oder JSON, fehlende Ordner werden dabei angelegt. Außerdem benennen sie einzelne Dateien oder ganze Ordner um, verschieben sie, ändern Metadaten und löschen, was nicht mehr gebraucht wird.

In eigenen Tools stehen dieselben Funktionen über connic.tools bereit. Dort liefert file_read den Inhalt jeder Datei als Bytes, und file_write nimmt auch Bytes entgegen, etwa ein PDF, das das Tool erzeugt hat.

Herkunft jeder Datei nachvollziehen

connic hält fest, welcher Agent, welcher Run und welche Session eine Datei geschrieben hat und ob sie von einem Agenten, aus dem Browser, aus dem Dashboard oder über die API kam. Diese Felder setzt die Plattform, Agenten können sie nicht ändern. Die Frage „Welche Dateien hat der fehlgeschlagene Run von gestern geschrieben?“ beantwortet dann ein Filter statt einer Suche in den Logs.

Eigene Metadaten können Agenten und Teammitglieder hinzufügen, etwa eine Kundennummer oder einen Bearbeitungsstatus. file_list filtert nach beiden Arten von Feldern mit denselben Abfrageoperatoren wie die connic-Datenbank, sortiert die Treffer und teilt sie in Seiten auf. Mit einem Statusfeld arbeitet ein Agent einen Ordner der Reihe nach ab. Dieses eigene Tool holt die älteste neue Rechnung und markiert sie als in Bearbeitung:

from connic.tools import file_list, file_update

async def next_pending_invoice() -> dict:
    """Gibt die älteste noch offene Rechnung zurück."""
    result = await file_list(
        "invoices",
        recursive=True,
        filter={"status": "new", "_mime_type": "application/pdf"},
        sort={"_created_at": 1},
        limit=1,
    )
    if not result["files"]:
        return {"done": True}
    invoice = result["files"][0]
    updated = await file_update(invoice["_path"], metadata={"status": "processing"})
    return updated["file"]

Dateien in den Browser und zurück

Agenten, die mit den Browser-Tools auf Websites arbeiten, können speichern, was sie dort finden. Mit save_to landet ein Download direkt im Dateispeicher, bis 100 MiB. Dieselbe Option speichert eine Seite als PDF, bewahrt das vollständige Ergebnis eines Skripts auf, das Daten aus einer Seite ausgelesen hat, oder legt eine einzelne Netzwerkantwort oder eine HAR-Datei des aufgezeichneten Datenverkehrs ab.

Das funktioniert auch in die andere Richtung. web_browser_upload setzt eine gespeicherte Datei in das Upload-Feld einer Website ein, im selben Run oder Wochen später. So kann ein anderer Agent eine Rechnung aus einem Portal in ein Buchhaltungssystem hochladen. Auch längere Browser-Skripte lassen sich als Datei ablegen und von dort ausführen.

# Download direkt im Dateispeicher ablegen (bis 100 MiB)
await web_browser_download("e12", include_content=False, save_to="invoices/acme/")

# Gespeicherte Datei in ein Upload-Feld einsetzen
await web_browser_upload("e7", path="contracts/signed/acme.pdf")

Festlegen, was jeder Agent sieht

Ohne weitere Konfiguration kann ein Agent den ganzen Baum nutzen. Ein files-Block im YAML des Agenten schränkt das ein, so wie sich Agenten schon heute auf bestimmte Collections der Datenbank oder Namespaces in Retrieval begrenzen lassen:

• Ordner: Der Agent sieht nur die aufgeführten Ordner und alles darunter. Dateien an anderer Stelle sind für ihn unsichtbar.
• Schreibschutz und Löschsperre: prevent_write und prevent_delete sperren Änderungen für den ganzen Agenten oder für einzelne Ordner.
• Nur die eigene Session: Mit session_only sieht der Agent nur Dateien, die in seiner aktuellen Session geschrieben wurden. Hat jeder Kunde eine eigene Session, bleiben Dateien, die der Agent für einen Kunden gespeichert hat, außer Reichweite, wenn er den nächsten bedient.

Einstellungen an einem Ordner haben Vorrang vor den Einstellungen des Agenten. In diesem Support-Agenten bleiben Dateien, die der Agent unter cases speichert, in der Session des aktuellen Kunden, während der Ordner templates geteilt und schreibgeschützt ist:

session:
  key: input.customer_id

files:
  session_only: true          # nur Dateien aus der Session dieses Kunden
  prevent_delete: true
  folders:
    cases: {}
    templates:
      session_only: false     # von allen Sessions geteilt
      prevent_write: true

connic wendet diese Regeln auf jeden Aufruf der Datei-Tools an, auch aus eigenen Tools, und ebenso auf Übertragungen im Browser. Eine Datei, die ein Agent nicht sehen kann, wird nie ersetzt: Ist ihr Pfad belegt, erhält die neue Datei einen nummerierten Namen. Dashboard und API zeigen Teammitgliedern und API-Schlüsseln mit Dateiberechtigungen den ganzen Baum.

Beispiel: Lieferantenrechnungen sammeln und verarbeiten

Zwei Agenten teilen sich den Ordner invoices. Eine Cron-Verbindung startet den Sammelagenten einmal im Monat. Er öffnet das Lieferantenportal, lädt die Rechnung nach invoices/<supplier>/ herunter und markiert sie mit dem Status new. Keiner der beiden Agenten kann Rechnungen löschen oder etwas außerhalb des Ordners sehen.

version: "1.0"

name: invoice-collector
model: connic/claude-sonnet-5.5
description: "Lädt Lieferantenrechnungen herunter und legt sie ab"
system_prompt: |
  Lade die Rechnung dieses Monats aus dem Lieferantenportal herunter und
  speichere sie unter invoices/<supplier>/. Markiere neue Rechnungen mit
  dem Status "new".

tools:
  - web_browser_open
  - web_browser_observe
  - web_browser_act
  - web_browser_download
  - file_list
  - file_update

files:
  folders: [invoices]
  prevent_delete: true

In einem späteren Run findet der Buchhaltungsagent die neuen Rechnungen über ihren Status, liest jedes PDF und legt es unter invoices/processed/ ab. Dafür braucht er ein Modell, das PDFs liest; das Beispiel nutzt Claude Sonnet 5.5.

version: "1.0"

name: invoice-bookkeeper
model: connic/claude-sonnet-5.5
description: "Liest Rechnungsdaten aus und legt verarbeitete Rechnungen ab"
system_prompt: |
  Suche unter invoices/ nach Rechnungen mit dem Status "new". Lies jedes
  PDF und gib Lieferant, Rechnungsnummer, Datum und Gesamtbetrag als JSON
  zurück. Setze danach den Status auf "processed" und verschiebe die
  Rechnung nach invoices/processed/<file name>.

tools:
  - file_list
  - file_read
  - file_update

files:
  folders: [invoices]
  prevent_delete: true

Dateien in Dashboard, API und MCP verwalten

Die Seite Files im Dashboard zeigt den Baum der ausgewählten Umgebung. Dort laden Teammitglieder Dateien bis 1 GiB per Auswahl oder Drag-and-drop hoch, sehen Vorschauen von Bildern und Textdateien, bearbeiten eigene Metadaten und verschieben, benennen oder löschen Dateien und Ordner, einzeln oder mehrere auf einmal. Filter grenzen die Liste auf eine Quelle, einen Agenten, einen Run oder eine Session ein, und die Details eines Runs oder einer Session verlinken direkt auf die Dateien, die dort geschrieben wurden.

Die REST API bietet dieselben Funktionen für andere Systeme: Auflisten und Filtern, Uploads bis 1 GiB, Änderungen an Metadaten und kurzlebige Download-Links. Über connic MCP lädt ein Coding-Agent Testdaten hoch, prüft, was ein Agent geschrieben hat, und räumt danach auf, direkt im Chat, in dem er die Agenten entwickelt.

Limits und Abrechnung

Gespeicherte Dateien und Downloads werden über das Projektguthaben abgerechnet. Als Download zählen Dateien, die über Dashboard oder API abgerufen werden, und gespeicherte Dateien, die ein Agent im Browser hochlädt oder als Skript ausführt. Dateien, die Agenten mit den Datei-Tools lesen, werden nicht als Download abgerechnet. Die aktuellen Preise stehen auf der Seite Preise.

Loslegen

1. 1

   Das composer SDK aktualisieren. Datei-Tools, der files-Block und die Browser-Optionen aus diesem Artikel brauchen Version 0.1.54 oder neuer:

   Copy

   pip install --upgrade connic-composer-sdk

2. 2

   Einem Agenten die Datei-Tools geben. Füge die benötigten Tools hinzu und, wenn er nicht den ganzen Baum sehen soll, einen files-Block mit seinen Ordnern. Browser-Agenten speichern Downloads dort mit save_to.

3. 3

   Bereitstellen und ausführen. Öffne Files im Dashboard und sieh nach, was der Agent gespeichert hat, mit Agent, Run und Quelle jeder Datei.