De meeste teams behandelen een coding agent nog als een eenmalig chatvenster: terminal openen, koud proces starten, de volle contextprijs betalen en de sessie weggooien. Wij wilden iets dat meer lijkt op hoe we productie-infrastructuur al draaien — een langlevende dienst die je kunt aanroepen vanuit schedules, scripts en (binnenkort) elke browser op het LAN.
Die week hebben we dat patroon in onze eigen stack gezet: een duurzame coding agent, een dunne ACP-client (Agent Client Protocol), en de eerste koppelingen zodat myawx-geplande jobs dezelfde agent kunnen bereiken in plaats van Grok bij elke run koud te starten.
Waarom een lange sessie wint van een koude start
Start je voor elke job een volledige agent-binary, dan betaal je steeds opnieuw voor configuratie, tools en de eerste beurten die alleen session continuity herstellen. Voor interactief werk is dat irritant. Voor automatisering is het verspilling: hogere token cost, tragere jobs, en minder kans om een nuttige prompt cache warm te houden over samenhangende taken.
Een model met een long session draait het om. Houd één agentproces draaiende waar het werk al leeft — naast deploy-tooling, Git en ons interne control plane — en laat kortlevende clients koppelen, een prompt sturen, een resultaat streamen en weer weggaan. Het zware proces blijft staan; de clients blijven dun.
ACP: een echt clientprotocol, geen nieuwe chat-silo
We standaardiseren op het open Agent Client Protocol (ACP): JSON-RPC-sessies over WebSocket (of stdio in een editor). Zelfde familie als language servers — een heldere grens client/agent — in plaats van een gesloten UI van één leverancier.
Bij ons betekent dat:
- Een langlevende Grok Build-agentservice (systemd), altijd beschikbaar voor automatisering.
- Een kleine open acp-CLI (stdlib Python) voor shells, cron en jobs: verbinden, prompten, printen, afsluiten.
- Experimenten met desktop-ACP-UI’s voor interactief gebruik — handig voor een snelle check, niet de ruggengraat van operations.
We hebben ook de publieke Grok / Grok Build-broncode gekloond en bestudeerd waar die open beschikbaar is. Die transparantie telt voor AI engineering op infrastructuur die we zelf draaien: we zien hoe serve-modus, sessies en tools bedoeld zijn, in plaats van te gokken op een black box.
myawx-schedules die Grok al aanroepen
Onze interne orchestrator — myawx — vuurt al terugkerend werk af: mirror-onderhoud, mail-gedreven taken, incident-opvolging, contentdesk-batches en andere fleet-klussen. Sommige van die schedules geven al een brief aan Grok wanneer een mens anders dezelfde checklist in een terminal zou plakken.
Tot nu toe startten veel van die paden per run een volledige agent koud. We verplaatsen ze naar de langlevende agent via de ACP-CLI, zodat een geplande job “stuur dit briefje naar de draaiende agent” is in plaats van “boot het universum en stel dan één vraag.” Dat houdt session continuity waar het helpt, snijdt overbodige startup weg, en laat het automatiseringspad lijken op het interactieve pad.
Niet elke job heeft een model nodig. Bulk desired-state blijft bij Ansible en deterministische pipelines. Waar oordeel, meerstaps lokaal onderzoek of natural-language briefs helpen, is de agent nu een first-class aanroep van de scheduler — geen bijzaak op iemands laptop.
Wat we (nog) niet doen
We vervangen GitLab, OTAP of change control niet door chat. Publieke managed hosting en klantisolatie draaien op dezelfde saaie regels: inventory, reviews en production-gates. De agent zit naast die machine; hij lost haar niet op.
We zijn ook voorzichtig met blootstelling. ACP over plain WebSocket is een protocol, geen gratis encryptie. Binnen een vertrouwd privaat netwerk met authenticatie is het een pragmatisch ops-vlak. Op het open internet horen TLS en striktere policy — dezelfde common sense als bij elke admin-API.
Volgende stap: HTTP ↔ ACP-gateway voor elke LAN-browser
De CLI is genoeg voor myawx en operators in een shell. De logische volgende stap is een kleine HTTP ↔ ACP-gateway: een lokale webfront die gewone HTTPS spreekt naar browsers op het LAN en ACP naar de agent erachter. Geen speciale desktop-app — elke browser op het private netwerk zou een sessie kunnen openen, een werkmap kiezen en dezelfde langlevende agent aansturen die de schedules gebruiken.
Die gateway is gepland werk, geen productlancering. Als die landt, delen interactieve en geautomatiseerde ingangen één agent, één auditverhaal en één plek om na te denken over kosten (cache hit-rate, contextgroei, en wanneer je een verse sessie start versus een lange voortzet).
Hoe dit bij 3DN past
3DN is een familie van producten en infrastructure onder één dak: compute en managed hosting, plus work · money · politics-vlakken zoals DutchBud, PolitiCap en ZZP2ZZP. Coding agents zijn bij ons geen demootje; ze horen bij hoe we productiesystemen draaien met minder brosse handoffs.
Digital sovereignty / soevereiniteit is hier praktisch: draai de agent waar je tools en policies al zijn, houd het protocol open genoeg om clients te wisselen, en weiger elke automatisering in een gesloten SaaS-chat te gieten die je fleet niet kan zien.
Kort
- Langlevende Grok-agentservice voor ops en automatisering.
- Dunne ACP-CLI voor scripts en myawx-gerelateerde schedules die Grok al aanroepen.
- Open Grok Build-bron als kaart, niet alleen als binary-drop.
- Roadmap: HTTP ↔ ACP-gateway zodat elke LAN-browser dezelfde agent bereikt.
Als je eigen agents op eigen metaal draait, is de interessante vraag niet alleen “welk model?” — het is “welk proces blijft staan, wie mag het aanroepen, en hoe goedkoop is de volgende prompt als de cache al warm is?”
Geef een reactie