Warum Ihre KI-Agenten langsam sind: Performance- und Speicheroptimierung mit ECC

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem DennisCraft AI Studio implementiere ich KI-Systeme für DACH-B2B-Kunden in regulierten Branchen – mit Claude, Supabase, n8n, Doppler und selbst gehosteter Postgres. In den letzten sechs Monaten habe ich 14 produktive KI-Agenten ausgeliefert. Was in Demos schnell aussieht, wird im Produktivbetrieb häufig durch die Execution Context & Control (ECC) Schicht gebremst. Nicht das LLM oder die API sind schuld, sondern wie Kontext und Gedächtnis gemanagt werden – besonders bei DSGVO- oder ISO 27001-Pflicht.

Wo Engpässe entstehen: ECC als Flaschenhals

Die meisten Performance-Probleme liegen nicht beim Modell, sondern bei Initialisierung, Gedächtniszugriff und Funktionsverkettung in der ECC-Schicht. In einem Supabase- und Postgres-Projekt führten 2–3 Sekunden Latenz pro Agenten-Schritt auf ineffiziente Speicherzugriffe und doppelte Initialisierungen zurück. Kein Hardwareproblem, sondern Architektur-Fehler.

Typische Fehlerquellen in der ECC:

Jeder Request erzeugt einen neuen Execution Context, statt bestehende Kontexte zu nutzen.
ORM statt direkter asynchroner SQL-Zugriffe für Speicheroperationen.
Kein Caching für Gedächtnis- oder Zwischenwerte.
Unoptimierte externe Service-Aufrufe (z.B. n8n-Workflows) ohne Batch- oder Queue-Mechanismen.

Gedächtnisverwaltung: Geschwindigkeit und Vorhersagbarkeit

Agenten-Gedächtnis ist mehr als Chat-Historie oder RAG-Daten. Geschwindigkeit, Isolation und Wartbarkeit stehen im Vordergrund. Bei einem Kunden-Projekt blähte sich die memory-Tabelle in Postgres ohne TTL und Indizes innerhalb einer Woche auf 700.000 Zeilen auf. SELECTs brauchten 1,7 Sekunden statt 60 Millisekunden, der Kunde vermutete „zu viel Traffic“ – tatsächlich fehlte das Speicher-Management.

Problem	Symptom	Erprobte Lösung
Tabellenwachstum	1–2s SELECT-Latenz	TTL, Index auf session_id, regelmäßiges VACUUM
Kein Cache	Doppelte DB-Lesevorgänge	Redis/LRU-Cache auf Postgres/Supabase
Schlechte Datenisolation	Race Conditions, Kontext-Leaks	Sitzungsbasierte ECC, Row-Level-Locks

Was im Produktivbetrieb funktioniert: ECC-Muster

Für DSGVO- und ISO 27001-Projekte müssen Microservices und Agenteninstanzen auch unter Last stabil bleiben. Diese Muster setze ich in DACH-Produktionsumgebungen ein:

1. Kontext wiederverwenden, nicht neu bauen


from contextvars import ContextVar

agent_context = ContextVar("agent_context")

async def get_context():
    ctx = agent_context.get(None)
    if ctx is None:
        ctx = await load_context_from_db()
        agent_context.set(ctx)
    return ctx

ContextVar ermöglicht eine Sitzungsisolation ohne wiederholte Initialisierung – das spart Zeit und Ressourcen.

2. Asynchrone Verbindungspools für Gedächtniszugriff


import asyncpg

pool = await asyncpg.create_pool(dsn="postgres://user:pass@db/agents")

async def get_memory(agent_id):
    async with pool.acquire() as conn:
        row = await conn.fetchrow("SELECT * FROM memory WHERE agent_id = $1", agent_id)
        return row

Asynchrone Pools vermeiden Blockaden und erhöhen die Parallelität – entscheidend im Multi-Agenten-Betrieb.

3. Caching für Zwischenstände


import aioredis

redis = await aioredis.create_redis_pool("redis://localhost")

async def get_cached_memory(key):
    value = await redis.get(key)
    if value:
        return value
    value = await heavy_db_lookup(key)
    await redis.set(key, value, expire=600)
    return value

Ein Redis-Cache reduziert DB-Lesezugriffe um bis zu 80% – das habe ich mehrfach in der DACH-Praxis gemessen.

Gedächtniswachstum eindämmen: TTL, Indizes, Deduplikation

Unkontrolliertes Wachstum der memory-Tabellen führt zu Latenz und Verbindungsproblemen. Ohne TTL und Cleanup stiegen bei einem Kunden die Query-Zeiten auf 3 Sekunden, Pools liefen voll. Jede produktive Agenten-Architektur braucht regelmäßige Wartungsjobs.


CREATE INDEX idx_session ON memory(session_id);
DELETE FROM memory WHERE created_at < NOW() - INTERVAL '7 days';
VACUUM FULL memory;

Automatisierte Bereinigung und Indizierung sind Pflicht, wenn Sie DSGVO oder BSI-Grundschutz einhalten wollen.

ECC skalieren: Wann auf Microservices aufteilen?

Ab ca. 10 parallelen Agenten empfiehlt sich eine Trennung von ECC-Komponenten (Kontext, Speicher, Task-Queue) in dedizierte Microservices mit klaren APIs. Das begrenzt Fehlerausbreitung und hält Antwortzeiten konstant. Monolithische ECCs geraten unter Last ins Stocken – Microservices ermöglichen stabiles Wachstum.

Muster	Vorteile	Nachteile
Monolithisches ECC	Einfache Bereitstellung	Geringe Skalierbarkeit, Datenrennen
Microservice-ECC	Isolation, schnelle Reaktion	Höherer Wartungsaufwand

FAQ

Warum sind Agenten langsam, obwohl das LLM schnell antwortet?

Weil die ECC-Schicht – Kontext, Gedächtnis, Steuerung – der eigentliche Engpass ist, nicht das Modell.

Wie erkenne ich ECC-Probleme?

Messen Sie die Latenz jedes Agentenschritts. Grosse Lücken zwischen LLM-Completion und nachfolgendem Step deuten auf Probleme im Kontext- oder Gedächtnis-Handling hin.

Welches Cache-Muster ist praxistauglich?

Redis mit Sitzungs-TTL und Key-Invalidation reicht für die meisten DACH-Projekte. Bei hoher Last: Sharding oder Memcached.

Wie verhindere ich unkontrolliertes Gedächtniswachstum?

TTL, Deduplikation und wöchentliche Bereinigung sind Pflicht. Felder für Lookups sollten indiziert sein.

Welcher ECC-Stack ist am stabilsten?

Supabase/Postgres + asyncpg + aioredis laufen stabil für 10–50 Agenten im deutschsprachigen Produktivbetrieb.

Wo entstehen bei Ihnen die größten Latenzen im produktiven Agentenbetrieb: Gedächtnis, Kontext oder Aufgabensteuerung? Ich biete einen kostenfreien 30-Minuten Stack-Audit für DACH-Unternehmen mit regulierten KI-Lösungen. Kontaktieren Sie mich auf LinkedIn oder @ger_dennis_ai.