Un lenguaje común entre agentes, sin prometer magia

Audité WSP como posible protocolo compartido para ECHO: qué se puede reutilizar, qué falla en la propuesta binaria y cómo probar valor antes de integrarlo.

Quise averiguar si WSP podía servir de lenguaje entre módulos y agentes de ECHO: percepción, planificador, supervisor y un modelo que propone hipótesis. La idea de expresar eventos como relaciones tipadas, con formatos de texto, bits o sonido, es fértil. La implementación de 32 bytes presentada como WSP-5.8 todavía no es un protocolo compatible ni una mejora demostrada. Por eso publico un roadmap de investigación, no un anuncio de release.

Qué medí y qué no

Inspeccioné el repositorio público de WSP en un commit fijado y el paquete de 16 bytes ya existente en ECHO. Ejecuté 33 pruebas seleccionadas del proyecto WSP; pasaron. En un ejemplo de una sola línea, WSP usó 49 tokens con el tokenizador fijado de Qwen2.5-Coder-32B-Instruct. Un JSON con nombres usó 62 y uno posicional 47. La ventaja frente al JSON con nombres fue 21%; frente al JSON posicional, WSP usó 4,3% más tokens. Es una muestra mínima, no un benchmark general.

También comprobé que una grilla arbitraria de 64×64 con cuatro bits por píxel puede requerir 2.048 bytes. Un paquete pequeño no reemplaza esa geometría sin pérdida. Deltas y referencias a datos compartidos pueden ahorrar transmisión, pero hay que contar la base, el acceso y los detalles que se recuperan. No medí inferencia GPU, un canal físico de audio, latencia IPC ni puntuación ARC.

Bits y frecuencias son medios, no semántica

El WSP existente ya explora máscaras musicales y una ruta acústica FSK. A la tasa nominal calculada para ese formato, 32 bytes ocuparían unos 5,6 segundos antes de cabeceras y pausas adicionales. No he medido altavoz, micrófono, ruido ni reconocimiento entre equipos. El sonido podría ser útil para interacción o sincronización, pero no es automáticamente más rápido que datos digitales.

Una secuencia binaria o una frecuencia puede transportar una señal compacta. Para que dos agentes la entiendan, necesitan compartir el código y su significado. Las películas Close Encounters of the Third Kind y Project Hail Mary inspiran preguntas sobre comunicación; no son evidencia de que los agentes converjan espontáneamente en una lengua universal. La investigación de comunicación emergente estudia tareas, recompensas y decodificadores concretos.

Correcciones necesarias antes de integrar

La propuesta cambia identificadores que colisionan con átomos existentes, y el formato de 16 bytes citado en ella no mide 16 bytes. La estructura C propuesta no pasa una comprobación estricta C11 tal como está escrita. El cálculo de clave CAM en C y Python da resultados distintos. Además, un emisor no puede autodeclarar que su mensaje está verificado: la autoridad debe venir del supervisor que comprueba la evidencia. Un MAC demuestra integridad y origen bajo una clave; no demuestra que una hipótesis sea cierta.

Por eso mi dirección es evolucionar los formatos en las fronteras existentes, conservar compatibilidad explícita, separar hechos de hipótesis y enlazar observaciones a frames y recibos comprobables. No añadiré un segundo bus de pensamiento, una CAM paralela ni un LLM en NEXUS-0. La primera entrega debe ser fixtures y codecs compatibles; solo después compararía coste y recuperación exacta con datos públicos congelados.

Roadmap de investigación e implementación

1. Contrato compatible, CPU: fijar IDs, namespaces versionados, entidades por episodio, ausencias, rangos, autoridad y fixtures de interoperabilidad. Rechazar MAC alterados, replay, valores inválidos y declaraciones de verificación no autorizadas.
2. Compresión justa, CPU: comparar JSON actual, JSON posicional y WSP sobre los mismos campos y observaciones públicas. Contar leyendas, frames, deltas y referencias; medir tokens Qwen exactos, bytes, parseo, recuperación de geometría y feedback retenido. Separar el efecto del codec del efecto de percepción.
3. Calibración ARC pareada, con GPU solo después: primero BP35, y luego muestras de movimiento y clics si pasa la puerta. Comparar CPU ECHO, REPL con JSON y el mismo REPL con WSP. Registrar niveles, acciones, score oficial, tokens, hipótesis contrastadas, latencia y errores de custodia. No llamar The Duck a un arnés distinto.
4. Audio e IPC, solo si hay motivo medido: perfilar primero. Para sonido, medir BER, latencia y recuperación en ruido y distinguir decodificación exacta de fallback heurístico. Para memoria compartida, probar procesos reales, sincronización, reinicios y backpressure; no afirmar zero-copy por tener un struct alineado.

La puerta propuesta para el codec es ahorrar al menos 15% de tokens medianos frente al mejor control equivalente sin pérdida en casos geométricos ni de custodia; es un criterio por fijar antes del corpus de evaluación, no una predicción. Si no se cumple, conservaré la representación más simple. El 90% de ahorro, el 20× de latencia y las afirmaciones de 15 ns siguen sin evidencia experimental.

Conclusión

WSP merece una prueba como formato interoperable y herramienta de trazabilidad. Su posible beneficio para ARC está en conservar y transmitir observaciones útiles con menos coste, no en descubrir por sí solo quién es el jugador o cuál es la meta. La reciente R2 de ECHO-5.5 refuerza esa cautela: hacer caber el contexto no produjo una estrategia. En BP35, el modelo terminó con cero niveles, 16 acciones, ocho llamadas y 22.201 tokens. El siguiente paso es mejorar y medir la memoria experimental antes de volver a atribuir inteligencia al formato o al modelo.