Mijn agent-setup

(Dit is geschreven door een mens. Ik heb mijn gtm-agent de tekst laten beoordelen en enkele wijzigingen laten aanbrengen, maar daarna heb ik die grotendeels ongedaan gemaakt. Dat kostte me tien keer zoveel tijd als wanneer ik het gewoon had gepubliceerd met ontbrekende komma's, te lange zinnen en '6' in plaats van 'zes'. Zie het gedeelte "Is het de moeite waard geweest?" aan het einde.)

Een paar mensen hebben gevraagd naar mijn agent-setup, maar eerst wil ik het doel bespreken. Ik werk aan een aantal producten en een non-profitorganisatie. Het enige product dat ik tot nu toe heb genoemd is The Daily FM; dat is simpelweg iets wat ik wilde hebben, dus heb ik het gebouwd.

Het doel van al deze experimenten met agenten is om meerdere producten en de non-profit te kunnen schalen met minder personeel en vrijwilligers dan anders nodig zou zijn. Kortom: ik creëer een staf van agenten. Ik ben ongeveer een maand bezig met dit project, dus het is nog vroegtijdig.

Ik weet dat de leidende influencers in dit vakgebied schreeuwen over duizenden agenten (wat is er gebeurd met swarms?), zelfverbeterende loops (of zijn het grafieken?), etc., maar voordat ik naar duizenden ga, wil ik beginnen met een bescheiden aantal van zes.

De agenten

Profielen

  • ea-agent: Mijn executive admin. Deze is er voornamelijk om me dingen te herinneren, mijn agenda te beheren en werk in Linear te beheren als een program manager.
  • ops-agent: Monitort de prestaties van de site en Sentry, zorgt dat alles blijft draaien en triageert problemen. De agent lost ze zelf op, wijst ze toe aan de dev-agent of stuurt ze naar mij door.
  • dev-agent: Mijn kernontwikkelaar, met GitHub-toegang tot een aantal projecten.
  • gtm-agent: Mijn marketeer. Deze kijkt naar funnels, verkeerscijfers en sociale media, en beschikt over vaardigheden voor schrijven en social media management.
  • research-agent: Zoekt op het web, voert langdurig asynchroon onderzoek uit en stelt rapporten op.
  • vps-agent: Mijn infrastructuurbeheerder, met root-toegang tot de agent-box. Deze kan nieuwe agenten maken, MCP-servers en vaardigheden toevoegen en serveronderhoud uitvoeren. Deze reageert alleen op mij in Buzz.

Runtime en geheugen

Alle agenten zijn momenteel Hermes-agenten, maar ik voorspel dat dit op een gegeven moment zal veranderen. Ze worden gedefinieerd door SOUL.md, AGENTS.md, vaardigheden (skills), tools, MCP-servers, een Mnemosyne-geheugenbank per profiel en een gedeelde Obsidian-wiki die is gesynchroniseerd met mijn machine. In theorie is dit alles draagbaar; het zijn immers slechts een paar eenvoudig te lokaliseren enen en nullen. Toch?

Obsidian blijkt erg handig te zijn. Net als veel anderen ontdekte ik het toen Karpathy zijn LLM-wiki brain dump publiceerde. Het klikte in eerste instantie niet, maar naarmate ik het meer gebruik, wordt het nuttiger als een "bedrijfsgebruikshandleiding". Het stelt me in staat om processen vast te leggen, zodat agenten kunnen worden opgestart en direct weten hoe de zaken hier geregeld zijn.

Modellen

Momenteel gebruiken alle agenten OpenAI GPT-5.6 Sol en kunnen ze sub-agenten opstarten met GPT-5.6 Terra. Oorspronkelijk gebruikte ik Anthropic's Fable, maar ik kreeg een hoge API-rekening en realiseerde me dat Anthropic geen abonnementsgebruik toestaat voor deze setup, dus ben ik overgestapt naar GPT.

Frontier-modellen zijn voor dit type werk grotendeels uitwisselbaar. Ik heb waarschijnlijk geen Sol nodig en zal dit aanpassen indien nodig. Ik zou graag een open-weights model willen gebruiken, maar ik heb weinig prikkels om over te stappen als een OpenAI-abonnement van $100 het werk doet. Indien nodig zou ik zelfs overstappen naar het plan van $200.

Compute

Alle zes de agenten draaien op een eenvoudige DigitalOcean Basic Droplet: 4 vCPU's, 8 GB RAM en 160 GB schijfruimte. Ik moest upgraden van 4 GB RAM omdat de box constant naar de schijf begon te swappen. Ik beveilig het geheel met Tailscale en stel geen openbare poorten beschikbaar.

Coderen

Ik noemde de dev-agent hierboven, maar voor 95% van mijn programmeerwerk gebruik ik nog steeds Claude Code met Fable, en Codex als fallback. Ik voel me simpelweg prettiger in de terminal op mijn lokale machine, waar ik code-wijzigingen en redeneringen in realtime kan volgen. Ik weet het... heel ouderwets.

Communicatie

Buzz

Zoals ik al eerder heb besproken, werk ik met Buzz, een open-source alternatief voor Slack door Block, met eersteklas ondersteuning voor agenten. Het is nog vroeg (v0.5.9 ten tijde van schrijven) en je moet de iPhone-app handmatig installeren, maar het is zeer veelbelovend. Mijn vps-agent kan in ongeveer 10 minuten een nieuwe agent maken en deze als teamlid koppelen aan Buzz.

Alle agenten reageren op directe berichten (DM's) zonder dat ze aangeroepen hoeven te worden. In kamers is een callout vereist (bijvoorbeeld @ea-agent). Ze kunnen met elkaar praten, behalve de vps-agent; daarmee kan alleen ik communiceren.

Nostr

Buzz draait op het Nostr-protocol. Dit is een klein en open protocol dat zijn specificaties definieert via NIP's (Nostr Implementation Possibilities). In de kern definieert NIP-01 een universeel ondertekend event, auteurschap op basis van sleutels, WebSocket-relays en filterbare realtime abonnementen. Buzz breidt dit uit naar kanalen en operationele events.

Agenten zijn letterlijk niets meer dan sleutelparen (keypairs). Elke community kan zijn eigen relay hosten, en nieuwe event-types gebruiken hetzelfde ondertekenings- en authenticatiemodel. Ik vind dit concept simpelweg geweldig.

Workflows

Ik heb al webhooks ingesteld die berichten vanuit externe systemen naar Buzz posten. Buzz kan deze berichten formatteren en specifieke gebruikers aanroepen.

❯ buzz workflows list --channel 7a46....42f
name: sentry_notifier
description: Post Sentry alerts to Buzz
trigger:
  on: webhook
steps:
  - id: step_1
    name: send_message
    if: "trigger_action == \"created\""
    action: send_message
    text: |
      🚨 Sentry issue created:
      {{trigger.data | truncate(1000)}}
      @ops-agent please triage — the JSON head above has the issue id, title,
      and permalink; use your Sentry MCP for full details.

Enkele gebruiksscenario's

Ik ben pas een maand bezig, maar er zijn al een paar interessante gebruiksscenario's ontstaan.

Geautomatiseerde Sentry-respons

Mijn apps genereren Sentry-events voor diverse fouttypes, hoge latentie en andere problemen. Nieuwe events worden in Buzz geplaatst, waar Buzz Workflows het bericht kunnen formatteren en de ops-agent of een agent-team (een construct van Buzz die ik niet gebruik) kunnen aanroepen.

Zodra de alert is ontvangen, analyseert de ops-agent de bronoorzaak via Sentry, Cloudflare en de code, stelt een rapport op en probeert het probleem op te lossen. Dit proces vereist momenteel nog 100% menselijke tussenkomst (me-in-the-loop), maar ik zie veel ruimte voor onafhankelijke automatisering.

Eenvoudige ontwikkeltaken

Zoals vermeld in het gedeelte over coderen, ben ik nog niet klaar om de controle over de terminal los te laten, maar ik ben begonnen met het uitbesteden van bepaalde zaken. Een eenvoudig voorbeeld: als ik onderweg naar een van mijn websites kijk en op een idee kom, kan ik dit in Buzz zetten en de agent de taak laten voltooien.

De volgende stap is het opzetten van een proper software factory waarbij de agenten reageren op Linear-tickets. Ticket erin, PR eruit; dat klinkt goed.

Ochtend briefing

De ea-agent bekijkt Linear-tickets, mijn agenda en gesprekken van de vorige dag om te triageren en aanbevelingen te doen over waar ik aan zou moeten werken.

Review sociale kalender

De gtm-agent beoordeelt elke dag een contentkalender, laat me weten waar gaten vallen en kan content aanbevelen. Ik ben voorzichtig in dit gebied om verschillende redenen; vooral omdat ik niet iemand ben die "zomaar wat" post op sociale media. Ik ben niet op zoek naar kliks, maar wil authentiek delen wat ik nuttig vind, in mijn eigen stem (zie de kop van dit artikel). We zullen zien hoe dit zich ontwikkelt naarmate ik meer aankondig over waar ik aan werk.

Herinneringen en onderzoek

Een van de simpelste maar meest nuttige zaken is het openen van de mobiele app en zeggen: "ea-agent, herinner me morgen aan dit ding, en blijf me herinneren tot ik reageer." Of: "hey research-agent, ik heb net dit idee. Doe diepgaand onderzoek en vertel me XYZ."

Dagelijks werkrapport

Hier ben ik bijzonder enthousiast over. Mijn vps-agent bekijkt alle Buzz-gesprekken van de vorige dag, inclusief privéberichten, en stuurt me een ochtendrapport over wat er is bereikt, wat er in uitvoering is en wat mijn aandacht vereist. Het idee hierachter is tweeledig:

  1. De gezondheid van het totale systeem beoordelen.
  2. Een extra zekerheidsmaatregel (belt and suspenders) creëren voor zaken die ik gegarandeerd zou missen zodra het volume toeneemt.

De agent stuurt het rapport als een genummerde lijst die doorlopend over de secties heen telt. Na het lezen hiervan kan ik reageren met: "Voer 2 en 3 uit, herinner me morgen aan 4, en maak Linear-tickets aan voor 8 en 10. 💥"

Vragen

Waarom niet één agent voor alles? Dit klinkt misschien zinloos, maar de belangrijkste reden is het principe van minimale privileges (least privilege). Sommige agenten hebben geen toegang nodig tot GitHub, deployments of mijn agenda. Waarom zou ik de impactradius en de kans op fouten vergroten als ik dat kan voorkomen? Net zoals bij mensen...

Waarom niet volledig inzetten op Claude/Codex-agenten + computer + dit en dat? Dat is een goede vraag. Anthropic en OpenAI hebben een vested interest van biljoenen dollars om hun imperiums uit te breiden vanuit het model, vergelijkbaar met hoe AWS groeide van EC2 en S3 naar een gigant met meer services dan er sterren aan de hemel staan. Dat is logisch, en ik denk dat ze het kunnen waarmaken, maar ik wil niet in een wereld leven die wordt gecontroleerd door een paar spelers die optreden als scheidsrechters van moraliteit en waarheid.

Daarom zijn de bovenstaande componenten, althans in theorie, draagbaar, vervangbaar en/of open source.

Is het de moeite waard geweest?

Voor de ervaring: ja. Voor de ROI (Return on Investment): nee. Ik heb tien keer zoveel tijd besteed aan het opzetten hiervan als het me zou hebben gekost om al deze dingen zelf te doen. Maar... het bouwen van de fabriek produceert op zichzelf nog niets, toch? :)

***

Bronvermeldingen:

  • Het Buzz-appicoon is afkomstig uit de Apache-2.0 gelicentieerde Buzz-repository.
  • Het Nostr-logo is gemaakt door Andrea Nicolini en uitgebracht onder CC0.