Capítulo 6: Principios de diseño

El diseño de TP gira en torno a cinco principios fundamentales. Estos principios no solo guían el diseño técnico del protocolo en sí, sino que también definen los estándares de comportamiento que todos los participantes en el ecosistema TP deben seguir.

6.1 Cognición compartida sobre paso de mensajes

El principio de diseño primario de TP es: siempre que sea posible, priorizar el establecimiento de un espacio cognitivo compartido sobre depender de la transmisión serializada de mensajes. El modelo de paso de mensajes introduce pérdida de codificación, latencia de transmisión y ambigüedad semántica en cada ronda de interacción; el modelo de cognición compartida permite a las partes colaborantes acceder directamente a los mismos recursos cognitivos, eliminando fundamentalmente la fricción de la transferencia de información. Este principio no niega el valor del paso de mensajes — establecer el espacio compartido en sí requiere negociación por mensajes — pero define claramente la dirección de diseño de TP: minimizar la serialización y deserialización innecesarias.

Ejemplo práctico: Dos Fays colaboran en el procesamiento de un siniestro de seguro de accidente de tráfico. Bajo el modelo de paso de mensajes, el Fay de seguros necesita enviar el informe completo del accidente, fotos, información del vehículo y detalles de la póliza al Fay de evaluación... cada ronda de comunicación implica empaquetar y transmitir grandes volúmenes de datos. Bajo el modelo de cognición compartida, ambas partes establecen un contexto compartido donde el informe del accidente, fotos e información de la póliza están montados en el espacio compartido. El Fay de evaluación visualiza y anota directamente en el espacio compartido, y el Fay de seguros ve los resultados de anotación en tiempo real — todo el proceso es como dos ajustadores de siniestros sentados en el mismo escritorio revisando el mismo expediente.

6.2 Agnosticismo de transporte

TP se enfoca en la capa semántica, no en la capa de transporte. Los mensajes TP pueden entregarse a través del JSON-RPC de A2A, el tool call de MCP, APIs REST tradicionales, o incluso Prompts en lenguaje natural. Este principio asegura que TP no está vinculado a ningún protocolo subyacente único; cuando surgen nuevos métodos de transporte, TP solo necesita agregar un adaptador de transporte sin modificar las definiciones semánticas propias del protocolo. El agnosticismo de transporte también significa que TP posee inherentemente compatibilidad hacia adelante — puede adaptarse a protocolos de transporte que aún no han sido inventados.

Ejemplo práctico: Un Fay empresarial ejecutándose en la nube necesita comunicarse con un Fay ejecutándose en un dispositivo de borde (como una pasarela de sensores de fábrica). El Fay en la nube soporta nativamente A2A, pero el dispositivo de borde solo tiene una API REST simple. El agnosticismo de transporte de TP permite a ambas partes comunicarse sin preocuparse por las capacidades de transporte del otro — TP se adapta automáticamente, y el intent enviado por el Fay en la nube vía A2A se traduce transparentemente en una llamada API REST entregada al dispositivo de borde.

6.3 Negociación adaptativa de protocolo

En un ecosistema AI heterogéneo, diferentes Fays pueden "hablar" diferentes lenguajes de protocolo. TP no requiere que todos los participantes usen un protocolo de transporte unificado; en cambio, a través de un mecanismo adaptativo de negociación y traducción, permite a Fays con diferentes "lenguas nativas" comunicarse sin problemas. El proceso de negociación incluye tres pasos — sondeo de capacidades, negociación de contrato y mapeo semántico — asegurando que la intención no se pierda durante la traducción entre protocolos. Este principio reduce la barrera de entrada al ecosistema TP — cualquier Fay que soporte al menos un método de transporte puede participar en la comunicación TP.

Ejemplo práctico: El Fay de RRHH de una empresa multinacional necesita interfaz con coFays de seguridad social en diferentes países. El coFay de seguridad social de EE.UU. usa A2A, el de Japón usa MCP tool call, y el de la UE usa API REST. El Fay de RRHH no necesita escribir código de integración diferente para cada país — TP sondea automáticamente las capacidades de protocolo de la contraparte durante el establecimiento de sesión, negocia un método de transporte que ambos lados soporten, y toda la comunicación subsiguiente es completamente transparente.

6.4 Privacidad soberana del Host

En la visión del mundo iFay, cada Fay actúa en nombre de un Host. Por lo tanto, el Host tiene soberanía absoluta sobre sus datos. Un Fay no puede decidir unilateralmente qué recursos cognitivos compartir — cada divulgación de datos debe ocurrir dentro de los límites preautorizados por el Host. TP asegura que los datos de privacidad del Host estén siempre protegidos durante la transmisión y el acceso a través de un triple mecanismo de cifrado de extremo a extremo, divulgación selectiva (SelectiveDisclosure) y credentials de callback de tiempo limitado (CallbackCredential). El Host puede revocar la autorización en cualquier momento, terminando la compartición de datos.

Ejemplo práctico: El iFay de un usuario solicita un préstamo a un coFay bancario en su nombre. El banco necesita revisar la prueba de ingresos y el historial crediticio del usuario, pero el usuario no quiere que el banco vea sus detalles de gastos y su portafolio de inversiones. El usuario especifica explícitamente durante la autorización que "solo los estados de cuenta salariales de los últimos 12 meses y el puntaje crediticio pueden ser divulgados", y el iFay expone solo estos dos elementos a través del mecanismo de divulgación selectiva. Después de completar la aprobación del préstamo, el callback credential expira automáticamente, y el coFay bancario ya no puede acceder a ningún dato del usuario. Si el usuario cambia de opinión a mitad de camino, puede revocar la autorización en cualquier momento, terminando inmediatamente la compartición de datos.

6.5 Fronteras de confianza auditables

La confianza no es ciega — debe construirse sobre una base verificable. TP requiere que todas las operaciones que involucren acceso a datos de privacidad, uso de credentials y comunicación inter-Fay sean auditables. Los registros de auditoría contienen el tipo de operación, las identidades de los participantes, marcas de tiempo y el alcance de acceso, pero no incluyen el contenido real de los datos ni el texto plano de los tokens de credentials. El Host puede revisar el log de auditoría en cualquier momento para entender quién accedió a sus datos, en qué momento y con qué propósito. Este principio asegura que la confianza dentro del ecosistema TP sea transparente y rastreable.

Ejemplo práctico: El iFay de un paciente ha interactuado con un coFay médico, un coFay de seguros y un coFay de farmacia múltiples veces durante el último mes. El paciente puede abrir el log de auditoría y ver registros como: "3 de abril, 14:23 — El coFay médico accedió a su historial de alergias (alcance autorizado: datos relacionados con diagnóstico)", "5 de abril, 09:15 — El coFay de seguros accedió a códigos de diagnóstico y desglose de costos vía callback credential (credential expiró el 5 de abril, 17:00)." Esto es como revisar el historial de transacciones de una cuenta bancaria — cada "transacción de datos" está documentada.