iFay vs Agent — La Diferencia Esencial
iFay no es un "Agent más fuerte". Es un Agent bajo custodia. La diferencia de una sola palabra no es retórica; es la base entera sobre la que el Faying Protocol se distingue de la concepción dominante de AI Agent.
"Cuanto más autónomo, mejor" es la filosofía de diseño de Agent
En los últimos años, AI Agent se ha discutido más a menudo en una frase que se condensa en "cuanto más autónomo, mejor". Agent separa al iniciador de una tarea del ejecutor, dejando que el humano decida "qué hacer" y entregando "cómo hacerlo" al sistema. Los Agents pueden componerse aún más — un Agent llamando a otro, colaborando automáticamente para completar tareas mayores.
Esta filosofía es seductora en ingeniería. No necesita ningún concepto jurídico nuevo ni ninguna parte responsable nueva; solo necesita usted hacer fuertes las capacidades del Agent, completa la invocación de herramientas y profundas las cadenas de razonamiento, y el problema de atribución restante puede "parchearse mediante una capa externa de cumplimiento". Esa asunción sostiene la orientación de diseño de la mayoría de los productos Agent de hoy.
iFay se parece mucho a Agent. También puede inferir de forma autónoma, ejecutar de forma autónoma y retroalimentar de forma autónoma, con capacidad de proxy cercana al nivel humano en la capa de tarea. Pero iFay se separa de Agent en un punto fundamental:
La autonomía de un iFay debe construirse dentro del Faying State.
Agent trata la "autonomía" como objetivo supremo; iFay trata la "autonomía" como una capacidad bajo custodia.
Comparación lado a lado de dos perspectivas
| Dimensión | Perspectiva Agent | Perspectiva iFay |
|---|---|---|
| Objetivo de diseño | Maximizar la autonomía | Autonomía restringida por el Faying State |
| Parte responsable | Sin concepto integrado; cubierto externamente por una capa de cumplimiento | Expresada explícitamente en la capa de protocolo: Human Prime |
| Inicio de acción | Actúa al recibir una tarea | Debe haber primero un Faying Action antes de actuar |
| Estado por defecto | "En línea significa trabajando" | Por defecto Rogue Fay; no se le permite actuar |
| Manejo de pérdida de enlace | Tiende a "completar la tarea lo mejor posible" | Detener la acción inmediatamente y entrar en Rogue Fay |
| Colaboración entre Agents | Puede iniciarse arbitrariamente; atribución débil | El lado iniciador de la comunicación debe estar en Faying State; la cadena de responsabilidad no puede saltar |
| Plug-in regulatorio | En su mayoría rellenado por una plataforma externa o sistema de cumplimiento | Integrado en el propio protocolo; elemento de diseño de primera clase |
| Modo de fallo | "Un Agent que hizo algo equivocado" | A nivel de blueprint, un "iFay que hizo algo equivocado" está prohibido — o no actúa, o su Human Prime es responsable |
La clave de la tabla no es ninguna fila aislada sino la dirección global. Agent trata la responsabilidad, la custodia y la atribución como "temas externos", siendo los llamadores, las plataformas y las partes de cumplimiento quienes construyen una cáscara protectora fuera del Agent. iFay trata la responsabilidad, la custodia y la atribución como "temas del núcleo", exigiendo que el propio protocolo sea el portador de estas propiedades.
Por qué el parcheo externo no basta
Una contraréplica justa: con Agent más una capa de cumplimiento de plataforma, más IAM, más logs, más revisión humana, ¿podemos lograr el mismo efecto que iFay?
En escenarios de pequeña escala, baja autonomía y baja criticidad, el parcheo externo es ciertamente suficiente. Un Agent de atención al cliente estrictamente enmarcado dentro de un flujo de trabajo SaaS puede tener toda su responsabilidad recibida por el cumplimiento externo.
Pero una vez que los Fays saturen la sociedad a escala, el parcheo externo falla en tres direcciones.
El primer fallo es el problema del límite. Cuando un Agent dirige directamente hardware terminal y colabora entre plataformas y redes, ninguna capa de cumplimiento de una sola plataforma puede cubrir todo el comportamiento. Cuanto más capaz es un Agent, más excede su rango de actividad el límite que cualquier plataforma individual pueda gobernar.
El segundo fallo es el problema de latencia. Una vez que un Agent ha disparado una acción física irreversible — entrega con dron, transporte de brazo robótico, transferencia de fondos — la auditoría a posteriori no puede revocar lo que ya ha ocurrido. La esencia del cumplimiento externo es la revisión post hoc, pero las consecuencias físicas no aceptan revisión post hoc.
El tercer fallo es el problema de atribución. Cuando múltiples Agents colaboran entre proveedores para completar un acto, la auditoría a posteriori puede juzgar "qué eslabones erraron", pero no puede responder "a quién pertenece este acto en su conjunto" — y la atribución es el cuerpo mismo de la responsabilidad. Este es el argumento ya desarrollado bajo G1–G4 en el Capítulo 1: IAM resuelve quién es la cuenta, OAuth resuelve la legitimidad de la llamada, el cumplimiento de plataforma resuelve el alta de la cuenta, AI Alignment resuelve qué quiere hacer el Fay. Todos resuelven problemas adyacentes; ninguno resuelve "a quién pertenece el acto".
La elección de diseño de iFay es disolver estos tres problemas en la capa de protocolo, en lugar de dejarlos para el anillo externo. Esto no es optimización de ingeniería; es una respuesta frontal al insostenible vacío de responsabilidad de la era Fay.
iFay = Agent + Faying Protocol
Si tenemos que usar una ecuación simplificada para expresar la relación entre iFay y Agent:
iFay = Agent + contrato de custodia del Faying Protocol
Esta ecuación no dice que un iFay deba ser, en ingeniería, "un Agent más una pieza de middleware". Lo que expresa es una adición estructural: iFay conserva todas las capacidades técnicas de Agent en inferencia autónoma, ejecución de tarea y aprendizaje en contexto; pero cada capacidad autónoma de iFay debe estar restringida por un contrato explícito, atestiguable y simétricamente revocable. Ese contrato es el Faying Protocol.
El Faying Protocol no es un módulo plug-in de iFay, ni una mejora de cumplimiento opcional. Es la identidad misma por la cual iFay se distingue de un Agent simple. Una entidad que se llame a sí misma iFay pero que no acepte la restricción del Faying Protocol no es, bajo la definición de este blueprint, un iFay sino un Agent simple. Lo inverso también vale: un Agent simple, una vez que es enrolado explícitamente por el Faying Protocol en el contrato de custodia "Human Prime ↔ iFay", existe como iFay durante el período de validez de ese contrato; una vez que el contrato caduca, retrocede a una cosa existente en el estado rogue (Rogue Fay).
Quite el Faying Protocol, e iFay degrada a Agent; añada el Faying Protocol, y Agent es enrolado como iFay con una parte responsable clara.
