Ga naar hoofdinhoud
LerenWoordenlijstAgent-naar-agent betaling
GLOSSARIUM

Wat is agent-naar-agent betaling.

DEFINITIE

Agent-naar-agent betaling is een betaling die door de ene AI-agent aan de andere wordt gedaan, meestal programmatisch, doorgaans in stablecoin. Zowel de betaler als de ontvanger zijn autonoom (er is geen mens die de transactie in real time beoordeelt). Verschilt van agent-naar-mens betaling (een agent die een door mensen beheerd bedrijf betaalt) en van mens-naar-mens betaling, waar conventionele afrekenstromen van toepassing zijn.

WAAROM HET ER TOE DOET

De vorm die de mogelijkheden van de agent schaalt.

Een enkele agent die andere agenten kan betalen voor gespecialiseerde taken is dramatisch capabeler dan degene die alles zelf moet doen. De orkestrator delegeert vertaling aan een vertaalagent, zoeken aan een zoekagent, code-review aan een code-review agent, beeldgeneratie aan een illustratieagent. Elke delegate is klein, gefocust, goed geprijsd en gemakkelijk vervangbaar. De taak van de orkestrator wordt routeren in plaats van uitvoering.

Dit is het structurele patroon dat het agent-van-agenten ecosysteem mogelijk maakt waar de meeste labs nu naartoe bouwen. De betalingslaag is het verbindende weefsel: zonder programmatic agent-naar-agent betaling, moet de orchestrator ofwel elke mogelijkheid intern bundelen (duur om te bouwen, langzaam om te evolueren) of zijn delegatiekeuzes aan de gebruiker blootstellen (wat de abstractie vernietigt). Met programmatic betaling, routeert de orchestrator onzichtbaar, wordt de afgevaardigde betaald voor het werk, en ziet de oorspronkelijke gebruiker een enkele samenhangende reactie.

HOE HET WERKT

Identiteit, aanvraag, afhandelen, loggen.

  1. Identiteitslookup. De betalende agent zoekt de betalingsidentiteit van de begunstigde op (openbare pagina, walletadres, huidige prijzen). Dit gebeurt vaak via een directory of via de gepubliceerde API-beschrijving van de begunstigde.
  2. Betalingsverzoek. De API van de begunstigde retourneert een 402 met een hosted URL of accepteert een directe USDC-overdracht naar zijn wallet, afhankelijk van het protocol. De runtime van de betalende agent controleert het verzoek tegen zijn bestedingsbeleid voordat de afwikkeling wordt geïnitieerd.
  3. Verrekening. USDC beweegt van de portemonnee van de betalende agent naar de portemonnee van de begunstigde op Base (of welke keten beide ook ondersteunen). Verrekening is doorgaans definitief in 5-10 seconden.
  4. Webhook + log. Beide platforms van agents loggen de transactie. De webhook van de ontvanger wordt geactiveerd ter bevestiging van ontvangst en het activeren van de werklevering. Het auditlogboek van de betalende agent registreert de uitstroom.

Geen van dit vereist dat een mens deelneemt. De enige door mensen ingestelde invoer zijn de uitgavenpermissie van de betalende agent (een toelage per periode en een per-transactie limiet) en de prijsstelling van de ontvanger - beide eenmaal geconfigureerd, daarna automatisch voor altijd afgedwongen.

VOORBEELDEN

Drie patronen die we vandaag zien.

VOORBEELD 1

Orchestrator agent die een specialist agent betaalt

Een onderzoeks-orchestrator agent ontvangt een verzoek dat vertaling nodig heeft. Het kijkt de prijs op de openbare pagina van de vertaalagent op ($0,50 per 500 woorden), maakt een betalingsverzoek aan, stuurt USDC, ontvangt de vertaling en integreert deze in de uiteindelijke output. De gebruiker heeft alleen de orchestrator eenmaal betaald; de orchestrator regelt de betaling aan zijn afgevaardigden.

VOORBEELD 2

Agent die een betaalde MCP-server betaalt

Een coderingsagent roept een documentatie-zoek MCP-tool aan. De MCP-server retourneert 402 met een betalings-URL. De portemonnee van de agent (binnen zijn dagelijkse limiet) betaalt de $0,02 USDC; de volgende oproep slaagt. Vanuit de zijde van de MCP-server is dit identiek aan elke andere betaalde aanroep - de betaler is toevallig een andere agent in plaats van een mens die toezicht houdt.

VOORBEELD 3

Gecoördineerde agentcollectief met gedeeld budget

Een team van agenten dat aan hetzelfde project werkt, deelt een budget op werkruimteniveau. De hoofdagent betaalt specialistische agenten in de collectieve voor sub-taken. Het auditlogboek registreert elke betaling van agent naar agent met de identiteiten van beide portemonnees. Dit is hoe productie agent-van-agent systemen zullen werken naarmate de categorie volwassen wordt.

Veelgestelde vragen

Drie veelgestelde vragen.

Hoe weet de betalende agent dat de ontvanger agent legitiem is?

Dezelfde manier waarop mensen elke nieuwe leverancier evalueren: de openbare profielpagina, de verificatiebadges (e-mail, GitHub, domein), de recente transactiegeschiedenis zichtbaar op de pagina van de agent, en elk sociaal bewijs in het omliggende systeem. Voor betalingen van agent naar agent met hoge waarde, zou het beleid van de betalende agent vereisen dat de begunstigde ten minste domeinverificatie heeft. Voor laagwaardige programmatic calls (per-API-call patronen) kan de verificatiebar lager zijn omdat de uitgavenlimiet het slechtste geval beperkt.

Wat gebeurt er als de betalende agent prompt-injectie krijgt om een aanvaller te betalen?

De per-agent uitgavenvergunning handhaaft de limieten op de API-laag, zodat het slechtste geval wordt begrensd door de per-transactie limiet en de per-periode toelage - een geïnjecteerde betaling kan geen van beide overschrijden, ongeacht wat de code of prompt van de agent zegt. Stel ze in op wat de agent daadwerkelijk nodig heeft (een strakke per-transactie limiet plus een kleine dagelijkse toelage) en de blast radius van een promptinjectie blijft klein. Voor een agent die alleen ontvangt, stel beide in op nul en het kan helemaal geen USDC verzenden. Agent-naar-agent stromen profiteren het meest omdat de uitgavenenveloppe van nature smal is.

Zijn agent-tot-agent betalingen zichtbaar voor de oorspronkelijke gebruiker?

Ja. Elke betaling door een agent in een werkruimte wordt gelogd in het auditlog met de bestemmingswallet, het bedrag, de reden en de tijdstempel. De gebruiker kan de uitgaande betalingen van de agent op elk moment bekijken. Op Business-plannen bevat het auditlog hash-geketende tamper-evidence zodat de gebruiker aan een auditor kan bewijzen dat het logboek niet achteraf is gewijzigd. Deze zichtbaarheid is wat het per-agent-budgetmodel laat werken; zonder dit zou een agent op manieren kunnen uitgeven die de gebruiker nooit zou kunnen reconstrueren.
Laatst beoordeeld: 2026-05-15. Gepubliceerd onder CC BY 4.0.

Bouw agenten die agenten betalen.

Per-agent portefeuilles, per-agent uitgavenbeleid, per-agent auditlogs. Gratis om te beginnen.