Runtime-Steuerung

Regeln zur Nebenläufigkeit

Regeln zur Nebenläufigkeit stellen sicher, dass pro eindeutigem Schlüssel immer nur ein Run aktiv ist. Verwende sie, wenn ein Agent Events für einen bestimmten Support-Prozess, Kunden oder Auftrag verarbeitet und eine parallele Verarbeitung zu Konflikten führen würde.

Queue-Modus (Standard)

Trifft ein weiteres Event für einen aktiven Schlüssel ein, wartet es, bis der erste Run beendet ist, und startet anschließend automatisch.

version: "1.0"

name: support-processor
type: llm
model: connic/gpt-5.6-terra
description: "Processes support tickets one at a time per process"
system_prompt: "You are a support agent. Process the incoming ticket."

# Only one run per process_id at a time. Additional runs wait in queue.
concurrency:
  key: "process_id"
  on_conflict: queue

Drop-Modus

Trifft ein weiteres Event für einen aktiven Schlüssel ein, wird der neue Run sofort abgebrochen. Verwende diesen Modus, wenn doppelte Arbeit unnötig wäre.

version: "1.0"

name: notification-handler
type: tool
description: "Handles notifications, skipping duplicates"
tool_name: notifications.handle

# Drop duplicate runs for the same customer while one is active.
concurrency:
  key: "data.customer_id"
  on_conflict: drop

Schlüssel extrahieren

key liest die Trigger-Payload in Punktnotation. Wenn ein Kafka-Payload {"data": {"customer_id": "abc"}} lautet, verwende data.customer_id. Existiert der Pfad nicht, wird die Nebenläufigkeitsregel für diesen Run übersprungen.

Zusammenspiel mit max_concurrent_runs

Beide Einschränkungen gelten. Mit max_concurrent_runs: 5 und concurrency.key: "process_id"können fünf Prozess-IDs parallel laufen, aber pro Prozess-ID kann nur ein Run aktiv sein.

Persistente Sessions

Standardmäßig erstellt jede Anfrage eine isolierte Session. Persistente Sessions erhalten den Gesprächsverlauf über Anfragen, Neustarts und erneute Deployments hinweg.

version: "1.0"

name: support-bot
type: llm
model: connic/gpt-5.6-terra
description: "A support chatbot that remembers conversation history"
system_prompt: |
  You are a helpful support agent. Use the conversation history
  to provide contextual responses.

# Maintain persistent sessions keyed by chat ID from middleware
session:
  key: context.chat_id
  ttl: 86400  # Sessions expire after 24 hours of inactivity

# Keep long conversations within the model context window
context_compression:
  enabled: true
  # Optional model for compression summaries; defaults to the agent model
  model: connic/gpt-5.6-luna
  keep_recent_messages: 12
  # Optional early compression based on model-reported prompt usage
  max_prompt_tokens: 100000

Session-Schlüssel

key identifiziert die Session und muss eines von zwei Präfixen verwenden:

• context.<path> liest den Session-Schlüssel aus dem Middleware-Kontext. Die Middleware kann ihn auch aus den Anfragedaten ableiten.
• input.<path> liest den Session-Schlüssel direkt aus der Payload der Verbindung, bevor die Middleware ausgeführt wird. Die Payload muss gültiges JSON sein; auch verschachtelte Felder sind zugänglich.

Schlüssel in Middleware setzen

async def before(content: dict, context: dict) -> dict:
    # Extract a stable identifier for this conversation from the connector payload.
    payload = context.get("payload", {})
    context["chat_id"] = payload.get("chat_id")
    return content

Input-Schlüssel verwenden

# When the connector payload is JSON like {"user_id": "u123", "message": "..."}
session:
  key: input.user_id

TTL und Session-Verwaltung

Der optionale Wert ttl legt fest, nach wie vielen Sekunden ohne Aktivität eine Session abläuft. Das Minimum beträgt 60 Sekunden; ohne TTL laufen Sessions nie ab. Aktive Sessions lassen sich im Dashboard unter Storage > Sessions ansehen und löschen. Sessions gelten pro Environment.

Kontextkomprimierung

Füge context_compression hinzu, damit lange LLM-Sessions innerhalb des KI-Modell-Kontextfensters bleiben. Nach der Konfiguration lösen Kontextfensterfehler des Providers eine Komprimierung und einen automatischen Wiederholungsversuch aus. Lege context_compression.model fest, um ein separates KI-Modell für Zusammenfassungen zu verwenden; normale Agent-Aufrufe und ihre Wiederholungsversuche nutzen weiterhin das KI-Modell des Agenten. Lege max_prompt_tokens fest, um anhand der gemeldeten Prompt-Nutzung früher zu komprimieren. Verwende session_history.interval nur, wenn auch der gespeicherte Verlauf zwischen Runs komprimiert werden soll.