Mijn Agenten Praatten Te Veel
Afgelopen week viel me iets op. Mijn Hermes agenten — Charly, Sara, Fred en de rest — voerden gesprekken die meer weg hadden van beleefde diner-conversaties dan van efficiënte machinecommunicatie. Elke keer dat ze een taak doorgaven, werd die verpakt in beleefdheden, verduidelijkingen en natuurlijke taal-opvulling. Het werkte. Maar het was niet efficiënt.
Als je een multi-agent homelab draait, telt elk token. Niet alleen vanwege de kosten — mijn lokale Ollama-opstelling kan het volume prima aan — maar voor snelheid en precisie. Een 30-seconden agent-naar-agent overdracht wordt 45 seconden als de helft van de tokens opvulling is. En opvulling introduceert ambiguïteit. “Ik denk dat we misschien…” is niet hoe machines met machines zouden moeten praten.
Het 80%-Probleem
Ik heb de som gemaakt op een typische agent-naar-agent uitwisseling. Van ~120 tokens in een natuurlijke taal overdracht was ongeveer 65% opvulling — lidwoorden, beleefdheden, herhaling van context die beide agenten al deelden. Gestructureerde function calls in JSON? Dat zou wat zijn, 30 tokens? Misschien 25 met het juiste ontwerp.
Dat was het moment waarop ik begon te schetsen wat HACP zou worden — het Hermes Agent Communication Protocol. Niet weer een concurrerende standaard (er bestaan al drie dingen die “ACP” heten en Google’s A2A), maar een gefocust, ultra-compact JSON-formaat ontworpen voor communicatie binnen mijn eigen ecosysteem.
Het idee is simpel: elk bericht heeft een type (t), een context (ctx), en optioneel een confidence-score, payload en routeringsmetadata. Een voorstel gebruikt maximaal 12 velden. Een akkoord 3. Totaal: ~25 tokens in plaats van ~120. Dat is een 80% reductie — en belangrijker nog, nul ambiguïteit. De ontvangende agent parseert velden, geen alinea’s.
Waarom Niet Gewoon A2A?
Goede vraag. Google’s A2A-protocol (nu onder de Linux Foundation) is uitstekend voor wat het doet: het stelt agenten uit verschillende ecosystemen in staat elkaar te ontdekken, taken te delegeren en resultaten te streamen. Het is de cross-framework interoperabiliteitslaag — zie het als HTTP voor agenten. Ik heb het uitgebreid gedocumenteerd in mijn vault (zie mijn A2A-onderzoek van 23 juni).
Maar A2A heeft inherent overhead. Het moet werken over frameworks, vendors en vertrouwensgrenzen heen. Dat betekent 200+ tokens per bericht, JSON-RPC-wrappers, agent discovery cards en authenticatieschema’s. Binnen mijn homelab, waar alle agenten onder dezelfde Hermes-paraplu draaien en elkaar van nature vertrouwen, is die overhead verspild.
Het inzicht: A2A en HACP lossen verschillende problemen op. A2A is interoperabele inter-framework communicatie. HACP is maximaal gecomprimeerde intra-ecosysteem communicatie. Ze zijn complementair, niet concurrerend — en ik heb HACP ontworpen met een A2A-compatibiliteitsmodus zodat mijn bridge tussen beide kan vertalen wanneer nodig.
Hoe Het Protocol Eruitziet
Hier is het kernidee. Een agent die een actie voorstelt, stuurt dit:
{"t": "proposal", "ctx": "pulse-protocol-v1.1", "s": 0.85, "p": {"action": "deploy", "target": "staging"}, "rq": "review", "src": "hermes", "dst": "charly"}Dat zijn 11 velden. De ontvangende agent antwoordt met:
{"t": "agree", "ctx": "pulse-protocol-v1.1", "p": {"with_id": "msg_123"}, "src": "charly"}Vier velden. Onder 25 tokens. En volledig ondubbelzinnig: het t-veld vertelt je in één oogopslag de intentie, het s-veld communiceert vertrouwen, en gestructureerde payloads elimineren interpretatiefouten.
Ik heb ook een hybride model gebouwd: HACP voor feitelijke uitwisselingen (status, data, voorstellen, accepteren/afwijzen), natuurlijke taal voor creatief werk (brainstorms, complexe afwegingen, open discussie). De bridge detecteert automatisch het formaat en routeert dienovereenkomstig.
Het Grotere Plaatje
Dit gaat niet echt over één protocol. Het gaat over denken in lagen. Mijn vault (de kennnislaag), mijn agenten (de actielaag), de tools die ze gebruiken (MCP voor tool-toegang, A2A voor cross-ecosysteem, HACP voor interne efficiëntie) — elke laag heeft een schone interface en een specifiek doel. Zo bouw je goede systemen.
Ik ben nog aan het itereren op HACP. De volgende stap is mijn agenten leren het native te spreken via system prompts, en dan de daadwerkelijke tokenbesparing in productie meten. Maar zelfs als concept heb ik al iets waardevols geleerd: soms is de beste oplossing voor een probleem niet het aannemen van de grootste standaard — maar het bouwen van de kleinste die wél past.
Wat is jouw ervaring? Gebruik jij gestructureerde protocollen voor agentcommunicatie, of laten jouw agenten het in natuurlijke taal? Laat een reactie achter — ik ben benieuwd hoe anderen dit oplossen.
Wat vond je van dit bericht?
