Hoe de agent-vloot bedraad is, in vijf lagen
Van een getypt verzoek tot een gated actie tegen een echt systeem — een wandeling langs de stack die Claude Code omtovert tot een vloot homelab-operators: de CLI, de gedeelde agent-core, de agents, hun skills, en de acties die ze uitvoeren.
We draaien een kleine vloot AI-agents in de homelab — één elk voor systemen, netwerk, security, identity en endpoints. Mensen vragen hoe dat eigenlijk samenhangt: is het één grote prompt? Vijf chatbots? Iets met een queue? Niets daarvan. Het is een korte, doordachte stack, en elk verzoek wandelt langs dezelfde vijf lagen naar beneden — van een zin die ik typ tot een wijziging op een echte box — en daarna wandelen de resultaten weer omhoog.
Hier is het hele verhaal op één pagina.
Laag 1 — de CLI is de orkestrator
Er is geen maatwerk-router of message bus. De voordeur is Claude Code, en die houdt de tools van elke agent al tegelijk vast onder de canonieke mcp__<agent>__<skill>__<tool>-naamgeving. Wanneer ik vraag “is VMID 120 gezond en is zijn image CVE-vrij?”, is Claude Code het ding dat weet dat de infra-agent de eerste helft beantwoordt en de security-agent de tweede. Cross-agent-werk gebeurt hier, één laag boven de agents — niet in bedrading ertussen. Dat houdt de agents onafhankelijk en betekent dat er geen orkestratiecode van mij te onderhouden valt.
Laag 2 — agent-core doet de saaie, moeilijke stukken één keer
Elke agent is een dunne schil rond het gedeelde jitc-agent-core-framework. De streaming chat-loop, prompt caching, de tool-call-loop, de token-gebudgetteerde historiek, de BaseSkill-basisklasse, het laden van config, en de dynamische skill-discovery die het bij het opstarten allemaal aan elkaar knoopt — dat alles leeft op één plek, gepind via commit-SHA in de requirements van elke agent. Niemand kopieert een chat-loop in een agent-repo. Fix één keer een bug in de loop, bump de SHA, en alle vijf de agents erven het.
Laag 3 — een agent is een prompt plus een skill-set
Wat er eigenlijk in een agent-repo zit, is klein: een entry point met een system prompt en een lijst standaard-skills. Dat is de hele persoonlijkheid. De infra-agent kent Proxmox en Docker; de netwerkagent kent UniFi, DNS en Traefik; security kent Wazuh, CVE’s en reputatielookups; identity kent Authentik en Infisical; endpoint kent pakket- en fleetbeheer. Skills worden bij het opstarten ontdekt, en één enkele SKILL_<NAME>=true/false-vlag zet er een aan of uit per deployment. Dezelfde agent draait ook als een MCP-stdio-server zonder API-key nodig — net daarom kan Claude Code in laag 1 hem aanroepen.
Laag 4 — skills zijn waar een tool een backend ontmoet
Een skill is één map: een skill.py die zijn tools declareert (elk een naam, een beschrijving en een JSON Schema), een client.py van zo’n honderd regels standard library tegen een vendor-API, en een config.py. Elke toolnaam krijgt de skill-naam als prefix, zodat er nooit een botsing is over de hele vloot. De regel die hier het meest telt: skills zijn standaard read-only. Een skill levert eerst zijn read-tools; elke tool die de staat wijzigt, zit achter een safety guard — een kill-switch-env-vlag, een two-phase confirm=true, een blast-radius-check — en writes staan uit tenzij je ze bewust aanzet.
Laag 5 — de actie, en de poort ervoor
De bodem van de stack is een echte wijziging op een echt systeem: een VM herstart, een DNS-record geschreven, een agent in quarantaine, een gebruiker uitgeschakeld. Twee dingen zijn op deze laag altijd waar. Een write vuurt nooit op een impliciete “ja” — hij vraagt een expliciete confirm=true nadat de agent je precies heeft getoond wat hij op het punt staat te doen. En elke write wordt gelogd, zodat een sessie terugkoppelt naar een actie die terugkoppelt naar een backend-wijziging. Het leespad is open en snel; het schrijfpad is smal en verantwoordbaar. Die asymmetrie is het volledige veiligheidsmodel.
Waarom het zo gevormd is
Elke laag heeft precies één taak, en de naden ertussen zijn zuiver: de CLI orkestreert, het framework draait de loop, een agent is een prompt, een skill is een getypte tool over een client, en de actie is gated. Je kunt een skill toevoegen zonder het framework aan te raken, een agent toevoegen zonder de andere aan te raken, en redeneren over “kan dit ding mijn infrastructuur wijzigen?” door naar één enkele laag te kijken. Het is minder slim dan een mesh van agents die met elkaar praten — en dat is net het punt. De saaie stack is degene die ik vertrouw om een write-token vast te houden.
(Een begeleidend stuk, Skills, MCP en waar de credentials thuishoren, graaft in de laag onder deze: hoe die backend-credentials gebrokerd zouden moeten worden in plaats van geparkeerd in een .env.)