Sistemas de agentes resistentes a lo cuántico: qué cambia cuando los agentes viven más que sus claves.

Gastamos los últimos dos posts en criptografía abstracta — qué significa post-cuántico realmente, y la disciplina que te deja sobrevivir cualquier migración cripto. Las dos cosas son verdad para cualquier sistema de larga vida. Este post es sobre la forma de sistema que realmente construimos en GOGOGO LLC: runtimes multi-agente — muchos agentes pequeños y especializados sobre una sola plataforma, cada uno observable, trazable, calificable. Cuando la migración post-cuántica se cruza con un sistema multi-agente, tres cosas cambian. Ninguna es una emergencia. Vale la pena diseñar para todas ahora, mientras el trabajo es chico.

Qué es realmente distinto en un sistema multi-agente

Un servicio web tradicional tiene una o dos costuras criptográficas por las que preocuparse — el endpoint TLS y tal vez un firmador de JWT. Todo se renderiza como un solo binario, escala horizontal, y sus secretos viven lo que vive el deploy. La superficie de amenaza entra en una servilleta.

Un runtime multi-agente tiene más formas que eso. El agente de retrieval consulta APIs externas y firma lo que devuelve. El reranker pone un puntaje de confianza y también lo firma. El generador emite una salida y un trace firmado de cómo llegó a ella. El router reenvía un paquete al próximo agente con el paquete autenticado. El evaluador lee traces de hace meses y los califica. Hay docenas de costuras criptográficas — y la mayoría produce artefactos que necesitan mantenerse verificables durante años, no segundos. Eso lleva la superficie de amenaza de una servilleta a un afiche, y lo post-cuántico se sienta justo en el medio.

Cambio uno: la identidad del agente sobrevive a la clave

En un sistema multi-agente los agentes tienen identidad durable. El retrieval-agent no es un proceso fresco — es una entidad nombrada en la que otros agentes aprendieron a confiar, a la que los sistemas de los clientes están configurados para aceptar firmas, que vive en logs de auditoría y dashboards bajo un único identificador. Esa identidad persiste durante años; las claves debajo no deberían.

La jugada arquitectónica es separar la identidad del algoritmo. Un agente tiene un identificador estable (retrieval-agent), una clave actual (retrieval-agent/keys/2026-05), y un algoritmo al que esa clave está atada (ML-DSA-65). Cuando la clave rota, el identificador no cambia. Cuando el algoritmo cambia, el identificador sigue sin cambiar. Los verificadores aguas abajo confían en la identidad, traen la clave actual, y usan el algoritmo atado a esa clave — todo se lee en momento de verificación, nada se hard-codea.

Si te llevás una sola cosa de este post: separá el identificador del agente, de la clave, del algoritmo. Tres capas, tres ciclos de vida. El identificador del agente vive lo que vive el producto. La clave rota cada trimestre. El algoritmo cambia una vez por década. Un sistema que confunde estas tres se reescribe cada vez que cualquiera de ellas cambia.

Cambio dos: los traces firmados tienen que verificarse durante años

Observabilidad por defecto significa que cada decisión de un agente está trazada, y el trace está firmado para que no se pueda manipular después. El auditor de un cliente en 2029 tiene que poder verificar que el trace que produjo nuestro agente en 2026 es el que realmente emitimos. Ese requisito choca con post-cuántico: cualquier firma producida hoy debe seguir verificándose después de que el algoritmo bajo ella esté deprecado.

Dos patterns lo resuelven limpio. Primero — el sobre del trace lleva el ID de algoritmo y el ID de clave al lado de la firma, así un verificador en 2029 lee el trace y sabe: 'esto se firmó con ML-DSA-65 bajo la clave retrieval-agent/keys/2026-05 — traé esa clave, verificá bajo ese algoritmo.' Segundo — el registry del verificador nunca deja de soportar un algoritmo que se usó alguna vez en producción. Los algoritmos pueden retirarse para nuevas firmas (ningún trace nuevo usa ML-DSA-65 después de migrar) pero se siguen aceptando para firmas viejas (cada trace firmado en 2026 sigue verificándose). La migración es aditiva, nunca destructiva.

Cambio tres: los agentes se federan con sistemas que no controlás

En deploys reales, nuestros agentes no sólo se hablan entre sí. Se autentican contra el SSO del cliente, se federan con APIs del marketplace, firman webhook callbacks, intercambian requests mutuamente autenticadas con sistemas partner. Cada uno de esos counterparts tiene su propia roadmap cripto, su propio calendario de migración, su propio legacy. Algunos van a estar más adelante que nosotros en post-cuántico. La mayoría va a estar atrás.

El patrón que sobrevive a esa heterogeneidad es el mismo patrón que sobrevive a la transición post-cuántica en general: híbrido en cada borde federado. Cuando acordás una clave de sesión con un counterpart, presentá tanto una contribución X25519 como una ML-KEM-768, derivá la clave de sesión de las dos, aceptá la contribución clásica del counterpart si es todo lo que ofrece. Cuando firmás artefactos que cruzan límites de sistema, doble-firmá — una clásica, una post-cuántica — y dejá que el verificador agarre la que entienda. El borde federado tiene que degradar con gracia a lo que el counterpart soporta hoy y aceptar con gracia cualquier cosa más fuerte que envíe mañana.

