# BLUEPRINT-AWS-AGENTS
Agentische Workflows auf AWS
Planner/Supervisor auf LangGraph mit modular erweiterbaren Teams und Tools, zentralem Single-Table-State in DynamoDB sowie einer Sync-/Async-Trennung, die die Chat-Latenz begrenzt hält, während lange Jobs über SQS laufen.
# THE-PROBLEM
warum es dieses Muster gibt.
Die meisten „KI-Agenten“-Systeme sind eine lose Prompt-Schleife, an die eine Handvoll Tools angeschlossen ist, und sie scheitern in dem Moment, in dem Sie Determinismus, Mandantenfähigkeit oder Auditierbarkeit benötigen. Am Ende können Sie weder erklären, warum ein Agent etwas getan hat, noch das System erweitern, ohne die Runtime neu auszurollen, noch langlaufende Arbeit vom synchronen Request-Pfad lösen.
Eine produktionsreife Agentenplattform muss die LLM-Nichtdeterminismen hinter einem validierten Vertrag isolieren, es Mitwirkenden außerhalb des Kernteams ermöglichen, neue Agenten und Tools ohne Eingriff in die Infrastruktur zu registrieren, und synchrone wie asynchrone Ausführungspfade architektonisch klar trennen. Das Datenmodell muss Schema-Drift (neue Team-Formen, neue Tool-Typen) ohne tabellenweise Migrationen verkraften.
# ARCHITECTURE
wie es gebaut ist.
Zweistufiger Planner/Supervisor
Ein Planner-Agent wandelt jede Nutzeranfrage in einen streng typisierten JSON-Plan um, validiert mit einem Zod-Schema. Ein Supervisor-Agent kompiliert diesen Plan zur Laufzeit in einen LangGraph-StateGraph, ruft für jeden Schritt sequenziell eine generische teamWorker-Lambda auf und führt die Ausgabe des vorherigen Schritts in den Kontext des nächsten Schritts über.
Erweiterbares Team-Modell
Teams sind erstklassige, durch Nutzende erweiterbare Artefakte in DynamoDB. Eine buildTeam-Factory unterstützt drei Formen — agent (Tool-nutzende ReAct-Executors), llm (Prompt-Template-Worker) und custom (dynamisch importierte Graph-Module) — sodass Betreibende neue Fähigkeiten registrieren, indem sie Daten bearbeiten, nicht Code.
Typisierte Tool-Registry
Tools teilen sich Basisklassen für Datei-, Static-Web- und HTTP/API-Integrationen sowie ein gemeinsames ToolResult-Schema. So unterschiedliche Integrationen wie die Facebook Marketing API, Google Search, Amazon-APIs und lokale Datei-I/O präsentieren dem Supervisor eine identische Erfolgs-/Fehlerform.
Sync- und Async-Ausführungspfade
Synchroner Chat fließt durch API Gateway hinter einem Cognito-JWT-Authorizer, einer API-Key-Pflicht und einer per Resource-Policy gesetzten IP-Allowlist. Langlaufende Agentenarbeit wird auf SQS verlagert und von einer dedizierten taskRunner-Lambda abgearbeitet, die für 15-minütige Ausführungen dimensioniert ist.
Single-Table-DynamoDB
Eine einzige Tabelle mit PK/SK-Composite-Keys und zwei GSIs trägt Chat-Sessions, Pläne, Tool-Call-Traces, Team-Definitionen und Prompts. Schema-Rigidität gegen vorhersagbare Latenz einzutauschen — samt PITR, TTL-Retention und KMS-CMK-Verschlüsselung — hält die Datenebene betrieblich schlank.
IAM pro Gruppe und CMK pro Dienst
Dedizierte API-Lambdas (bas-api, bas-admin-api, teams-api, tasks-api, chats-api) sind an zweckgebaute IAM-Rollen gebunden. Customer-Managed-KMS-Keys verschlüsseln die Datenebene durchgängig — DynamoDB, SQS und S3 haben jeweils ihren eigenen CMK und eine eng gefasste Key-Policy.
# KEY-PRIMITIVE
die tragende Idee.
Schema-validierter Plan als deterministisch kompilierter StateGraph
Die zentrale Entscheidung in diesem Blueprint ist die Trennung von Planung und Ausführung. Das LLM läuft einmal, um einen gegen ein Zod-Schema validierten Plan zu erzeugen; dieser Plan wird anschließend in einen LangGraph-StateGraph kompiliert und deterministisch ausgeführt. Das eliminiert eine ganze Klasse von LLM-Drift zur Laufzeit, macht jeden Schritt auditierbar (Pläne, Tool-Call-Traces und Schritt-Ausgaben werden allesamt in DynamoDB persistiert) und lässt den Supervisor Arbeit mit einem vorhersagbaren Vertrag an Worker verteilen. Es ist der Unterschied zwischen „einem Agenten, der manchmal funktioniert“ und einer Plattform, auf der Sie aufbauen können.
# TECH-STACK
was es betreibt.
# PRODUCTION-EVIDENCE
was wir gemessen haben.
Produktionsreife mandantenfähige Plattform — Infrastructure-as-Code, durchgängige Verschlüsselung, durch Teams erweiterbar.
Wir haben dies als universelle Plattform ausgeliefert, um LLM-Agenten als komponierbare Workflows zu entwerfen und zu orchestrieren. Die gesamte Umgebung ist mit dem Serverless Framework plus modularen CloudFormation-Fragmenten (IAM, Policies, Cognito, DynamoDB, SQS, S3, KMS) und stage-spezifischen Overrides mit stage-übergreifenden Exports kodifiziert. Laufzeit-Secrets werden über einen kleinen Config-Loader in den AWS Secrets Manager ausgelagert — Credentials bleiben außerhalb der Funktions-Umgebungen, eine Rotation erfordert kein erneutes Deployment.
- Erst planen, dann ausführen
- 2-stufig
- Team-Formen
- 3
- DynamoDB-Tabelle
- 1
- KMS-Verschlüsselung
- E2E
eines davon in Produktion bringen?
Ein 30-minütiges Erstgespräch. Wir passen den Blueprint an, wir verkaufen ihn nicht weiter.
termin-buchen// oder schreib uns: hello@saloid.com · gräfelfing · de