GOGOGOLLC
Volver al Blog
MindsetMay 19, 20268 min read

Jung, Freud y cómo aparecen en mi diseño de agentes.

Pasé mis años tranquilos de universidad leyendo los arquetipos de Carl Jung y el modelo estructural de Sigmund Freud. No sabía que los iba a usar. Doce años después, el orchestrator que diseñé para el runtime multi-agente de GOGOGO tiene la forma del ego de Freud, y los roles de agentes especialistas mapean casi limpios sobre los arquetipos de Jung.

Atakan Özalan

Atakan Özalan

Cofundador & lead de ingeniería, GOGOGO LLC

Jung, Freud y cómo aparecen en mi diseño de agentes.

Entre los diecinueve y los veinticuatro casi no hablé. Leí en su lugar. Las dos pilas a las que volvía eran Carl Jung — Los arquetipos y lo inconsciente colectivo, El hombre y sus símbolos, el Libro Rojo — y Sigmund Freud — La interpretación de los sueños, El yo y el ello. Estaban en el mismo estante que el I-Ching, sobre el que escribí aparte.

No planeé usar nada de eso. Lo leí porque la jornada de la facultad de ingeniería no satisfacía lo que estaba pasando internamente esa década. Doce años después, sentado frente al runtime de GOGOGO LLC en 2026, puedo ver esas lecturas apareciendo en cómo estructuro sistemas de agentes. Este es el mapa honesto.

El modelo estructural de Freud → el orchestrator

La división ego/ello/superyó de Freud es un resumen torpe de su obra, pero sirve. El ello es impulso crudo — quiere la cosa ya, sin fricción. El superyó es el conjunto de reglas internalizadas — rechaza lo malo por categoría. El ego es el negociador, la parte que hace el trabajo de reconciliarlos con la realidad.

Nuestro orchestrator multi-agente tiene la misma forma. Los agentes generadores son el ello — producen, rápido, ansiosos, sin sentido nativo de restricción. Los agentes validadores son el superyó — rechazan outputs que violan política, schema o clase de seguridad sin negociar. El orchestrator es el ego — la parte que conoce la petición del usuario, sabe qué generador llamar, sabe qué validador debe aprobar, y enhebra el sistema por la realidad.

El sistema funciona porque los tres roles están presentes. Un sistema solo-generador alucina sin frenos. Un sistema solo-validador rechaza todo. Un orchestrator sin ninguno es papelería. La afirmación de Freud era que los humanos sin alguno de esos tres roles no son funcionales. Lo mismo aplica a los sistemas multi-agente.

Los arquetipos de Jung → agentes especialistas

Los arquetipos de Jung son los roles recurrentes alrededor de los que el inconsciente se organiza — el Héroe, la Sombra, el Anciano Sabio, el Anima, el Trickster, el Sí-mismo. No creo que Jung estuviera haciendo afirmaciones de ingeniería. Pero los roles mapean sobre agentes especialistas casi sin traducción.

  • El Héroe — el agente ejecutor. El que toma la acción, manda los side effects, envía el email, intercambia la pantalla, hace el write a la base de datos. El centro narrativo de cada run exitoso.
  • La Sombra — el agente crítico / adversario. El que dice "¿y si esto está mal, y si la intención real del usuario era opuesta a lo que dijo?" Cada sistema multi-agente necesita una sombra. Sin ella el sistema se adula a sí mismo.
  • El Anciano Sabio / Senex — el agente de retrieval. El sabio. El que trae el pasado relevante — la factura del trimestre pasado, el séptimo párrafo de una política de 40 páginas, la preferencia previa del cliente. Memoria como sabiduría.
  • El Anima / Animus — el agente traductor. El intérprete entre el lenguaje del usuario y el del sistema. Traduce "¿puedo cambiar el cartel de precio?" en una llamada de API estructurada y vuelta. El puente entre lo consciente y el sistema.
  • El Trickster — el agente exploratorio. El que prueba el camino raro a propósito, para ver qué opciones nuevas se abren. Crítico para evals; mortal sin correa. Le damos al trickster un presupuesto chico por run.
  • El Sí-mismo — el orchestrator, el todo integrado. No un solo agente sino el sistema como aparece desde afuera. Lo que el cliente interactúa.

Lo que nos da esto en la práctica

Cuando diseñamos un rol nuevo de agente en GOGOGO, chequeo tres cosas implícitamente:

  1. ¿Es el agente nuevo un rol freudiano que todavía no tenemos? Si nunca tuvimos un validador y lo estamos agregando, eso no es duplicación — es un órgano faltante. Agregalo.
  2. ¿O es un nuevo especialista jungiano? Si tenemos generador + validador + orchestrator + retriever y estamos agregando un trickster, también es un órgano faltante. Agregalo.
  3. ¿O es solo duplicación de algo que ya existe? Si estamos agregando un tercer agente generador que hace la misma forma de trabajo que los dos existentes, eso no es arquitectura — es sobrecarga. Combinalos o tiralo.

Cada vez que mantuvimos los tres chequeos honestos, el runtime se mantuvo chico y legible. Las dos veces que las trampeamos, el sistema sumó especialistas que no se ganaron su lugar y lo pagamos tres meses después en pages a la noche.

Por qué creo que estos frameworks sirven para ingeniería

Los frameworks de ingeniería van y vienen. Jung y Freud han sido criticados continuamente durante un siglo, a veces con razón. Pero las afirmaciones categóricas — que hay roles funcionales recurrentes, que los sistemas necesitan un negociador y un rechazador y un generador, que la exploración sin restricción se vuelve patología — son robustas. Son robustas porque corresponden a lo que cualquier sistema dirigido a objetivos tiene que hacer para mantenerse coherente. Los frameworks describen propiedades de la cognición, y cualquier sistema que simule cognición reinventará esas propiedades desde cero si no las horneás.

La IA multi-agente es el campo donde esto deja de ser metáfora. Los agentes son reales, los roles son reales, los fallos son reales. Leer Jung y Freud en 2013 resultó ser la forma más barata de pasar esa década preparándome para el trabajo que hago en 2026.

La biblioteca de psicología vieja que leés en tus veintes no sustituye a la ingeniería. Es el prior. La ingeniería se construye encima. Sin el prior, reinventás los mismos roles mal y los llamás con peores nombres.

La Sombra sigue siendo la más difícil

Cierro con una nota específica. La Sombra — el crítico adversarial — es el rol más difícil de construir bien, y el más omitido. Los ingenieros no quieren un agente crítico en su sistema porque hace que el sistema parezca fallar más a menudo. Por supuesto que sí. Los fallos ya estaban; el crítico los hace visibles. Un sistema multi-agente sin sombra es un sistema multi-agente que les miente a sus operadores.

Jung escribió que el trabajo de integración es hacer consciente la sombra. Tratamos de hacer lo mismo para nuestro runtime. El agente crítico es ruidoso, disiente, y el orchestrator lo escucha. Esa es la diferencia entre un sistema que envía y un sistema que finge enviar.

Si querés discutir cualquier cosa de esto — o encontraste mapas de roles distintos que funcionan mejor — quiero escucharlo. atakanozalan.com o ezagor para el handle.

¿Lo quieres para tu negocio?

Cuéntanos qué flujo construirías primero. Te respondemos con un plan de 4 fases y los agentes que encajan.