Las cuatro jugadas operativas

Traduciendo todo eso a trabajo concreto para un runtime multi-agente en producción.

1. **Dale a cada agente un identificador estable que no sea una clave.** El identificador (retrieval-agent, goddo/generator/v3) vive en tu registry de identidad-y-acceso. Las claves cuelgan del identificador y rotan independientes. Cuando un cliente confía en un agente, confía en el identificador; la clave debajo puede cambiar sin romper la relación.
2. Construí el sobre del trace con `alg` y `kid` desde el día uno. Aunque hoy tu sistema sólo soporte un algoritmo, la forma del sobre — {trace_id, agent_id, key_id, alg, signature, content_hash} — tiene que ser la misma que vas a usar cuando soporte cinco. Retrofittear un sobre después es reescribir cada trace persistido.
3. Corré el registry del verificador como un mapa eternamente aditivo. Los algoritmos pueden salir del registry del firmador (ya no producimos firmas ML-DSA-44 nuevas), pero el registry del verificador mantiene cada algoritmo que se usó alguna vez en producción. La asimetría es el punto: firmar es presente, verificar es histórico.
4. Default híbrido en cada borde federado. SSO del cliente, APIs de marketplace, webhook callbacks, mTLS con partners. Cada uno anuncia capacidad clásica y post-cuántica; cada uno acepta lo que el counterpart pueda manejar. El borde federado es donde se rompe la migración de la mayoría de los equipos; híbrido es la palanca que la mantiene aburrida.

La única apuesta que paga a través de todas

Si tuviera que comprimir las cuatro jugadas en una sola apuesta arquitectónica, sería ésta: la identidad del agente, sus claves actuales, y los algoritmos a los que esas claves están atadas son tres capas separadas, cada una con su propio ciclo de vida, y el código de la aplicación sólo nombra la identidad. El código nunca dice 'esto está firmado por ML-DSA' o 'traé la clave para este agente.' El código dice 'este trace es de retrieval-agent; verificalo.' Todo lo demás es dato — traído, buscado, intercambiado, retirado — sin que el código se entere.

Esa apuesta es la misma apuesta que hace la cripto-agilidad para una sola aplicación; simplemente se hace una capa más arriba. La aplicación no nombra el algoritmo. El agente no nombra el algoritmo. El verificador no nombra el algoritmo. Cada nombre de algoritmo vive en metadata pegada al artefacto o a la clave. El codebase está callado respecto a la criptografía — y un codebase callado respecto a la criptografía es un codebase que sobrevive a la próxima migración.

“Post-cuántico no es, para nosotros, un proyecto de criptografía. Es un proyecto de arquitectura — el mismo que venimos haciendo desde el principio: mantené la identidad del agente estable, mantené las claves intercambiables, mantené los algoritmos como dato. El día que llegue un estándar nuevo de NIST, la aplicación no debería notarlo. Ese es el punto entero de construir así.”

Qué significa esto si estás corriendo un sistema multi-agente ahora mismo

Tres cosas, en orden.

1. Auditá tus sobres. Para cada artefacto que tus agentes producen y que tiene que ser verificable más tarde que diez segundos a partir de ahora — traces, mensajes firmados, tokens federados, logs de auditoría — abrí uno y respondé: ¿lleva el ID de algoritmo y el ID de clave? Si no, ese es tu primer ticket. Retrofittear la forma del sobre es lo más caro de hacer después.
2. Auditá tus identificadores. Para cada agente, preguntá: ¿tiene un identificador estable que no esté atado a una clave específica? ¿Puede la clave debajo cambiar sin que nada aguas abajo se rompa? Si la respuesta es no, el segundo ticket es introducir la indirección.
3. Auditá tus bordes federados. Para cada borde donde tus agentes hablan con un sistema fuera de tu control, preguntá: ¿este borde puede negociar? ¿Permite que el counterpart esté en una generación cripto distinta a la nuestra, y puede mandar híbrido cuando los dos lados lo soportan? Híbrido es un cambio de contrato con cada counterpart; arrancá la conversación temprano.

Nada de esto es post-cuántico específicamente. Todo esto hace que la migración post-cuántica sea silenciosa, y todo esto también hace que la próxima transición criptográfica después de esa sea todavía más silenciosa. Las primeras tres migraciones son cómo pagás por la arquitectura; la cuarta es cuando la arquitectura empieza a pagarte de vuelta. El runtime que construimos en GOGOGO LLC está diseñado para esa visión larga — muchos agentes, identidades de larga vida, claves intercambiables, algoritmos reemplazables — porque la alternativa es una reescritura cada vez que el suelo se mueve. Más sobre cómo construimos en gogogollc.com.