Einen eigenen KI-Agenten mit Anthropics SDK bauen
Das erste Mal, dass ich wirklich verstand, was "agent" bedeutet — nicht die Marketingversion, nicht das Buzzword auf der Landingpage jedes Startups — saß ich drei Stunden tief in Anthropics Agent SDK-Dokumentation. Es war 23 Uhr an einem Dienstagabend. Mein Kaffee war kalt geworden. Ich hatte siebzehn Browser-Tabs offen. Meine IDE hatte eine halb aufgebaute Python-Umgebung, die noch nicht mitmachen wollte.
Und ich dachte immer wieder: Das ist wirklich anders.
Ich war skeptisch hineingegangen. Ich hatte zu viele "KI-Agenten"-Demos gesehen, die glorifizierte Chatbots mit einer toolwrapper daraufgeklebt waren. Beeindruckend in einer kontrollierten Demo. Nutzlos in der Produktion. Aber die Architektur, die Anthropic hier gebaut hat — die Art, wie sie die control loop verwaltet, den Gesprächskontext automatisch handhabt und Entwicklern Zugang zu derselben eingebauten Toolset gibt, auf der Claude Code selbst läuft — war das nicht. Es war etwas bedeutsam anderes.
Die darauffolgende Woche verbrachte ich damit, einen persönlichen KI-Agenten zu bauen, den ich Luna nenne. Sie integriert sich mit Slack, Gmail, Notion, Chartmogul und App Store Connect. Sie hat ein dreilagiges Gedächtnissystem. Sie führt geplante Morgenzusammenfassungen aus und liefert Aktionspunkt-Benachrichtigungen auf mein Telefon, bevor ich meinen Laptop öffne. Sie ist langsam — komplexe Queries dauern 1–2 Minuten — aber sie ist gründlich auf eine Weise, die keine schnelle Chatbot-Antwort erreichen kann.
Dieser Beitrag behandelt alles, was ich gelernt habe. Einschließlich des Kostenproblems, das mich wirklich besorgte, des architekturalen Fehlers, den ich früh machte und der mich vier Tage Nacharbeit kostete, und warum ich denke, dass das Anthropic Agent SDK das Bedeutendste ist, was Anthropic für Entwickler veröffentlicht hat, seit Claude selbst.
Bevor wir uns damit befassen, wie man das baut, möchte ich hier etwas vorwegnehmen: Der größte Fehler, den die meisten Entwickler beim Bauen von Agents machen, ist kein technischer Fehler. Es ist ein Designfehler. Ich erkläre genau, was es ist — und warum es Wochen verschwendet — sobald wir das Fundament gelegt haben.
Was ein Agent Wirklich Ist (Das Buzzword Wegstreifen)
Jedes Unternehmen behauptet jetzt, Agents zu haben. Die meisten nehmen es sehr großzügig mit der Definition. Ein echter Agent hat genau drei Komponenten. Sie präzise zu verstehen ist das, was funktionierende Agents von teuren Chatbots unterscheidet.
Komponente eins: ein LLM. Claude, GPT-4, was auch immer du verwendest. Der LLM ist die Reasoning-Engine. Er liest Kontext, entscheidet, was als nächstes zu tun ist, und generiert Text. Das ist es. Er kann nichts selbst ausführen. Er kann keine APIs aufrufen. Er kann keine Dateien lesen. Er denkt. Nichts mehr.
Komponente zwei: tools. Funktionen, die der LLM aufrufen kann. Ein tool könnte "lies diesen Gmail-Thread", "frage diese Notion-Datenbank ab" oder "führe diesen bash-Befehl aus" sein. Der LLM führt diese nicht aus — er fordert sie in einem strukturierten Format an, dein System führt sie aus, und die Ergebnisse kehren als neuer Kontext zum LLM zurück.
Komponente drei: die loop. Nachdem der LLM ein tool aufruft und Ergebnisse erhält, wertet er diese Ergebnisse aus und entscheidet, was als nächstes zu tun ist. Ein weiterer tool call? Eine Folgeanfrage? Eine endgültige Antwort? Diese loop setzt sich fort, bis die Aufgabe abgeschlossen ist. Das macht etwas zu einem agent und nicht zu einem Chatbot. Ohne die loop hast du einen one-shot tool caller. Mit der loop hast du etwas, das über Dutzende von Schritten hinweg schlussfolgern kann.
Ich machte früh den Fehler, "mehr tools" mit "schlauerer agent" gleichzusetzen. Das ist genau umgekehrt. Intelligenz lebt in der loop. Eine gut strukturierte loop mit fünf fokussierten tools übertrifft eine chaotische loop mit fünfzig. Immer. Ich baute Lunas toolkonfiguration zweimal um, bevor ich das wirklich verinnerlicht hatte.
Diese Unterscheidung ist wichtig für das, was als nächstes kommt — denn das Anthropic Agent SDK ist fundamental ein loop-Manager. Alles, was es tut, dient der loop: sie zuverlässig, effizient und einfacher zu bauen zu machen, ohne Hunderte von Zeilen Boilerplate zu schreiben.
Was das SDK Wirklich Tut, Was Sonst Niemand Ganz Richtig Macht
Bevor dieses SDK existierte, bedeutete den loop zu bauen, Boilerplate von Hand zu schreiben: Verwaltung der Gesprächshistorie, Parsing von tool calls, Ergebnisformatierung, streaming handler, Retry-Logik. Nichts davon ist einzeln kompliziert. Kombiniert sind es mehrere hundert Zeilen Code, die jeder agent-Entwickler etwas anders schrieb, was agent-Codebasen schwer wartbar oder erweiterbar machte.
Das SDK komprimiert das alles zu session-basiertem Management. Du initialisierst eine Sitzung mit einer ID, das SDK verfolgt das Gespräch, und Claude erhält bei jeder Runde automatisch den richtigen Kontext. Als ich das zum ersten Mal testete, erwartete ich Zerbrechlichkeit — "automatisches" Zustandsmanagement in Entwicklertools bedeutet normalerweise, dass es funktioniert, bis es auf mysteriöse Weise nicht mehr tut. Aber nach dem Betrieb von mehrstündigen Sitzungen, in denen Luna Dutzende von sequentiellen tool calls ausführte, bin ich auf kein Kontextkonsistenzproblem gestoßen.
Das auto-compaction Feature besiegelte es für mich. Wenn ein Gespräch lang genug wird, um Claudes Kontextlimit zu nähern, fasst das SDK automatisch ältere Teile des Gesprächs zusammen und komprimiert sie. Keine Fehler. Keine Kürzung. Kein manuelles Eingreifen. Für Luna, wo eine einzelne Workflow-Sitzung das Lesen von zwanzig E-Mails, die Überprüfung von drei Datenbanken und das Abrufen von Geschäftskennzahlen umfassen kann — ist das keine Option. Ohne würden komplexe Aufgaben mitten in der Ausführung scheitern, wenn sie das Limit erreichen. Damit denkt der agent weiter, ohne Unterbrechung.
Aber hier ist, was ich nicht erwartet hatte: Das SDK gibt deinem agent Zugang zur tatsächlichen eingebauten Toolset von Claude Code. Nicht eine vereinfachte Version. Die gleichen tools.
Die Eingebauten Tools: Mächtiger als die Dokumentation Vermuten Lässt
Die eingebauten tools von Claude Code sind produktionsreif: bash-Ausführung, Lesen und Schreiben von Dateien, grep und glob für Musterabgleich, optimierte Websuche und Web-Scraping. Wenn du das Anthropic Agent SDK verwendest, erhält dein agent sofort Zugang zu diesen gleichen tools.
Lass mich spezifisch sein, was das bedeutet: Dein agent kann Shell-Befehle ausführen, Dateien im Dateisystem lesen und schreiben, das Web nach aktuellen Informationen durchsuchen und Inhalte von jeder öffentlichen URL scrapen. Das ist keine Spielzeugfunktionalität. Es ist die gleiche Toolset, die Claude Code verwendet, wenn es Entwicklern hilft, Produktionssoftware zu schreiben.
Für Luna eliminierte das drei benutzerdefinierte Integrationen, die ich zu bauen geplant hatte. Die Web-Scraping-Fähigkeit allein ersetzte 200 Zeilen benutzerdefinierten Code, den ich für ein früheres Projekt geschrieben hatte. Ich löschte diesen Code innerhalb von 24 Stunden nach dem Konfigurieren des SDKs.
Hier muss ich den Vorbehalt erwähnen — denn es dauerte einen ganzen Tag, bis ich es richtig lernte. bash-Ausführung in einem agent ist eine Vertrauensgrenze. Ein agent mit uneingeschränktem bash-Zugang kann alles tun, was dein Benutzerkonto tun kann: Dateien löschen, ausgehende Netzwerkanfragen stellen, systemweit Pakete installieren, Systemkonfiguration ändern. Mein erstes Luna-Prototyp entschied in einer Testsitzung, eine fehlende Python-Bibliothek über pip install systemweit zu installieren, weil er diese Bibliothek brauchte, um eine Aufgabe zu erledigen, die ich ihm gegeben hatte. Sie hatte nicht unrecht, dass der Ansatz funktionieren würde. Aber ein automatisierter agent, der auf meinem Laptop läuft, sollte keine systemweiten Paketänderungen vornehmen ohne explizite Genehmigung.
Das ist der Designfehler, den ich in der Einleitung erwähnte — und er gilt weit über bash-Zugang hinaus. Die meisten Entwickler geben ihrem agent maximale Berechtigungen, weil das einfacher zu konfigurieren ist. Dann sind sie überrascht, wenn der agent unerwartete Dinge tut. Begrenze deine tools auf genau das, was der agent braucht, um seine definierten Aufgaben zu erfüllen. Nichts mehr. Diese Entscheidung sollte getroffen werden, bevor du eine einzige Zeile Implementierungscode schreibst.
Das Skills-System: Wie Du Skalierst Ohne Alles zu Zerstören
Wenn ein agent Fähigkeiten ansammelt, trifft er auf ein grundlegendes Skalierungsproblem: Mehr tools im Kontext bedeuten höhere Token-Kosten und langsameres Schlussfolgern. Ein agent, der sich fünfzig tools bewusst ist, ist teurer pro Anfrage als einer, der fünf kennt — auch wenn er nur drei davon jemals verwendet.
Das skills-System löst das sauber. Ein skill ist eine modulare Fähigkeit, die als Ordner mit einer Metadatendatei und markdown-Anweisungen definiert wird. Die Metadaten beschreiben in einfacher Sprache, was der skill macht. Der agent liest skill-Beschreibungen, um zu bestimmen, welche für die aktuelle Aufgabe relevant sind, und lädt dann nur diese. Das ist progressive Enthüllung — der agent enthüllt Fähigkeiten selektiv für sich selbst, basierend auf dem Aufgabenkontext, anstatt alles im Voraus zu laden.
Für Luna habe ich acht skills konfiguriert: Gmail, Slack, Notion, Chartmogul, App Store Connect, push notifications, Dateiverwaltung und Web-Recherche. In einer typischen Morgenzusammenfassungssitzung werden drei skills aktiviert. Die anderen fünf bleiben ruhend. Bevor ich auf diese Architektur wechselte, lud jede Sitzung alle acht skill-Kontexte. Nach dem Wechsel sank die Anfrage-Latenz um 30–40% und meine monatliche Token-Nutzung fiel merklich.
Die skill-Metadatendatei ist einfach, aber wichtig, richtig zu machen:
# Gmail Skill
## Description
Search, read, and analyze Gmail messages. Use when the user needs to check email,
find specific messages, or review communication threads.
## When to activate
- User asks about emails or messages
- Task requires checking inbox for updates
- User mentions checking communication or correspondence
## Capabilities
- Search Gmail with query syntax
- Read full email threads
- Extract sender, subject, date, and body content
- Identify urgency signals in messages
Die Beschreibung ist das, was der agent liest, um Relevanz zu bestimmen. Schreibe sie aus der Perspektive des agents, nicht des Entwicklers. Wenn die Beschreibung nicht klar kommuniziert, wann der skill verwendet werden soll, wird der agent ihn entweder zu oft aktivieren oder ignorieren, wenn er gebraucht wird.
Hier wird das skills-System besonders leistungsstark: Es verbindet sich direkt mit der Gedächtnisarchitektur. Die Kombination aus schlanken, bedarfsgesteuerten skills und einer persistenten Gedächtnisschicht ist das, was einen persönlichen agent wirklich personalisiert anfühlen lässt, anstatt jede-Sitzung-von-vorne generisch.
Deinen Ersten Agent Bauen: Die Tatsächliche Implementierung
Lass mich die Kernstruktur durchgehen. Das ist vereinfacht, aber architektonisch genau — genug, um zu verstehen, was du baust, bevor du anfängst.
import anthropic
from anthropic import Anthropic
client = Anthropic()
# Define your tools as structured schemas
tools = [
{
"name": "search_gmail",
"description": "Search Gmail for emails matching a query. Returns sender, subject, date, and body preview.",
"input_schema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Gmail search query (supports standard Gmail operators)"
},
"max_results": {
"type": "integer",
"description": "Maximum number of results to return. Default: 10"
}
},
"required": ["query"]
}
},
{
"name": "get_slack_messages",
"description": "Retrieve recent messages from a specified Slack channel.",
"input_schema": {
"type": "object",
"properties": {
"channel": {
"type": "string",
"description": "Slack channel name or ID"
},
"hours": {
"type": "integer",
"description": "How many hours back to retrieve messages"
}
},
"required": ["channel"]
}
}
]
def run_agent_loop(session_id: str, user_message: str, conversation_history: list):
"""Core agent loop: think → tool call → result → repeat until done."""
messages = conversation_history + [{"role": "user", "content": user_message}]
while True:
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=4096,
tools=tools,
messages=messages
)
# Agent has reached a final answer
if response.stop_reason == "end_turn":
final_text = next(
(block.text for block in response.content if hasattr(block, "text")),
""
)
return final_text, messages
# Agent wants to call one or more tools
if response.stop_reason == "tool_use":
tool_results = []
for block in response.content:
if block.type == "tool_use":
# Execute the requested tool
result = execute_tool(block.name, block.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": str(result)
})
# Append agent's response and tool results, continue loop
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": tool_results})
Die execute_tool-Funktion ist, wo deine tatsächlichen Integrationen leben. Gmail API-Aufrufe. Notion-Queries. Chartmogul-Metric-Abfragen. Der agent weiß nicht und kümmert sich nicht darum, wie diese intern funktionieren — er sieht nur die Ergebnisse.
Ein Pro-Tipp, der es wert ist hervorzuheben: Gib strukturierte, agent-freundliche Daten aus deinen tools zurück, keine rohen API-Antworten. Wenn dein Gmail-tool "3 dringende E-Mails gefunden: (1) Von: client@domain.com, Betreff: Zahlungsproblem, Datum: Heute 9:14 Uhr, Vorschau: 'Wir haben die Rechnung noch nicht erhalten...'" zurückgibt — schlussfolgert der agent sofort darüber. Wenn es rohes JSON mit 40 Feldern zurückgibt, die der agent parsen muss, verbrennst du Token für das Parsing, das das tool übernehmen sollte. Deine tools sollten die schwere Arbeit tun, damit der agent sich auf das Schlussfolgern konzentrieren kann.
Gut — wenn du es bis hierhin geschafft hast, verstehst du die Kernarchitektur bereits besser als die meisten Entwickler, die anfangen, Agents zu bauen. Der nächste Teil ist, wo es wirklich leistungsstark wird.
Gedächtnis, das Wirklich Funktioniert: Die Dreilagige Architektur
Standard-Agents haben Goldfischgedächtnis. Jede Sitzung beginnt frisch. Der agent weiß nicht, dass du Notion-Checklisten gegenüber Bullet-Points bevorzugst. Er erinnert sich nicht daran, dass du immer dringende Kundennachrichten zuerst angezeigt haben möchtest. Er kennt die Namenskonvention nicht, die du für Projektdateien verwendest.
Für einmalige Aufgaben ist das in Ordnung. Für einen persönlichen Assistenten, der deinen morgendlichen Workflow abwickeln soll, ist es ein Dealbreaker.
Die dreilagige Architektur, die ich für Luna gebaut habe:
Sitzungsgedächtnis ist der aktuelle Gesprächskontext — automatisch vom SDK verwaltet. Hier ist nichts zu bauen. Es funktioniert einfach.
Persistentes Gedächtnis ist die interessante Schicht. Hier werden Fakten gespeichert, die der agent für aufbewahrungswürdig hält: deine Präferenzen, wiederkehrende Muster, Korrekturen an seinem eigenen Verhalten. "Mejba bevorzugt tägliche Zusammenfassungen, die als priorisierte Aktionslisten formatiert sind, nicht als narrative Zusammenfassungen." "Prüfe immer den App Store Connect-Kanal in Slack, bevor du App Store-Probleme markierst — dort ist normalerweise Kontext." "Der Standard-Chartmogul-Bericht sollte MRR, Churnrate und Anzahl neuer Kunden enthalten."
Das Schlüsselverhalten hier: Der agent speichert das proaktiv. Er wartet nicht darauf, dass du "merke dir das" sagst. Er identifiziert während normaler Interaktionen aufbewahrungswürdige Informationen und schreibt sie ins Gedächtnis mit einer Notiz, warum. Nach zwei Wochen mit Luna hatte sie dreiundneunzig persistente Gedächtniseinträge. Meine Interaktionen fühlen sich personalisiert an, weil sie meine Muster tatsächlich gelernt hat.
Archivgedächtnis verarbeitet umfangreiches Referenzmaterial — Projektdokumentation, vergangene Gesprächstranskripte, Referenzdateien, die zu groß sind, um direkt in den Kontext geladen zu werden. Abgerufen durch semantische Suche: Luna fragt das Archiv mit einer Beschreibung dessen ab, was sie braucht, relevante Chunks kommen zurück. Es wird nie vollständig geladen.
Für das Storage-Backend evaluierte ich Firebase, Supabase und Convex. Ich entschied mich für Convex aus einem spezifischen Grund: Echtzeitsynchronisierung. Wenn Luna eine Aktion ausführt, die auf meinem iPhone erscheint — eine push notification, eine Morgenzusammenfassung — ist der Datenfluss: agent-Aktion → Convex → Benachrichtigungsdienst → Telefon. Bei polling-basierten Backends gibt es unangenehme Verzögerungen. Mit Convexs Echtzeit-Subscriptions ist es sofort. Convex verarbeitet auch cron-Jobs nativ, was Lunas geplanten Morgen-Workflow antreibt.
Deployment: Die Entscheidung, die die Meisten Tutorials Ignorieren
Wo lebt dein agent eigentlich? Diese Frage hat mehr architektonisches Gewicht, als es zunächst scheint.
Lokales Deployment gibt dir vollen Zugriff auf deine Maschine. Für iMessage-Integration — die keine offizielle API hat und nur über AppleScript auf macOS zugänglich ist — ist lokale Ausführung die einzige Option. Der Kompromiss: dein agent läuft nur, wenn dein Laptop eingeschaltet und verbunden ist. Geplante Workflows scheitern in dem Moment, in dem der Deckel zugeklappt wird.
Ein VPS läuft 24/7 und verarbeitet jede cloud-zugängliche Integration sauber: Gmail, Slack, Notion, Chartmogul, App Store Connect. Aber ein VPS kann kein AppleScript ausführen. Er kann iMessage oder andere Mac-spezifische tools nicht berühren.
Luna verwendet eine geteilte Architektur. Ein VPS verarbeitet geplante Workflows und alle Cloud-Plattform-Integrationen. Lokale Ausführung verarbeitet alles Mac-Spezifische. Convex synchronisiert den Status in Echtzeit über beide Umgebungen, sodass es sich aus Nutzerperspektive wie ein kontinuierlicher agent anfühlt, unabhängig davon, welche Maschine die aktuelle Aufgabe ausführt.
Der ungelöste Teil — und ich möchte hier ehrlich sein — ist Authentifizierung für Multi-User-Deployment. API-Schlüssel für den persönlichen Gebrauch zu speichern ist unkompliziert: Umgebungsvariablen, verschlüsselt in Ruhe, fertig. Diese Schlüssel sicher für Benutzer eines Produkts, das du veröffentlichst, verfügbar zu machen, ist ein wirklich schwieriges Problem. Der naive Ansatz (Anmeldedaten in einer gemeinsamen Datenbank) schafft Sicherheitsrisiken. Der richtige Ansatz (per-User OAuth mit ordentlicher Credential-Isolation) fügt Wochen Ingenieurarbeit hinzu, die die meisten agent-Tutorials nicht erwähnen, weil sie keine Produkte bauen, sondern Demos.
Jeder, der plant, ein agent-Produkt zu veröffentlichen, sollte 2–3x mehr Zeit für die Authentifizierungsarchitektur einplanen als zunächst geschätzt.
Die Kostenrealität, die Niemand Durchrechnen Will
Zu den aktuellen Anthropic API-Preisen kostet ein aktiver persönlicher agent, der Claude Opus 4.6 mit mehreren täglichen Sitzungen und komplexen Multi-Tool-Workflows verwendet, ungefähr 200–400 $ pro Monat an API-Kosten. Das ist vor VPS-Kosten, Datenbankkosten und Drittanbieter-API-Gebühren.
Vergleiche das mit einem Claude Pro-Abonnement für 20 $/Monat. Für einen Verbraucher, der etwas bessere Ergebnisse von einem benutzerdefinierten agent erhält als von einem Claude Pro-Abonnement, funktioniert die Rechnung nicht. Überhaupt nicht.
Das bedeutet nicht, dass agent-Produkte nicht lebensfähig sind. Es bedeutet, dass sie derzeit B2B-Produkte sind — Fälle, in denen die Kosten des agents im Vergleich zum generierten Wert gering sind. Ich beriet bei einem HIPAA-Compliance-Audit-agent, der 50–100 $ pro Bericht an API-Aufrufen kostet, aber Compliance-Lücken findet, die 10.000–50.000 $ an Ingenieurzeit kosten würden, um sie manuell zu identifizieren. Diese Rechnung funktioniert. Ein Kundensupport-agent, der 80% der Tier-1-Tickets autonom bearbeitet und die Personalkosten um 15.000 $/Monat reduziert — diese Rechnung funktioniert.
Für den persönlichen Gebrauch mit Anthropics Abonnementplänen: Die Token-Zuteilung deckt einen angemessenen persönlichen agent-Einsatz ab. Luna, die meine täglichen Workflows ausführt, bleibt gut innerhalb der Abonnementlimits. Das Problem taucht nur auf, wenn du deinen agent als Produkt anbieten möchtest, da Abonnementvorteile nicht auf deine Benutzer übertragbar sind. In dem Moment, in dem du externe Benutzer bedienen möchtest, bist du auf API-Abrechnung.
Ehrliche Einschätzung: Ich baute Luna für den persönlichen Gebrauch, subventioniert durch mein Abonnement. Die Erfahrung ist wirklich ausgezeichnet. Wenn ich Luna als Produkt vermarkten und Verbrauchern 15 $/Monat berechnen wollte, funktionieren die Unit-Economics noch nicht. Ich überprüfe das in 18 Monaten wieder, wenn die Modelleffizienz weiter verbessert wird.
Consumer-agent-Produkte erfordern entweder lokale LLMs (immer noch ressourcenintensiv und nicht fähig genug für komplexe Multi-Plattform-Aufgaben) oder Geduld, bis die Preiskurven weiter fallen. Beides kommt. Keines ist heute eine tragfähige Startstrategie.
Was Sich Wirklich Ändert, Wenn Du Das Richtig Baust
Ich bin bewusst vorsichtig mit Produktivitätsbehauptungen, weil die meisten übertrieben sind. Also lass mich dir spezifische Zahlen aus meinem eigenen Workflow geben.
Vor Luna: 45–60 Minuten jeden Morgen für die Überprüfung von Slack, das Scannen von Gmail, das Abrufen von Chartmogul-Kennzahlen und die Überprüfung von App Store Connect-Benachrichtigungen. Die Zeit wurde nicht auf einer einzigen Plattform verbracht — sie wurde damit verbracht, zwischen all diesen zu wechseln. Jeder Wechsel bringt kognitive Mehrbelastung mit sich: wieder in den mentalen Kontext dieser Plattform eintreten, herausfinden, was Aufmerksamkeit braucht, entscheiden, was warten kann.
Nach Luna: 8–12 Minuten. Lunas Morgenzusammenfassung kommt als push notification an, bevor ich meinen Laptop öffne. Zwei Punkte brauchen sofortige Aufmerksamkeit. Fünf brauchen eine Antwort am gleichen Tag. Alles andere ist katalogisiert und verfügbar, wenn ich es brauche. Ich öffne meinen Laptop und weiß genau, wo ich meine erste Stunde verbringen soll.
Das sind 35–50 Minuten täglich zurückgewonnen. Über einen Arbeitsmonat, ungefähr 15 Stunden. Diese Stunden verwende ich damit, Dinge zu bauen.
Lunas Antwortzeit von 1–2 Minuten für komplexe Queries ist der echte Kompromiss — und ich möchte deutlich sein, dass es ein echter Kompromiss ist, keine kleine Unannehmlichkeit. Für schnelle Sachfragen ist die Antwortzeit frustrierend. Aber für die Aufgaben, die Luna tatsächlich übernimmt, rechtfertigt die Tiefe das. Wenn ich sie bitte, dringende Kommunikation über fünf Plattformen zu zeigen, prüft sie wirklich alle fünf, wendet Relevanzlogik an und synthetisiert das Ergebnis. Ein schnellerer, aber oberflächlicherer agent würde von mir verlangen, seine Schlussfolgerungen zu überprüfen, was den Zweck zunichte macht.
Das Muster, das es wert ist zu verinnerlichen: Baue schnelle Agents für hochfrequente, niedrigkomplexe Aufgaben. Baue gründliche Agents für niedrigfrequente, hochkomplexe Aufgaben. Luna ist für letzteres optimiert. Sie schneller zu machen würde sie oberflächlich machen, und oberflächlich macht den Zweck zunichte.
Was Als Nächstes für Diese Architektur Kommt
Sub-agents sind die nächste Iteration, die ich aktiv entwerfe. Lunas aktuelle Architektur ist ein einzelner agent mit mehreren tools. Die nächste Version betreibt Spezialistenagenten — einen, der sich rein auf E-Mail und Kommunikation konzentriert, einen auf Geschäftskennzahlen, einen auf Projektmanagement — koordiniert von einem primären orchestrierenden agent, der Arbeit delegiert und Ergebnisse synthetisiert.
Das spiegelt wider, wie effektive Teams arbeiten. Spezialisten für spezifische Domänen. Ein Koordinator, der die Synthese besitzt und weiß, welchen Spezialisten er konsultieren soll. Keine einzelne Person, die versucht, gleichzeitig in allem Experte zu sein. Das gleiche Prinzip skaliert sauber auf Agents.
Streaming ist die Erfahrungsverbesserung, die ich am meisten freue mich zu implementieren. Im Moment wartet Luna, bis sie eine vollständige Antwort hat, bevor sie etwas zurückgibt. Streaming würde ihr Schlussfolgern in Echtzeit zeigen — man würde tool calls passieren sehen, Zwischenergebnisse anhäufen sehen, den Entscheidungsprozess sich entfalten sehen. Bei 2-Minuten-Aufgaben ist es dramatisch besser, einen agent aktiv arbeiten zu sehen, als auf einen Fortschrittskreisel zu schauen.
Direkte Computersteuerung schließt die letzte große Lücke. Im Moment liegt jede Plattform ohne API außerhalb von Lunas Reichweite. Mit Computersteuerung verschwindet diese Einschränkung — der agent interagiert mit jeder Oberfläche, nicht nur mit solchen, die programmatischen Zugang bieten.
Hier lasse ich dich — und das ist eine echte Herausforderung, kein rhetorisches Mittel:
Denk an einen Workflow in deiner aktuellen täglichen Routine, der drei oder mehr manuelle Schritte über verschiedene Plattformen hinweg erfordert. Keinen hypothetischen zukünftigen Workflow. Etwas, das du diese Woche tust. Vielleicht ist es die Vorbereitung vor deinem Montagmorgen-Standup. Vielleicht ist es ein wöchentlicher Berichtsprozess, bei dem du Daten aus zwei tools holst und für ein drittes formatierst. Vielleicht ist es etwas Spezifisches für deine Branche.
Das ist dein erster agent. Keine große Vision. Kein Plattform-Spiel. Ein begrenzter, spezifischer Workflow mit API-zugänglichen Eingaben und einer klaren Definition von "fertig".
Bau das. Bring es zum Laufen. Miss, wie viel Zeit es spart. Dann erweitere.
Das Anthropic Agent SDK ist bereit. Die Architektur, die ich beschrieben habe — die loop, das skills-System, das dreilagige Gedächtnis, das geteilte Deployment — ist von einem einzelnen Entwickler in zwei bis drei fokussierten Wochen baubar. Die Infrastruktur existiert. Das Tooling ist real.
Welchen Workflow baust du zuerst?
🤝 Lass uns zusammenarbeiten
Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne dabei.
- 🔗 Fiverr (individuelle Entwicklungen & Integrationen): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (Enterprise-Lösungen): ramlit.com
- 🎨 ColorPark (Design & Branding): colorpark.io
- 🛡 xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
