Cómo construir un agente de IA desde cero (y por qué hacerlo)

Esta semana se hizo popular un tweet de Andrej Karpathy que decía que nunca se había sentido tan “atrás” como programador: que nuestra profesión está siendo refactorizada en tiempo real, que hoy podemos ser 10x más productivos si sabemos encadenar bien todo lo nuevo que apareció en el último año, y que si no lo aprovechamos, casi que es un skill issue. Hablaba de este nuevo nivel de abstracción lleno de agentes, subagentes, prompts, contexto, memoria, herramientas, plugins, workflows, integraciones con IDEs… y de que, básicamente, nos dieron una herramienta alienígena muy poderosa, sin manual, mientras todo tiembla alrededor.

Y la verdad, coincido bastante.

Es imposible estar al día con todo: frameworks nuevos cada semana, librerías, SDKs, patrones, siglas que aparecen de la nada. Por eso, en medio de ese ruido, cada vez estoy más convencido de que lo importante es entender los fundamentos. No solo aprender a usar frameworks de agentes, sino primero comprender cómo funciona y qué implica armar un agente desde cero, sin magia, sin abstracciones que te escondan lo esencial.

Con esa cabeza llegué al artículo de Philipp que trabaja como Developer Relations en Google. Es necesario bajar un cambio, ir a lo básico y entender de verdad qué hay debajo de conceptos que hoy están por todos lados.

En el artículo, explica paso a paso cómo construir un agente de inteligencia artificial desde cero usando Gemini 3 y otros conceptos clave de ingeniería de agentes, y esto fue lo que aprendí más un par de experimentos que hice con el código del artículo.

Para mí, lo más importante que aprendí es que un agente no es algo mágico ni extremadamente complejo: es básicamente un modelo de lenguaje grande (LLM) que se ejecuta en un bucle y que, además, puede usar herramientas que lo ayudan a interactuar con el mundo real.

Lo que distingue a un agente de un simple chatbot es justamente su capacidad de actuar, no sólo de responder. Para que eso pase, el agente necesita:

Un modelo de razonamiento (el LLM, como Gemini 3 en el artículo de ejemplo).

Herramientas que puede invocar (por ejemplo: leer archivos, listar directorios, llamar APIs).

Un contexto o memoria que guíe su razonamiento.

Un bucle de vida (loop) que haga que observe, piense, actúe y vuelva a observar hasta completar su tarea.

Philipp pone énfasis en algo que me quedó muy claro: el “loop del agente” es la columna vertebral de todo. Funciona así:

Se definen las herramientas que el agente puede usar (con sus descripciones y parámetros).

Se manda al modelo la entrada del usuario + herramientas disponibles.

El modelo decide si necesita usar una herramienta (y cuál).

El sistema ejecuta esa herramienta y devuelve el resultado al modelo.

El modelo usa ese resultado para decidir el siguiente paso (otra herramienta o la respuesta final).

Eso significa que el agente piensa dinámicamente según lo que vaya ocurriendo, no sigue un camino prefijado. Esto marca dos diferencias importantes con los clásicos programas if-else que construimos normalmente:

• El comportamiento no es determinístico, cada ejecución podría dar un comportamiento diferente.

• La lógica de control no la escribe uno mismo línea por línea, sino que emerge de las decisiones del modelo en cada iteración del loop.

Otro punto importante del artículo y de la construcción de agentes, es que las herramientas son como las manos y los ojos de un agente. El modelo por sí solo solo genera texto, pero con herramientas puede:

Listar archivos de un directorio.

Leer o escribir en archivos.

Llamar APIs externas.

Interactuar con sistemas reales. Lo que implica acceder a información real y actualizada.

El truco está en definir estas herramientas claramente, con descripciones precisas para que el modelo entienda cuándo usarlas

En los ejemplos los divide en fases claras:

1. Primer prototipo — “chatbot con memoria”

Antes de que sea un agente, uno puede empezar con un modelo que simplemente mantiene la conversación y recuerda lo que pasó antes. Eso no es un agente todavía, pero es la base.

2. Agregar herramientas

Después se le dan herramientas al modelo y se define cómo usarlas. Entonces el modelo puede decidir “mirar dentro de una carpeta”, “leer un archivo”, etc.

3. Cerrar el bucle — ejecutar y responder

El agente intercepta las llamadas a herramientas que propone el modelo, ejecuta esas funciones en el código y devuelve los resultados para que el LLM decida el siguiente paso.

4. Ejecutable en CLI

Al final, con muy poco código (menos de 100 líneas), se puede tener un “agente funcional” que corre en una terminal y recibe órdenes del usuario como en un chat.

Probé el programa resultante y es gracioso como replica con exactitud la personalidad que todos conocemos de Linus Torvals.

Pero todos estos ejemplos estan enfocados en el uso del stack de Google, como lo son Gemini y Google GenAI Python SDK. ¿Cómo sería hacerlo con OpenAI o Claude con sus respectivos modelos y SDKs?

Para el caso de OpenAI usé su sdk para Python y su API de Responses que es la forma moderna y recomendada de hacerlo. Los principales cambios están en el método run:

Dado que el sdk tiene una API diferente es necesario realizar algunas adaptaciones en el armado de mensajes y en el tool calling para que funcione.

En el caso de Claude usé el SDK de Anthropic para Python y cree una función helper para adaptar los datos de los tools a lo que la API esperaba.

En los tres casos lo probé con el modelo más rápido y más barato que tienen los tres proveedores que en este momento son: Gemini 3 Flash, GPT-5 mini, y Claude 4.5 Haiku. Lo destacable de la prueba es que Gemini fue el único que replicó la personalidad de Linus Torvals. Claude y GPT en este caso fueron “demasiado amables”.

Además de explicar cómo se construye, se dan pautas que son muy útiles para diseñar bien un agente:

El contexto que le das al modelo (qué información ve y cuándo) es clave para que pueda razonar bien. No es solo “prompting”, es diseñar bien qué datos entran al contexto

Si una herramienta es ambigua o compleja de entender para el modelo, no la va a usar bien. Hay que describirlas de forma explícita

Se recomienda no complicar el sistema desde el principio con múltiples agentes y sub-agentes: primero lograr que un agente básico funcione estable y bien

Para tareas sensibles (como enviar emails o ejecutar código), puede ser mejor pedir confirmación humana antes de que el agente ejecute la herramienta.

Después de leer el artículo, lo que más me quedó en claro es que:

Un agente de IA no es magia, es una arquitectura bien pensada alrededor de un LLM y herramientas.

Los pasos para construir uno son simples, pero hacerlo confiable y robusto requiere disciplina.

Con pocos conceptos bien definidos, podés pasar de un chatbot tradicional a un agente con capacidades reales para actuar.

Y algo clave: una vez que entendés bien estos fundamentos, frameworks de agentes como Google ADK te permiten agilizar todo lo repetitivo (loops, manejo de herramientas, contexto, orquestación) y así enfocarte en lo que realmente importa: tu caso de uso particular y el valor que querés construir, en vez de reinventar la rueda cada vez.

En resumen, el artículo no solo muestra cómo armar un agente desde cero, sino que también te deja bien parado para después aprovechar frameworks más avanzados con criterio, sabiendo qué hacen por debajo y cuándo realmente valen la pena.

Si te interesa meterte de lleno con agentes, este artículo es una excelente guía práctica. Para los que les interesa el código, acá está el repo.