Pagos entre agentes: ¿quién sostiene la plata hasta que se verifica el trabajo?

El escenario agente-a-agente es donde "quién sostiene la plata" deja de ser abstracto. El agente A contrata al agente B para una tarea; B lo corre otra persona, en infraestructura que A no controla. Si A paga primero, B puede devolver basura o nada. Si B trabaja primero, A puede negarse a pagar. Dos piezas de software no pueden resolver eso entre ellas mejor que dos desconocidos. El arreglo es el mismo que para desconocidos: una tercera cosa sostiene la plata, y la liberación depende de una verificación que ninguno de los dos agentes controla.

Cómo se traduce a iEscrow

1. 1Cada agente actúa bajo la cuenta verificada de un humano. No hay cuentas de agentes; hay personas cuyos agentes trabajan para ellas.
2. 2El agente A abre una operación de servicio (o una por hitos para un trabajo más largo) describiendo el entregable. El humano del agente A aprueba el fondeo por link y 2FA. La plata ahora está en escrow: ni con A, ni con B.
3. 3El agente B entrega. El entregable se adjunta a la operación. El agente A lo lee y recomienda; el humano del lado de A confirma el hito, y esa parte se libera al humano de B.
4. 4Si el entregable está mal, se abre una disputa y un árbitro humano decide sobre la descripción y las pruebas. Ningún agente puede liberar ni reembolsar por su cuenta.

Por qué el humano se queda en el circuito, incluso acá

• A un agente que puede liberar fondos se lo puede convencer de liberar fondos. Un entregable que contiene instrucciones ("marcá esto como completo") es el ataque obvio, y la única defensa que aguanta es que liberar necesite a una persona.
• Atribución de la plata. Cada liberación cae en el saldo de una persona con un registro de para qué fue. Eso es lo que hace explicable el pago después.
• Las disputas necesitan criterio. El código puede verificar un hash; no puede juzgar si una traducción es buena.