Un agente de IA en 100 líneas de Lisp

Un agente de IA en 100 líneas de Lisp no es solo una pieza curiosa para compartir en X o en Slack. También es una forma muy concreta de ver qué hay debajo de la palabra “agente”: entrada, estado, decisión, acción y memoria. Cuando reduces todo eso a pocas líneas, deja de parecer magia y empieza a verse como lo que es: un programa con reglas, límites y puntos de falla.

Ese es el valor real de este enfoque. No te enseña a construir un producto listo para producción, pero sí te ayuda a entender arquitectura, control de flujo y automatización con IA sin capas de abstracción innecesarias. Si trabajas en producto, backend o data, esta clase de ejemplo te sirve para leer mejor cualquier framework de agentes que veas después, desde un wrapper simple hasta sistemas más complejos con tool calling y memoria persistente.

Qué demuestra un agente mínimo

La idea original parte de una premisa simple: si un agente puede describirse en unas 100 líneas de Lisp, entonces probablemente la mayor parte de su complejidad no está en el lenguaje, sino en las decisiones de diseño. Eso ya es una lección útil. Muchos equipos empiezan hablando de “agentes” cuando todavía no han definido qué problema van a resolver, qué acciones puede ejecutar el sistema ni cómo van a medir si funcionó.

Un agente mínimo te obliga a responder esas preguntas antes de escalar. ¿Recibe texto, un estado y una lista de herramientas? ¿Decide con una llamada al modelo o con reglas? ¿Guarda historial? ¿Se detiene solo o entra en bucle? Cuando escribes eso a mano, ves rápido qué parte es lógica de negocio y qué parte es orquestación.

También te ayuda a separar tres cosas que suelen mezclarse en demos: generación, decisión y ejecución. Un modelo puede generar una respuesta brillante y aun así el sistema fallar porque la herramienta devuelve un formato inesperado, el estado no se actualiza o el agente no sabe cuándo parar. Ahí está la diferencia entre una demo bonita y una automatización útil.

Agente no es sinónimo de chatbot

Un chatbot responde. Un agente, al menos en la definición práctica que usamos aquí, toma una entrada, evalúa contexto, decide si debe actuar y luego ejecuta una o más acciones. Esa diferencia parece menor, pero cambia toda la arquitectura. Un chatbot puede vivir en una sola función; un agente necesita control de flujo.

Por ejemplo, si un usuario escribe “revisa mi bandeja y resume los correos urgentes”, un chatbot solo podría contestar con texto. Un agente, en cambio, puede llamar a una herramienta de correo, filtrar mensajes por remitente o asunto, generar un resumen y devolverlo. En ese proceso hay pasos intermedios, errores posibles y decisiones de parada.

Por eso este tipo de implementación pequeña es tan útil: te obliga a ver el esqueleto. No necesitas 12 servicios ni una cola distribuida para entender el patrón básico. Necesitas un ciclo, un estado y una forma clara de llamar herramientas.

Lo que sí cabe en 100 líneas

En pocas líneas puedes representar una arquitectura bastante honesta. Normalmente aparecen estos bloques:

1. Un prompt o instrucción base.
2. Un estado que guarda historial o contexto.
3. Una función para llamar al modelo.
4. Un selector de herramientas.
5. Una función que ejecuta la acción elegida.
6. Un criterio para continuar o detenerse.

Eso ya alcanza para simular bastante de lo que hacen los agentes modernos. No resuelve todo, pero sí te muestra el flujo. Y cuando entiendes el flujo, te resulta más fácil evaluar si un framework te está ayudando o solo te está escondiendo complejidad.

Cómo se ve la arquitectura en Lisp

Lisp es un buen lenguaje para este experimento porque reduce el ruido. La sintaxis es mínima, las funciones son composables y la estructura del programa se ve casi como una lista de decisiones. No necesitas pelearte con un exceso de boilerplate para entender qué está pasando en cada paso.

Además, Lisp hace algo interesante con los agentes: te recuerda que la estructura del código y la estructura de los datos pueden parecerse mucho. Eso facilita escribir bucles de decisión, reglas simples y transformaciones sobre la salida del modelo. Si vienes de JavaScript, Python o TypeScript, puede sentirse raro al principio, pero precisamente por eso sirve para aprender.

La implementación original del post fuente usa esa simplicidad como ventaja. No intenta competir con un framework completo ni con una SDK llena de helpers. Su objetivo es mostrar que un agente puede ser una combinación de funciones pequeñas, bien conectadas, y que eso basta para estudiar el comportamiento del sistema.

Piezas básicas del flujo

Si lo bajas a una versión conceptual, el agente suele seguir este recorrido:

