Drei Zeilen Python. Mehr braucht es nicht, um mit AWS Strands Agents einen funktionierenden KI-Agenten zu bauen. Man definiert einen Prompt, übergibt dem SDK eine Liste von Tools, und das LLM übernimmt den Rest: welche Tools wann aufgerufen werden, in welcher Reihenfolge, und wann Schluss ist. Keine Graphen, keine State Machines, kein Orchestrierungs-Boilerplate. Amazon nennt diesen Ansatz “modellgetrieben”, und er läuft bereits produktiv in Amazon Q Developer, AWS Glue und VPC Reachability Analyzer.
Seit der Open-Source-Veröffentlichung im Mai 2025 hat Strands über 14 Millionen PyPI-Downloads erreicht, 5.400 GitHub-Stars gesammelt und Beiträge von Anthropic, Meta, PwC und Accenture erhalten. Das Release 1.0 brachte Multi-Agent-Orchestrierung. Die aktuelle Version (1.30.0, Stand März 2026) liefert über 13 Modellanbieter und 20+ eingebaute Tools.
Was “modellgetrieben” konkret bedeutet
Die meisten Agent-Frameworks verlangen vom Entwickler, den Workflow selbst zu definieren. LangGraph erwartet gerichtete Graphen mit Knoten, Kanten und bedingtem Routing. CrewAI will Crew-Hierarchien und Task-Abhängigkeiten. Strands dreht die Kontrolle um: Man beschreibt die Rolle und Fähigkeiten des Agenten, und das Modell entscheidet, was zu tun ist.
Die Agent-Schleife funktioniert so: Das LLM erhält den System-Prompt, den bisherigen Gesprächsverlauf und die Beschreibungen der verfügbaren Tools. Es analysiert die Aufgabe, wählt bei Bedarf Tools aus und erzeugt eine Antwort. Strands führt die Tool-Aufrufe aus, speist die Ergebnisse zurück ins Modell und wiederholt den Vorgang. Die Schleife endet, wenn das Modell eine finale Antwort ohne weitere Tool-Aufrufe liefert.
from strands import Agent
from strands_tools import calculator, http_request
agent = Agent(tools=[calculator, http_request])
agent("Was ist der aktuelle BTC-Preis geteilt durch den Goldpreis pro Unze?")
Das ist ein vollständiger, funktionierender Agent. Das Modell entscheidet selbst, dass es Preise abrufen (via http_request), rechnen (via calculator) und eine Antwort formulieren muss. Keiner dieser Schritte wurde vom Entwickler vorgegeben.
Eigene Tools in vier Zeilen
Eigene Tools werden über einen Decorator definiert:
from strands import Agent, tool
@tool
def buchstaben_zaehler(wort: str, buchstabe: str) -> int:
"""Zählt das Vorkommen eines bestimmten Buchstabens in einem Wort."""
return wort.lower().count(buchstabe.lower())
agent = Agent(tools=[buchstaben_zaehler])
agent("Wie viele r gibt es in Erdbeere?")
Der @tool-Decorator extrahiert Funktionssignatur und Docstring, konvertiert sie ins Tool-Schema und kümmert sich um die Ausführung. Keine JSON-Schemas von Hand schreiben, kein Tool-Registrierungscode.
Produktionsbewährt innerhalb von AWS
Strands wurde nicht im Labor entwickelt und dann veröffentlicht. Es wurde aus Produktionssystemen extrahiert, die bereits innerhalb von AWS laufen. Das ist relevant, weil die Design-Entscheidungen des Frameworks durch reale betriebliche Anforderungen geprägt wurden.
Amazon Q Developer ist das Vorzeigeprojekt. Der KI-Coding-Assistent von AWS nutzt Strands für seine Agent-Funktionen. Vor Strands dauerte die Bereitstellung neuer Agenten beim Q-Developer-Team Monate. Danach: Tage bis Wochen. Die Q CLI wurde laut AWS in nur drei Wochen mit Strands gebaut.
VPC Reachability Analyzer setzt Strands-basierte Agenten für Netzwerk-Konnektivitätsanalysen ein. AWS berichtet, dass die Untersuchungszeit von 30 Minuten auf 45 Sekunden sank. Das ist eine 40-fache Verbesserung und zeigt, wie effizient es ist, die Tool-Auswahl dem Modell zu überlassen statt diagnostische Workflows hartzukodieren.
AWS Glue integrierte Strands für KI-Agent-Funktionen in Datenintegrationspipelines. AWS hat hier weniger Details veröffentlicht.
Eine externe Organisation (nicht namentlich genannt) berichtete, eine produktionsreife agentische Lösung in 10 Tagen mit Strands gebaut zu haben, verglichen mit Monaten bei herkömmlichen Ansätzen.
Multi-Agent-Orchestrierung seit Version 1.0
Das Release von Strands 1.0 im Juli 2025 führte vier Multi-Agent-Primitive ein, die die meisten Produktionsmuster abdecken:
Agents-as-Tools ist das einfachste Muster. Man erstellt spezialisierte Agenten und registriert sie als Tools für einen Orchestrator-Agenten. Der Orchestrator entscheidet, wann er Arbeit an einen Spezialisten delegiert. Das funktioniert gut für hierarchische Aufgabenzerlegung.
Handoffs ermöglichen einem Agenten, die Kontrolle an einen anderen Agenten (oder einen Menschen) zu übergeben, mit vollständiger Kontexterhaltung. Der empfangende Agent macht dort weiter, wo der erste aufgehört hat. Nützlich für Eskalations-Workflows, in denen ein Generalisten-Agent an seine Grenzen stößt.
Swarms erlauben mehreren Agenten, sich autonom über gemeinsam genutzten Arbeitsspeicher zu koordinieren. Jeder Agent liest und schreibt in einen geteilten Zustand und entscheidet unabhängig, wann er handelt. Das flexibelste Muster, aber auch das am schwersten zu debuggende.
Graphs bringen explizite Workflow-Kontrolle zurück, wenn man sie braucht. Man definiert Knoten, Kanten, bedingte Verzweigungen und Qualitätsprüfungen. Wer deterministische Ausführungspfade für Compliance oder Auditing benötigt, findet hier die Lösung.
Strands im Vergleich zur Konkurrenz
Der Markt für Agent-Frameworks ist voll. So positioniert sich Strands gegenüber den relevanten Alternativen.
Strands vs. LangGraph
LangGraph bietet feingranulare Kontrolle durch explizite Graph-Definitionen. Jeder Knoten ist eine Funktion, jede Kante eine Routing-Entscheidung. Das ist mächtig für komplexe, deterministische Workflows, bringt aber eine steilere Lernkurve und mehr Boilerplate mit sich.
Strands optimiert auf Geschwindigkeit bis zum ersten funktionierenden Agenten. Man tauscht explizite Kontrolle gegen Einfachheit. Für 80 % der Agent-Anwendungsfälle, in denen das Modellurteil ausreicht, ist man mit Strands schneller am Ziel. Für die anderen 20 %, wo garantierte Ausführungspfade nötig sind, ist LangGraphs Graph-Modell schwer zu schlagen.
Strands vs. OpenAI Agents SDK
Beide Frameworks teilen die Philosophie “einfache API, Modell steuert Orchestrierung”. Der entscheidende Unterschied: OpenAIs SDK ist eng an OpenAI-Modelle gekoppelt. Strands unterstützt über 13 Anbieter, darunter Bedrock, Anthropic, OpenAI, Ollama, LiteLLM, Google Gemini und lokale Inferenz via Llama.cpp.
OpenAIs SDK hat eingebaute Guardrails-Validierung. Strands hat native MCP-Unterstützung (Model Context Protocol) und damit Zugang zu tausenden externen Tools über eine standardisierte Schnittstelle. Beide unterstützen Agent-as-Tool und Handoff-Muster.
Strands vs. CrewAI
CrewAIs Metapher aus “Agents und Crews” ist einsteigerfreundlich, aber das Framework hat eine kostenpflichtige Enterprise-Steuerungsebene. Strands ist Apache 2.0 ohne proprietäre Komponenten. CrewAI ist Cloud-agnostischer; Strands hat tiefere AWS-Integration (Bedrock, Lambda, EKS-Deployment, AgentCore-Kompatibilität).
Für DACH-Unternehmen, die ohnehin auf AWS setzen, ist die Nähe zu Bedrock und die Möglichkeit, EU-AI-Act-konforme Modelle über Bedrock in europäischen Regionen zu betreiben, ein relevanter Vorteil gegenüber Frameworks, die primär US-Cloud-Dienste voraussetzen.
Das Modellanbieter-Ökosystem
Strands liefert eingebaute Unterstützung für eine breite Palette von Modellanbietern. Das ist der stärkste Wettbewerbsvorteil gegenüber dem OpenAI SDK:
- AWS Bedrock (Claude, Llama, Mistral und andere auf Bedrock gehostete Modelle)
- Anthropic (direkte API, von Anthropic selbst beigesteuert)
- OpenAI (GPT-4o, o3 usw.)
- Meta Llama API (von Meta beigesteuert)
- Google Gemini, Cohere, Mistral, xAI
- Ollama, LiteLLM, vLLM, Llama.cpp (lokal/selbst gehostet)
- NVIDIA NIM, SageMaker, SGLang (Enterprise/Forschung)
Der Wechsel zwischen Anbietern ist eine Konfigurationsänderung, kein Code-Umbau:
from strands import Agent
from strands.models import BedrockModel
model = BedrockModel(
model_id="anthropic.claude-sonnet-4-20250514-v1:0",
region_name="eu-central-1", # Frankfurt für DSGVO-Konformität
temperature=0.3,
)
agent = Agent(model=model)
Native MCP-Integration bedeutet, dass jeder MCP-kompatible Tool-Server direkt funktioniert. Wer bereits MCP-Tool-Server aus anderen Projekten betreibt, kann sie direkt in einen Strands-Agenten einbinden.
Wo Strands an Grenzen stößt
Kein Framework ist perfekt. Diese Punkte sollte man kennen, bevor man sich festlegt.
Abhängigkeit von der Modellqualität. Der modellgetriebene Ansatz bedeutet: Der Agent ist nur so gut wie das LLM dahinter. Schwächere Modelle produzieren Agenten, die falsche Tools wählen, unnötig schleifen oder mehrstufige Aufgaben nicht abschließen. Strands funktioniert am besten mit Claude 3.5 Sonnet oder besser. Wer aus Kostengründen auf kleinere Modelle setzt, riskiert schlechteres Agent-Verhalten, ohne viel Framework-seitig dagegen tun zu können.
AWS-Credential-Hürde. Trotz Modellagnostizität setzt die Standardkonfiguration AWS-Credentials voraus. Entwickler außerhalb des AWS-Ökosystems berichten von Reibung beim Einstieg, weil die Dokumentation mit dem Bedrock-Setup beginnt. Wer einen anderen Anbieter nutzen will, muss die Modellanbieter-Konfiguration aktiv suchen.
Empfindlichkeit bei Tool-Beschreibungen. Wenn zwei Tools überlappende Beschreibungen haben, kann das Modell konsistent das falsche wählen. Man muss präzise, nicht-überlappende Tool-Beschreibungen schreiben. Das ist kein Strands-spezifisches Problem, betrifft aber den modellgetriebenen Ansatz stärker als explizites Routing in LangGraph.
Kein eingebautes Lernen. Agenten können nicht aus vergangenen Ausführungen lernen. Jede Sitzung startet von Null. Es gibt einen GitHub-Feature-Request (#923) für kontinuierliches Lernen, aber er steht nicht auf der kurzfristigen Roadmap.
Jüngeres Ökosystem. Mit weniger als einem Jahr ist die Community und das Drittanbieter-Tooling rund um Strands noch im Aufbau, verglichen mit LangGraph (das Jahre an Ökosystem-Entwicklung hat) und selbst CrewAI. Die experimentellen Features (Steering, bidirektionales Streaming) haben APIs, die sich noch ändern können.
Für wen eignet sich Strands
Strands ist die richtige Wahl für Teams, die Agenten auf AWS-Infrastruktur bauen, modellunabhängige Flexibilität mit minimalem Boilerplate wollen oder schnell vom Prototyp in die Produktion kommen müssen. Die Erfahrung des Q-Developer-Teams (Monate auf Tage) ist repräsentativ für den Geschwindigkeitsvorteil.
Es ist die falsche Wahl, wenn man deterministische, auditierbare Ausführungspfade für jede Anfrage braucht (LangGraph nehmen), eine verwaltete Enterprise-Plattform mit GUI möchte (CrewAI Enterprise oder Bedrock AgentCore prüfen) oder wenn Agenten aus vergangenen Sitzungen lernen sollen.
Die Apache-2.0-Lizenz und die aktive Beteiligung von Anthropic und Meta deuten darauf hin, dass das Projekt über ein einzelnes Unternehmen hinaus Bestand haben wird.
Häufig gestellte Fragen
Was ist das AWS Strands Agents SDK?
Strands Agents ist ein Open-Source-SDK von AWS unter Apache 2.0 Lizenz zum Bau von KI-Agenten. Es nutzt einen modellgetriebenen Ansatz, bei dem Entwickler nur einen Prompt und eine Tool-Liste definieren und das LLM Planung, Tool-Auswahl und Ausführung autonom übernimmt. Es wird produktiv bei Amazon Q Developer, AWS Glue und VPC Reachability Analyzer eingesetzt.
Wie unterscheidet sich Strands Agents von LangGraph?
LangGraph erfordert explizite Graph-Definitionen mit Knoten und Kanten für Agent-Workflows und bietet mehr deterministische Kontrolle. Strands nutzt einen modellgetriebenen Ansatz, bei dem das LLM den Workflow zur Laufzeit bestimmt. Strands ist schneller beim Prototyping, bietet aber weniger explizite Kontrolle. LangGraph ist besser für komplexe, deterministische Workflows mit garantierten Ausführungspfaden.
Ist Strands Agents nur für AWS nutzbar?
Nein. Trotz AWS-Herkunft unterstützt Strands Agents über 13 Modellanbieter, darunter Anthropic, OpenAI, Google Gemini, Meta Llama, Ollama und lokale Inferenz-Optionen wie Llama.cpp. Der Standard ist AWS Bedrock, aber jeder unterstützte Anbieter kann konfiguriert werden. Deployment ist auch außerhalb von AWS auf Docker, Kubernetes oder beliebigen Servern möglich.
Welche Programmiersprachen unterstützt Strands Agents?
Strands Agents hat offizielle SDKs für Python und TypeScript. Das Python-SDK hat über 14 Millionen Downloads auf PyPI und ist das reifere der beiden, während das TypeScript-SDK etwa 526 GitHub-Stars hat und wächst.
Kann Strands Agents Multi-Agent-Orchestrierung?
Ja. Seit Version 1.0 (Juli 2025) unterstützt Strands vier Multi-Agent-Muster: Agents-as-Tools (spezialisierte Agenten als aufrufbare Tools), Handoffs (kontexterhaltende Übergaben zwischen Agenten), Swarms (autonome Koordination über geteilten Speicher) und Graphs (explizite Workflow-Definitionen mit bedingtem Routing).