Een aangepaste AI-agent bouwen met Anthropic's SDK
De eerste keer dat ik écht begreep wat "agent" betekende — niet de marketingversie, niet het buzzword op elke startup-landingspagina — zat ik drie uur diep in de documentatie van Anthropic's Agent SDK. Het was 23:00 uur op een dinsdagavond. Mijn koffie was koud geworden. Ik had zeventien browsertabbladen open staan. Mijn IDE had een half-gebouwde Python-omgeving die nog niet wilde meewerken.
En ik bleef maar denken: dit is echt anders.
Ik was sceptisch begonnen. Ik had te veel "AI-agent"-demo's gezien die glorified chatbots waren met een toolwrapper er omheen geplakt. Indrukwekkend in een gecontroleerde demo. Nutteloos in productie. Maar de architectuur die Anthropic hier heeft gebouwd — de manier waarop het de control loop beheert, converstatiecontext automatisch bijhoudt, en ontwikkelaars toegang geeft tot dezelfde ingebouwde toolset waarop Claude Code zelf draait — was dat niet. Het was iets wezenlijk anders.
De week daarna bouwde ik een persoonlijke AI-agent die ik Luna noem. Ze integreert met Slack, Gmail, Notion, Chartmogul en App Store Connect. Ze heeft een drielaags geheugensysteem. Ze draait geplande ochtendssamenvattingen en stuurt actie-notificaties naar mijn telefoon voordat ik mijn laptop open. Ze is langzaam — complexe queries kosten 1–2 minuten — maar ze is grondig op een manier die geen snelle chatbot kan evenaren.
Dit artikel behandelt alles wat ik heb geleerd. Inclusief het kostenprobleem dat me oprecht zorgen baarde, de architecturale fout die ik vroeg maakte en me vier dagen herwerk kostte, en waarom ik denk dat de Anthropic Agent SDK het meest significante dat Anthropic voor ontwikkelaars heeft uitgebracht is sinds Claude zelf.
Voordat we ingaan op hoe je dit bouwt, wil ik iets alvast neerleggen: de grootste fout die de meeste ontwikkelaars maken bij het bouwen van agents is geen technische fout. Het is een ontwerpfout. Ik leg precies uit wat het is — en waarom het weken verspilt — zodra we de basis op orde hebben.
Wat een Agent Eigenlijk Is (Schrap het Buzzword)
Elk bedrijf claimt nu dat ze agents hebben. De meesten nemen het erg ruim met de definitie. Een echte agent heeft precies drie componenten. Ze precies begrijpen is wat functionele agents onderscheidt van dure chatbots.
Component één: een LLM. Claude, GPT-4, wat je ook gebruikt. De LLM is de reasoning-engine. Hij leest context, beslist wat er daarna moet gebeuren, en genereert tekst. Dat is het. Hij kan zelf niets uitvoeren. Hij kan geen API's aanroepen. Hij kan geen bestanden lezen. Hij denkt. Meer niet.
Component twee: tools. Functies die de LLM kan aanroepen. Een tool kan zijn "lees deze Gmail-thread", "vraag deze Notion-database op", of "voer dit bash-commando uit". De LLM voert deze niet zelf uit — hij vraagt erom in een gestructureerd formaat, jouw systeem voert ze uit, en de resultaten keren als nieuwe context terug naar de LLM.
Component drie: de loop. Nadat de LLM een tool aanroept en resultaten ontvangt, evalueert hij die resultaten en beslist wat er daarna moet gebeuren. Nog een tool call? Een vervolgvraag? Een definitief antwoord? Deze loop gaat door totdat de taak voltooid is. Dit is wat iets een agent maakt in plaats van een chatbot. Zonder de loop heb je een one-shot tool caller. Met de loop heb je iets dat over tientallen stappen kan redeneren.
Ik maakte vroeg de fout om "meer tools" gelijk te stellen aan "slimmere agent". Dat is precies omgekeerd. Intelligentie zit in de loop. Een goed gestructureerde loop met vijf gerichte tools presteert beter dan een chaotische loop met vijftig. Altijd. Ik heb Luna's toolconfiguratie twee keer herbouwd voordat ik dit echt had geïnternaliseerd.
Dit onderscheid is belangrijk voor wat er daarna komt — omdat de Anthropic Agent SDK fundamenteel een loop-manager is. Alles wat het doet dient de loop: hem betrouwbaar maken, efficiënt, en eenvoudiger te bouwen zonder honderden regels boilerplate te schrijven.
Wat de SDK Werkelijk Doet Wat Niets Anders Zo Goed Doet
Voordat deze SDK bestond, betekende de loop bouwen met de hand boilerplate schrijven: beheer van gespreksgeschiedenis, parsing van tool calls, resultaatopmaak, streaming handlers, retry-logica. Niets hiervan is individueel ingewikkeld. Gecombineerd is het een paar honderd regels code die elke agent-ontwikkelaar net iets anders schreef, waardoor agent-codebases moeilijk te onderhouden of uit te breiden waren.
De SDK comprimeert dat alles tot session-based beheer. Je initialiseert een sessie met een ID, de SDK houdt de conversatie bij, en Claude ontvangt automatisch de juiste context bij elke beurt. Toen ik dit voor het eerst testte, verwachtte ik fragielheid — "automatisch" staatsbeheer in developer-tools betekent gewoonlijk dat het werkt totdat het mysterieus niet meer werkt. Maar na het draaien van sessies van meerdere uren waarbij Luna tientallen opeenvolgende tool calls uitvoerde, ben ik nog geen probleem met contextconsistentie tegengekomen.
De auto-compaction feature deed hem voor mij. Wanneer een gesprek lang genoeg wordt om Claude's contextlimiet te naderen, vat de SDK automatisch oudere delen van het gesprek samen en comprimeert ze. Geen errors. Geen afkapping. Geen handmatige tussenkomst. Voor Luna, waar een enkele werkstroomsessie kan bestaan uit het lezen van twintig e-mails, het controleren van drie databases en het ophalen van bedrijfsstatistieken — is dit niet optioneel. Zonder zou complexe taken halverwege de uitvoering mislukken wanneer ze de limiet bereiken. Mét blijft de agent redeneren zonder onderbreking.
Maar hier is wat ik niet had verwacht: de SDK geeft je agent toegang tot de werkelijke ingebouwde toolset van Claude Code. Niet een vereenvoudigde versie. Dezelfde tools.
De Ingebouwde Tools: Krachtiger dan de Documentatie Doet Vermoeden
De ingebouwde tools van Claude Code zijn productieklaar: bash-uitvoering, bestanden lezen en schrijven, grep en glob voor patroonmatching, geoptimaliseerde webzoekopdrachten en webscraping. Wanneer je de Anthropic Agent SDK gebruikt, krijgt je agent direct toegang tot diezelfde tools.
Laat me specifiek zijn over wat dat betekent: je agent kan shell-commando's uitvoeren, bestanden lezen en schrijven op het bestandssysteem, het web doorzoeken naar actuele informatie, en content scrapen van elke publieke URL. Dit is geen speelgoedfunctionaliteit. Het is dezelfde toolset die Claude Code gebruikt wanneer het ontwikkelaars helpt productiesoftware te schrijven.
Voor Luna elimineerde dit drie aangepaste integraties die ik van plan was te bouwen. De webscraping-mogelijkheid alleen al verving 200 regels aangepaste code die ik voor een vorig project had geschreven. Ik verwijderde die code binnen 24 uur nadat ik de SDK had geconfigureerd.
Hier moet ik de kanttekening plaatsen — want het duurde een volledige dag voordat ik het goed begreep. Bash-uitvoering in een agent is een vertrouwensgrens. Een agent met onbeperkte bash-toegang kan alles wat je gebruikersaccount kan doen: bestanden verwijderen, uitgaande netwerkverzoeken doen, systeembreed packages installeren, systeemconfiguratie wijzigen. Mijn eerste Luna-prototype besloot in een testsessie om een ontbrekende Python-bibliotheek via pip install systeembreed te installeren omdat het die bibliotheek nodig had om een taak te voltooien die ik had opgegeven. Ze had niet ongelijk dat de aanpak zou werken. Maar een geautomatiseerde agent die op mijn laptop draait zou geen systeembrede package-wijzigingen moeten doorvoeren zonder expliciete toestemming.
Dat is de ontwerpfout die ik in de opening noemde — en die geldt ver voorbij bash-toegang. De meeste ontwikkelaars geven hun agent maximale rechten omdat dat eenvoudiger te configureren is. Daarna zijn ze verrast wanneer de agent onverwachte dingen doet. Beperk je tools tot precies wat de agent nodig heeft om zijn gedefinieerde taken uit te voeren. Niets meer. Deze beslissing hoort genomen te worden vóórdat je ook maar één regel implementatiecode schrijft.
Het Skills-systeem: Hoe je Schaalt Zonder Alles te Breken
Naarmate een agent meer mogelijkheden opbouwt, stuit hij op een fundamenteel schaalprobleem: meer tools in context betekent hogere tokenkosten en trager redeneren. Een agent die vijftig tools kent is duurder per verzoek dan een die er vijf kent — zelfs als hij er maar drie van gebruikt.
Het skills-systeem lost dit netjes op. Een skill is een modulaire mogelijkheid gedefinieerd als een map met een metadatabestand en markdown-instructies. De metadata beschrijft in gewone taal wat de skill doet. De agent leest skill-beschrijvingen om te bepalen welke relevant zijn voor de huidige taak, en laadt dan alleen die. Dit is progressieve onthulling — de agent onthult mogelijkheden aan zichzelf selectief, op basis van taakcontext, in plaats van alles vooraf te laden.
Voor Luna heb ik acht skills geconfigureerd: Gmail, Slack, Notion, Chartmogul, App Store Connect, push notifications, bestandsbeheer en webonderzoek. In een typische ochtendssamenvattingssessie worden drie skills geactiveerd. De andere vijf blijven slapend. Voordat ik overstapte naar deze architectuur laadde elke sessie alle acht skill-contexten. Na de overstap daalde de verzoeklatentie met 30–40% en daalde mijn maandelijkse tokengebruik merkbaar.
Het skill-metadatabestand is eenvoudig maar belangrijk om goed te krijgen:
# 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
De beschrijving is wat de agent leest om relevantie te bepalen. Schrijf hem vanuit het perspectief van de agent, niet van de ontwikkelaar. Als de beschrijving niet duidelijk communiceert wanneer de skill gebruikt moet worden, zal de agent hem ofwel te vaak activeren of negeren wanneer dat nodig is.
Hier wordt het skills-systeem bijzonder krachtig: het sluit direct aan op de geheugenarchitectuur. De combinatie van slanke, on-demand skills en een persistente geheugenlaag is wat een persoonlijke agent aanvoelen als echt gepersonaliseerd in plaats van elke-sessie-opnieuw generiek.
Je Eerste Agent Bouwen: De Werkelijke Implementatie
Laat me door de kernstructuur lopen. Dit is vereenvoudigd maar architecturaal nauwkeurig — genoeg om te begrijpen wat je bouwt voordat je begint.
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})
De execute_tool-functie is waar je daadwerkelijke integraties leven. Gmail API-aanroepen. Notion-queries. Chartmogul metric-ophalingen. De agent weet niet en geeft er niet om hoe deze intern werken — hij ziet alleen de resultaten.
Een pro-tip die de moeite waard is om te benadrukken: geef gestructureerde, agent-vriendelijke data terug vanuit je tools, geen ruwe API-responses. Als je Gmail-tool "3 urgente e-mails gevonden: (1) Van: client@domain.com, Onderwerp: Betalingsprobleem, Datum: Vandaag 9:14 AM, Preview: 'We hebben de factuur nog niet ontvangen...'" teruggeeft — redeneert de agent er direct over. Als het ruwe JSON teruggeeft met 40 velden die de agent moet parsen, verbrand je tokens aan parsing die de tool zou moeten afhandelen. Je tools moeten het zware werk doen zodat de agent zich kan richten op redeneren.
Goed — als je het tot hier hebt gered, begrijp je de kernarchitectuur al beter dan de meeste ontwikkelaars die beginnen met het bouwen van agents. Het volgende deel is waar het echt krachtig wordt.
Geheugen dat Echt Werkt: De Drielaagse Architectuur
Standaard agents hebben geheugen als een goudvis. Elke sessie begint opnieuw. De agent weet niet dat jij de voorkeur geeft aan Notion-checklists boven bullet points. Hij herinnert zich niet dat je altijd urgente berichten van klanten als eerste wilt zien. Hij kent de naamgevingsconventie niet die je gebruikt voor projectbestanden.
Voor eenmalige taken is dat prima. Voor een persoonlijk assistent die je ochtendworkflow moet afhandelen, is het een dealbreaker.
De drielaagse architectuur die ik voor Luna bouwde:
Sessiegeheugen is de huidige gesprekscontext — automatisch beheerd door de SDK. Niets te bouwen hier. Het werkt gewoon.
Persistent geheugen is de interessante laag. Deze slaat feiten op die de agent de moeite waard vindt om te bewaren: je voorkeuren, terugkerende patronen, correcties op zijn eigen gedrag. "Mejba geeft de voorkeur aan dagelijkse samenvattingen opgemaakt als geprioriteerde actielijsten, niet als verhalende samenvattingen." "Controleer altijd het App Store Connect-kanaal in Slack voordat je App Store-problemen markeert — dat heeft meestal context." "Het standaard Chartmogul-rapport moet MRR, churnrate en aantal nieuwe klanten bevatten."
Het sleutelgedrag hier: de agent slaat dit proactief op. Hij wacht niet tot jij zegt "onthoud dit". Hij identificeert tijdens normale interacties informatie die het bewaren waard is en schrijft die naar het geheugen met een notitie over waarom. Na twee weken met Luna had ze drieënnegentig persistente geheugenitems. Mijn interacties voelen gepersonaliseerd aan omdat ze mijn patronen echt heeft geleerd.
Archiefgeheugen verwerkt bulkreferentiemateriaal — projectdocumentatie, transcripten van vroegere gesprekken, referentiebestanden die te groot zijn om direct in context te laden. Opgezocht via semantisch zoeken: Luna vraagt het archief op met een beschrijving van wat ze nodig heeft, relevante chunks komen terug. Het wordt nooit in zijn geheel geladen.
Voor de storage backend evalueerde ik Firebase, Supabase en Convex. Ik koos voor Convex om één specifieke reden: real-time sync. Wanneer Luna een actie uitvoert die op mijn iPhone verschijnt — een push notification, een ochtendsamenvatting — is de dataflow: agent-actie → Convex → notificatieservice → telefoon. Met polling-gebaseerde backends zijn er onhandige vertragingen. Met Convex's real-time subscriptions is het instant. Convex verwerkt ook cron-jobs native, wat de geplande ochtendworkflow van Luna aandrijft.
Deployment: De Beslissing die de Meeste Tutorials Negeren
Waar leeft je agent eigenlijk? Deze vraag heeft meer architecturaal gewicht dan hij op het eerste gezicht lijkt te hebben.
Lokale deployment geeft je volledige toegang tot je machine. Voor iMessage-integratie — die geen officiële API heeft en alleen toegankelijk is via AppleScript op macOS — is lokale uitvoering de enige optie. De afweging: je agent draait alleen wanneer je laptop aan en verbonden is. Geplande workflows mislukken op het moment dat het deksel dichtgaat.
Een VPS draait 24/7 en verwerkt elke cloud-toegankelijke integratie netjes: Gmail, Slack, Notion, Chartmogul, App Store Connect. Maar een VPS kan geen AppleScript draaien. Hij kan iMessage of andere Mac-specifieke tools niet aanraken.
Luna gebruikt een gesplitste architectuur. Een VPS verwerkt geplande workflows en alle cloud-platform integraties. Lokale uitvoering verwerkt alles wat Mac-specifiek is. Convex synchroniseert status in real time over beide omgevingen, zodat het vanuit gebruikersperspectief aanvoelt als één continue agent ongeacht welke machine de huidige taak uitvoert.
Het onopgeloste deel — en ik wil hier eerlijk over zijn — is authenticatie voor multi-user deployment. API-sleutels opslaan voor persoonlijk gebruik is eenvoudig: omgevingsvariabelen, versleuteld in rust, klaar. Die sleutels veilig beschikbaar maken voor gebruikers van een product dat je verzendt is een oprecht moeilijk probleem. De naïeve aanpak (credentials in een gedeelde database) creëert beveiligingsblootstelling. De juiste aanpak (per-user OAuth met goede credential-isolatie) voegt weken engineeringwerk toe dat de meeste agent-tutorials niet vermelden omdat ze geen producten bouwen, maar demo's.
Iedereen die van plan is een agent-product te verzenden, zou 2–3x meer tijd moeten budgetteren voor authenticatiearchitectuur dan ze aanvankelijk inschatten.
De Kostenrealiteit waar Niemand de Rekening op Wil Maken
Tegen de huidige Anthropic API-prijzen kost een actieve persoonlijke agent die Claude Opus 4.6 gebruikt met meerdere dagelijkse sessies en complexe multi-tool workflows ongeveer $200–$400 per maand aan API-kosten. Dat is vóór VPS-kosten, databasekosten en externe API-vergoedingen.
Vergelijk dat met een Claude Pro-abonnement van $20/maand. Voor een consument die iets betere resultaten krijgt van een aangepaste agent dan van een Claude Pro-abonnement, werkt de rekensom niet. Helemaal niet.
Dit betekent niet dat agent-producten niet levensvatbaar zijn. Het betekent dat ze momenteel B2B-producten zijn — gevallen waarbij de kosten van de agent klein zijn vergeleken met de waarde die hij genereert. Ik adviseerde over een HIPAA-compliance audit-agent die $50–$100 per rapport kost aan API-aanroepen, maar die compliance-hiaten opspoort die $10.000–$50.000 aan engineeringtijd zouden kosten om handmatig te identificeren. Die rekensom werkt. Een klantenservice-agent die 80% van tier-1-tickets autonoom afhandelt en de personeelskosten met $15.000/maand vermindert — die rekensom werkt.
Voor persoonlijk gebruik met Anthropic's abonnementsplannen: de tokenvergoeding dekt redelijk persoonlijk agent-gebruik. Luna, die mijn dagelijkse workflows draait, blijft ruimschoots binnen de abonnementslimieten. Het probleem duikt alleen op als je je agent als product wilt aanbieden, omdat abonnementsvoordelen niet overdraagbaar zijn aan je gebruikers. Op het moment dat je externe gebruikers wilt bedienen, ben je op API-facturering.
Eerlijke mening: ik bouwde Luna voor persoonlijk gebruik, gesubsidieerd door mijn abonnement. De ervaring is echt uitstekend. Als ik Luna als product zou willen verkopen en consumenten $15/maand zou willen rekenen, werken de unit economics nog niet. Ik bekijk dat opnieuw over 18 maanden naarmate de modelefficiëntie blijft verbeteren.
Consumer agent-producten vereisen ofwel lokale LLM's (nog steeds resource-intensief en niet capabel genoeg voor complexe multi-platform taken) of geduld totdat de prijscurves verder dalen. Beide komen eraan. Geen van beide is vandaag een levensvatbare lanceerstrategie.
Wat er Werkelijk Verandert Wanneer Je Dit Goed Bouwt
Ik ben bewust voorzichtig met productiviteitsclaims omdat de meeste overdreven zijn. Dus laat me je specifieke cijfers geven uit mijn eigen workflow.
Voor Luna: 45–60 minuten elke ochtend voor het bekijken van Slack, scannen van Gmail, ophalen van Chartmogul-statistieken en controleren van App Store Connect-notificaties. De tijd werd niet besteed aan één platform — hij werd besteed aan het wisselen van context tussen al die platforms. Elke wissel brengt cognitieve overhead met zich mee: opnieuw de mentale context van dat platform betreden, uitzoeken wat aandacht nodig heeft, beslissen wat kan wachten.
Na Luna: 8–12 minuten. Luna's ochtendsamenvatting arriveert als een push notification voordat ik mijn laptop open. Twee zaken hebben onmiddellijke aandacht nodig. Vijf hebben een reactie binnen dezelfde dag nodig. Al het andere is gecatalogiseerd en beschikbaar als ik het nodig heb. Ik open mijn laptop met exact de wetenschap waar ik mijn eerste uur aan moet besteden.
Dat is 35–50 minuten per dag teruggewonnen. Over een werkmaand, ruwweg 15 uur. Ik gebruik die uren om dingen te bouwen.
Luna's responstijd van 1–2 minuten voor complexe queries is de echte afweging — en ik wil duidelijk zijn dat het een echte afweging is, geen kleine ongemak. Voor snelle feitelijke vragen is de responstijd frustrerend. Maar voor de taken die Luna werkelijk verwerkt, rechtvaardigt de diepgang het. Wanneer ik haar vraag urgente communicatie over vijf platforms te surfacen, controleert ze werkelijk alle vijf, past ze relevantielogica toe, en synthetiseert het resultaat. Een snellere maar oppervlakkigere agent zou me haar conclusies laten verifiëren, wat het doel tenietdoet.
Het patroon dat de moeite waard is om te internaliseren: bouw snelle agents voor hoog-frequente, laag-complexe taken. Bouw grondige agents voor laag-frequente, hoog-complexe taken. Luna is geoptimaliseerd voor het laatste. Proberen haar snel te maken zou haar oppervlakkig maken, en oppervlakkig verslaat het doel.
Wat er Daarna Komt voor Deze Architectuur
Sub-agents zijn de volgende iteratie die ik actief aan het ontwerpen ben. Luna's huidige architectuur is een enkele agent met meerdere tools. De volgende versie draait specialistische agents — één gericht puur op e-mail en communicatie, één op bedrijfsstatistieken, één op projectbeheer — gecoördineerd door een primaire orchestrerende agent die werk delegeert en resultaten synthetiseert.
Dit weerspiegelt hoe effectieve teams werken. Specialisten voor specifieke domeinen. Een coördinator die de synthese bezit en weet welke specialist te raadplegen. Geen enkele persoon die probeert tegelijkertijd expert te zijn in alles. Hetzelfde principe schaalt netjes naar agents.
Streaming is de ervaringsverbetering die ik het meest enthousiast ben om te implementeren. Op dit moment wacht Luna totdat ze een compleet antwoord heeft voordat ze iets teruggeeft. Streaming zou haar redenering in real time zichtbaar maken — je zou tool calls zien plaatsvinden, tussenresultaten zien ophopen, het beslissingsproces zien ontvouwen. Voor 2-minuten-taken is het zien van een agent die actief werkt dramatisch beter dan het kijken naar een voortgangsspinner.
Directe computerbesturing sluit de laatste grote kloof. Op dit moment is elk platform zonder een API buiten Luna's bereik. Met computerbesturing verdwijnt die beperking — de agent communiceert met elke interface, niet alleen met degenen die programmatische toegang bieden.
Hier laat ik je achter — en dit is een echte uitdaging, geen retorisch middel:
Denk aan één workflow in je huidige dagelijkse routine die drie of meer handmatige stappen vereist over verschillende platforms. Geen hypothetische toekomstige workflow. Iets wat je deze week doet. Misschien is het de voorbereiding vóór je maandagochtend-standup. Misschien is het een wekelijks rapportageproces waarbij je data uit twee tools haalt en opmaakt voor een derde. Misschien is het iets specifiek voor jouw sector.
Dat is je eerste agent. Geen groots visioen. Geen platform-spel. Één afgebakende, specifieke workflow met API-toegankelijke inputs en een heldere definitie van "klaar".
Bouw dat. Zorg dat het werkt. Meet hoeveel tijd het bespaart. Breid dan uit.
De Anthropic Agent SDK is klaar. De architectuur die ik heb beschreven — de loop, het skills-systeem, het drielaagse geheugen, de gesplitste deployment — is bouwbaar door één enkele ontwikkelaar in twee tot drie gefocuste weken. De infrastructuur bestaat. De tooling is echt.
Welke workflow bouw jij als eerste?
🤝 Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur schalen? Ik help je graag.
- 🔗 Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (enterprise-oplossingen): ramlit.com
- 🎨 ColorPark (design & branding): colorpark.io
- 🛡 xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