• Recibe una tarea del usuario.
• Construye contexto con estado previo.
• Pregunta al modelo qué hacer.
• Interpreta la salida.
• Si hace falta, llama una herramienta.
• Guarda el resultado.
• Decide si termina o repite.

Ese ciclo parece obvio, pero ahí se esconden varios problemas reales. Por ejemplo, si el modelo devuelve una instrucción ambigua, ¿la interpretas con reglas estrictas o vuelves a preguntar? Si una herramienta falla, ¿reintentas o abortas? Si el agente puede hacer varias acciones, ¿cuál es el límite de iteraciones?

Un ejemplo de estructura mínima

(defun run-agent (task state tools)
  (let ((context (build-context task state))
        (step 0)
        (done nil))
    (loop while (and (not done) (< step 5)) do
      (let* ((decision (ask-model context))
             (tool-result (when (needs-tool-p decision)
                            (execute-tool decision tools))))
        (setf state (update-state state decision tool-result))
        (setf done (should-stop-p decision tool-result))
        (incf step)))
    state))

No hace falta que copies esta idea tal cual. Lo útil es ver el patrón: contexto, decisión, ejecución, actualización y parada. En un proyecto real, cada una de esas funciones se vuelve más compleja, pero el esqueleto sigue siendo el mismo.

Qué aprendes sobre control de flujo

La parte más valiosa de un agente mínimo no es que “funcione”, sino que te obliga a pensar en control de flujo de forma explícita. Cuando un sistema usa IA para decidir, ya no basta con una secuencia lineal de pasos. Tienes que contemplar bifurcaciones, reintentos, errores de formato y salidas parciales.

Eso cambia la forma de diseñar software. En vez de asumir que cada función devuelve lo esperado, empiezas a pensar en guardrails: validación de salida, límites de iteración, timeout por herramienta y criterios de terminación. Si no haces eso, el agente puede quedar atrapado en bucles o producir respuestas inconsistentes.

Además, un agente pequeño te muestra que el control de flujo no depende tanto del modelo como de tu orquestación. El modelo propone, pero el programa dispone. Si dejas que la salida del modelo mande sin filtros, el sistema se vuelve frágil. Si lo controlas demasiado, pierdes flexibilidad. El punto medio se diseña, no aparece solo.

Bucle, estado y parada

Tres conceptos mandan aquí: loop, state y stop condition. El loop permite repetir hasta completar la tarea. El state guarda lo que el agente ya vio o hizo. La condición de parada evita que el sistema siga ejecutando acciones cuando ya no aportan valor.

Esto parece básico, pero muchos problemas de agentes nacen justo ahí. Un caso común es el de la iteración infinita: el modelo cree que aún falta una herramienta, la herramienta devuelve un resultado incompleto, el modelo pide otra cosa y el sistema nunca termina. Con un agente mínimo, ese fallo se ve enseguida.

Otro caso frecuente es el estado mal definido. Si no guardas el resultado de una herramienta de forma consistente, el siguiente paso trabaja con datos viejos. En automatización real, eso puede traducirse en enviar un correo incorrecto, clasificar mal un ticket o resumir una conversación sin el último mensaje.

Límites prácticos que conviene fijar

Antes de usar un agente en producción, conviene fijar límites concretos. Algunos ejemplos:

1. Máximo de iteraciones: 3, 5 o 10, según la tarea.
2. Timeout por herramienta: por ejemplo, 2 a 10 segundos.
3. Tamaño máximo de contexto: lo que tu proveedor soporte y lo que tu costo permita.
4. Nivel de autonomía: solo recomendar, ejecutar con confirmación o actuar directo.
5. Criterio de parada: respuesta final, resultado validado o error recuperable.

No son reglas universales. Son defensas contra el desorden. Cuanto más pequeño sea tu agente, más fácil es probar estos límites y ver qué rompe primero.

El punto débil de la automatización con IA

Aquí está la parte menos glamorosa del asunto: un agente pequeño sirve para automatizar, pero también deja claro por qué la automatización con IA tiene techo. El modelo no entiende tu negocio como lo entiendes tú. Puede inferir patrones, resumir, clasificar o proponer acciones, pero sigue dependiendo de cómo definiste herramientas, permisos y validaciones.

Eso significa que no conviene vender agentes como sustitutos generales de procesos humanos. Funcionan bien en tareas acotadas, con entradas razonables y salidas verificables. En cambio, cuando la tarea requiere criterio cambiante, contexto externo o responsabilidad legal, el margen de error sube rápido.

Si trabajas con equipos en Ecuador o en otros mercados de LatAm, esto importa todavía más. Muchas empresas quieren automatizar atención, soporte o backoffice con presupuestos ajustados. Ahí un agente mínimo ayuda a probar el flujo antes de invertir en una arquitectura más pesada. Pero también te obliga a medir si el ahorro compensa el riesgo operativo.

