Sessions, Datensätze und Dokumente.
In jedem Environment schon dabei.
Gesprächsverläufe über Runs hinweg, eine Dokumentdatenbank mit Umkreissuche und semantische Suche in deinen Dateien. Jedes Environment bringt alles mit, du musst nichts einrichten.
Drei Blöcke im YAML. Keine eigene Datenbank nötig.
booking-assistant merkt sich jeden Chat, arbeitet mit zwei Collections und durchsucht Garantiebedingungen. Die Grenzen aus seinem YAML gelten bei jedem Run.
- session
- Speichert das Gespräch zwischen Runs, eine Session pro
chat_id.ttlbeendet sie nach sieben Tagen ohne Nachricht. - database
- Beschränkt den Agenten auf die Collections
workshopsundbookings.prevent_deletesperrtdb_delete. - retrieval
- Grenzt die Suche auf den Namespace
warrantyein. Mitprevent_writekann der Agent keine Einträge anlegen.
agents/booking-assistant.yaml
version: "1.0"
name: booking-assistant
description: Books service appointments at the nearest workshop
model: connic/gpt-5.6-terra
system_prompt: |
Help customers book a service appointment.
Use what they already told you in this chat.
tools:
- bookings.find_workshops
- bookings.book_slot
- warranty.search_terms
session:
key: input.chat_id
ttl: 604800
database:
collections: [workshops, bookings]
prevent_delete: true
retrieval:
namespaces: [warranty]
prevent_write: trueDatensätze aus jedem Tool speichern und abfragen.
Tools rufen db_find und db_insert wie jede andere async-Funktion auf. Hier liefert $near die nächstgelegenen Werkstätten zuerst.
- Kein Schema, keine Migrationen
- Der erste Schreibzugriff legt die Collection an.
- Filtern und sortieren
- Operatoren wie
$gt,$in,$regex,$elemMatchund$near, dazu Sortierung, Paginierung, Feldauswahl und eindeutige Werte. - Sieben fertige Tools
db_find,db_insert,db_update,db_upsert,db_delete,db_countunddb_list_collections. Du rufst sie aus deinen Tools auf oder trägst sie direkt am Agenten ein.
tools/bookings.py
from connic.tools import db_find, db_insert
async def find_workshops(lat: float, lng: float) -> list[dict]:
"""Find the three closest workshops within 25 km.
Args:
lat: Latitude of the customer
lng: Longitude of the customer
"""
result = await db_find(
"workshops",
filter={"location": {"$near": {"lat": lat, "lng": lng, "maxDistance": 25000}}},
limit=3,
)
return result["documents"] # nearest first, each with _distance in meters
async def book_slot(workshop: str, starts_at: str, licence_plate: str) -> dict:
"""Book a service slot.
Args:
workshop: Workshop code from find_workshops, e.g. MUC-EAST
starts_at: Start time in ISO 8601
licence_plate: The customer's licence plate
"""
return await db_insert("bookings", {
"workshop": workshop,
"starts_at": starts_at,
"licence_plate": licence_plate,
"status": "confirmed",
})Am nächsten Tag geht der Chat genau dort weiter.
connic speichert den Verlauf jeder Session zwischen den Runs. Der Agent kennt die Werkstatt und die angebotenen Termine noch, und unter Storage → Sessions siehst du jedes Gespräch.
Jedes Environment hat eigene Daten. Staging bekommt nur, was du kopierst.
Sessions, Collections und Retrieval-Einträge bleiben in ihrem Environment. Tests in Staging fassen Produktivdaten also nie an.
Entdecke weitere Features
RetrievalQuellen, Namespaces und Such-Tools mit festem Bereich.Toolsdb_find und retrieval_query in typisierte Tools packen.composer SDKAgenten in YAML, Tools in Python.EnvironmentsStaging und Produktivumgebung mit getrennten Daten.ObservabilityJeder Datenbank- und Retrieval-Aufruf im Trace.BridgesEigene Datenbanken in privaten Netzen erreichen.VerbindungenRuns per Webhook, E-Mail oder Zeitplan starten.Dev ServerEin Dev-Environment mit eigener Datenbank und eigenen Sessions.
Häufig gestellte Fragen
Nein. Jedes Environment bringt eine Dokumentdatenbank, einen Session-Speicher und einen Retrieval-Index mit. Collections entstehen beim ersten db_insert oder db_upsert, Dokumente brauchen kein Schema, und unter Storage → Database legst du Collections auch von Hand an.
Ergänze session im YAML des Agenten. Ohne key teilen sich alle Runs des Agenten eine Session, mit key: input.chat_id oder key: context.chat_id bekommt jeder Wert seinen eigenen Verlauf. Gesprächsverlauf und Browserzustand bleiben standardmäßig erhalten, und mit ttl (ab 60 Sekunden) laufen inaktive Sessions ab.
Runs mit derselben Session laufen nicht automatisch nacheinander, und überschneiden sich zwei, schlägt der Run fehl, der als zweiter schreibt. Leg deshalb eine Concurrency-Regel auf dasselbe Feld wie den Session-Key, etwa concurrency.key: chat_id mit session.key: input.chat_id. Dann warten die Runs eines Chats aufeinander.
Die Datenbank passt zu Datensätzen, die du über exakte Werte findest, etwa Buchungen, Bestellungen oder Kundeneinstellungen. Retrieval passt zu Texten, die über ihre Bedeutung gefunden werden sollen, etwa Richtlinien, Handbücher und Hilfeartikel. booking-assistant nutzt beides: Werkstätten und Buchungen liegen in Collections, die Garantiebedingungen im Retrieval.
Ja. database.collections und retrieval.namespaces beschränken einen Agenten auf bestimmte Collections oder Namespaces. prevent_write und prevent_delete sperren Änderungen global oder pro Collection und Namespace, auch wenn deine eigenen Tools die Funktionen db_* und retrieval_* aufrufen.
Nein. Sessions, Collections und Retrieval-Einträge gehören zu genau einem Environment, Staging und Produktivumgebung sehen also nie die Daten des anderen. Mit Copy from other env auf den Seiten Database und Retrieval holst du ausgewählte Collections oder Namespaces herüber, mit Skip oder Replace für Einträge, die es schon gibt.