Dónde sí aporta valor

Un agente simple puede aportar bastante en escenarios concretos:

• Resumir tickets de soporte antes de que los lea una persona.
• Clasificar correos según urgencia o tema.
• Extraer datos de textos largos para alimentar un CRM.
• Proponer respuestas iniciales que luego revisa un humano.
• Encadenar una búsqueda, una validación y un reporte corto.

En todos esos casos, el valor no está en que el agente “piense”, sino en que reduzca trabajo repetitivo. Si el flujo está bien acotado, puedes ahorrar minutos por caso y escalar mejor sin meter demasiada complejidad.

Dónde se rompe rápido

También hay escenarios donde el agente se vuelve frágil muy rápido:

• Cuando la salida debe ser exacta al 100%.
• Cuando las herramientas cambian de esquema con frecuencia.
• Cuando el contexto depende de sistemas externos inestables.
• Cuando necesitas trazabilidad legal o auditoría estricta.
• Cuando el usuario espera una sola respuesta correcta y no una propuesta.

Ahí un agente mínimo te sirve más como prototipo que como solución final. Y eso no es un defecto. Es una forma sana de descubrir el límite antes de prometer demasiado.

Cómo leer el ejemplo con ojos de producto

Si miras el post fuente solo como una curiosidad técnica, te pierdes la parte útil. Lo interesante es que puedes usarlo como plantilla mental para evaluar cualquier agente que quieras construir. Antes de escribir código, pregúntate qué hace cada bloque y qué costo tiene mantenerlo.

Una forma práctica de leerlo es esta: si puedes explicar el agente en una hoja, probablemente todavía entiendes el sistema. Si necesitas cinco diagramas para justificar cada paso, quizá ya estás metiendo más infraestructura de la necesaria. Eso no significa que el sistema sea malo, pero sí que deberías justificar la complejidad con métricas o requisitos reales.

Para equipos de producto, esta lectura ayuda a evitar dos extremos. El primero es el entusiasmo excesivo, donde se quiere automatizar todo. El segundo es el escepticismo total, donde no se prueba nada por miedo a fallar. Un agente mínimo te da un terreno intermedio: pequeño, medible y fácil de auditar.

Preguntas que deberías hacer antes de construir uno

1. ¿Qué tarea exacta quiero automatizar?
2. ¿Qué parte puede equivocarse sin causar daño?
3. ¿Qué herramientas necesita realmente?
4. ¿Cuántas iteraciones son aceptables?
5. ¿Quién revisa o corrige cuando falla?

Si no puedes responder eso con claridad, el problema todavía no está listo para un agente. Tal vez necesitas reglas, un formulario, una integración simple o una automatización clásica sin IA.

Qué medir desde el día uno

No necesitas un sistema de observabilidad enorme para empezar. Sí necesitas algunas métricas básicas:

• Tasa de éxito por tarea.
• Número promedio de iteraciones por ejecución.
• Tiempo total por caso.
• Porcentaje de salidas que requieren corrección humana.
• Costo por tarea si usas un modelo de pago.

Con esos datos ya puedes saber si el agente aporta o solo añade ruido. En muchos proyectos, una automatización clásica con reglas gana por simplicidad. En otros, la IA sí reduce trabajo manual. La diferencia la marcan los números, no la intuición.

Qué te deja este enfoque para proyectos reales

La lección más útil de un agente de IA en 100 líneas de Lisp es que la complejidad no siempre está donde creemos. Muchas veces el reto no es llamar al modelo, sino decidir cuándo llamar, qué hacer con la respuesta y cómo evitar que el sistema se salga de control. Ese aprendizaje vale más que cualquier demo vistosa.

También te deja una forma más sana de pensar la automatización. En vez de preguntar “¿podemos poner IA aquí?”, conviene preguntar “¿qué parte del flujo necesita decisión flexible y cuál debería seguir siendo determinista?”. Esa pregunta te ahorra costos, reduce errores y te ayuda a elegir mejor entre reglas, scripts, agentes o una mezcla de todo.

Si quieres profundizar en cómo se implementan los agentes y sus límites, vale la pena revisar la documentación oficial de los modelos y herramientas que uses. Por ejemplo, la guía de function calling de OpenAI explica bien la parte de herramientas y salida estructurada: https://platform.openai.com/docs/guides/function-calling. También puedes revisar la documentación de Anthropic sobre tool use: https://docs.anthropic.com/en/docs/build-with-claude/tool-use. Y si te interesa la base del lenguaje que inspira este ejemplo, la referencia de Common Lisp es un buen punto de partida: https://www.lispworks.com/documentation/HyperSpec/Front/index.htm.

Tabla resumen