Por qué deberías crear un agente tú mismo

• Los agentes LLM son una estructura tecnológica que se entiende mejor implementándolos directamente que solo como concepto, porque así se percibe cómo funcionan en la práctica
• Con apenas unas decenas de líneas de código Python, se puede crear un agente conversacional usando la OpenAI Responses API; si además se agrega la función de tool call, puede actuar de forma autónoma
• La esencia del agente es un bucle de llamadas repetidas a un LLM sin estado; al gestionar manualmente el contexto de la conversación, se pueden implementar diálogos de múltiples turnos
• La ingeniería de contexto es un problema al nivel de una tarea real de programación, que requiere diseñar cómo optimizar entradas, salidas y descripciones de herramientas dentro del límite de tokens
• El diseño de agentes es hoy un espacio abierto de problemas de ingeniería de software, donde incluso desarrolladores individuales pueden probar nuevos enfoques mediante experimentación

---

La simplicidad de escribir un agente

• Un agente LLM puede implementarse sin configuraciones complejas usando solo la OpenAI Responses API
  • En el código de ejemplo, se almacena la conversación entre el usuario y el modelo mediante una lista context, y esta se reutiliza en llamadas repetidas para generar respuestas conversacionales como ChatGPT
• Se pueden crear dos contextos, uno con una “buena personalidad” y otro con una “mala personalidad”, para simular una conversación de múltiples personalidades
  • El LLM no tiene estado, y la continuidad de la conversación se mantiene con un arreglo de cadenas (context) administrado por el usuario
• Incluso con esta estructura simple, es posible tener conversaciones de múltiples turnos y experimentar directamente cómo opera un LLM

Integración de herramientas y funcionamiento autónomo

• Al agente se le puede registrar una función ping como herramienta para añadir la capacidad de comprobar el estado de conectividad de red
  • La API de OpenAI exige definir las herramientas en formato JSON, y cuando el LLM solicita usar una herramienta, el código Python la ejecuta y luego devuelve el resultado
• El LLM hace ping automáticamente a varios hosts (google.com, www.google.com, 8.8.8.8) incluso sin instrucciones explícitas
  • Esto muestra que, solo con tener “permiso para usar herramientas”, el LLM pudo tomar decisiones autónomas
• Todo el bucle sigue simplemente la estructura “solicitud de uso de herramienta → ejecución → devolución del resultado”, y aun así permite implementar un agente autónomo sin lógica de control compleja

Aplicaciones reales y crítica a MCP

• Aunque el código de ejemplo es simple, se puede ampliar de manera práctica combinándolo con herramientas adicionales (como traceroute) o con almacenamiento de contexto basado en SQLite
• MCP (Multi-Context Protocol) no es más que una interfaz de plugins para Claude Code o Cursor, no una tecnología indispensable
  • Si se trabaja directamente con la API, se puede implementar la misma funcionalidad incluso sin MCP
• MCP solo resulta útil en entornos donde no se tiene control sobre el código y, de hecho, puede limitar la flexibilidad de la arquitectura del agente
• La seguridad en LLM es compleja, pero se puede diseñar una estructura segura mediante contextos aislados y restricciones sobre las herramientas

La importancia de la ingeniería de contexto

• La “ingeniería de prompts” es una idea exagerada, pero la ingeniería de contexto sí es un problema real de programación
  • La cantidad de tokens dentro de la ventana de contexto es limitada, y tanto las entradas como las salidas y las descripciones de herramientas ocupan espacio
  • Si se supera ese límite, la calidad de respuesta del modelo se vuelve inestable
• Como solución, se pueden crear subagentes (sub-agent) con distintos contextos y herramientas, diseñados para resumirse e intercambiar información entre sí
  • Esta estructura puede extenderse a experimentos diversos, como redes de agentes en forma de árbol o compresión basada en resúmenes en tiempo real
• Incluso ideas complejas tienen un nivel de simplicidad que permite implementarlas en 30 minutos

Problema de ingeniería abierto y valor de la experimentación

• Actualmente, numerosas startups están desarrollando agentes para detección de vulnerabilidades, y los desarrolladores individuales también pueden realizar los mismos experimentos
• El diseño de agentes incluye retos de ingeniería aún no resueltos como los siguientes
  • El equilibrio entre no determinismo y programación estructurada
  • La verificación contra la realidad (ground truth) y la prevención del cierre prematuro de bucles
  • Los formatos de intercambio de datos entre agentes multinivel (JSON, SQL, Markdown, etc.)
  • La asignación de tokens y el control de costos
• Estos problemas no requieren investigación a gran escala, sino que también pueden explorarse mediante experimentos individuales, y cada iteración puede probarse en cuestión de decenas de minutos
• En definitiva, la experiencia de crear un agente por cuenta propia es el punto de partida para comprender la tecnología LLM

[GN⁺]

Opinión de Hacker News

• Hay muchísimas cosas por hacer. Me gustaría construir un CPU con compuertas NAND directamente en una protoboard, y también hacer un CDN en Rust, pero no me alcanza el tiempo.
  En cambio, seguí el tutorial de Karpathy y construí un LLM; sentí que experimentar poco a poco de esta manera está bastante bien.

  • Se siente como una curva sin fin. Antes armé una computadora de 8 bits en una protoboard, y esta vez me obsesioné con el entrenamiento de vuelo (PPL).
    Siempre que siento que “ya terminé”, la línea de meta parece alejarse más. Al final, creo que los que somos así nunca quedamos completamente satisfechos.
  • Al principio del TFA explican lo fácil que puede ser hacerlo. Ese es precisamente el punto central del texto.

• En el ejemplo usan GPT-5, pero la interfaz de consultas ya está a nivel de estándar de la industria.
  Por ejemplo, si conectas OpenRouter.ai, puedes cambiar fácilmente de modelo y proveedor durante el runtime.
  También ofrecen modelos gratuitos, como DeepSeek, pero son lentos y limitados. Aun así, son excelentes para experimentar.

• Hace unos meses construí mi propio agente en Ruby. Fue realmente divertido.
  La lógica central tenía solo cuatro líneas; conceptualmente era sorprendentemente simple.

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• Hace 2 años hice un agente en 25 líneas de PHP; en ese momento ni siquiera existía tool calling, pero funcionaba bastante bien.
  Los LLM me parecen herramientas de manipulación de texto UNIX como sed o awk: les das una entrada y una instrucción, y te devuelven una salida.
  Si combinas llamadas a LLM de esta forma y construyes bucles o bifurcaciones, obtienes un sistema bastante potente.
  Código relacionado: hubcap, llm

  • Me gusta muchísimo hubcap. Aunque tiene poco código, los resultados eran impresionantes.
    Me inspiró mucho el artículo de Simon Willison.

• Me identifiqué especialmente con la parte de construir tu propia alternativa a Claude Code. Crear un agente de programación con auto-mejora se siente casi como magia.
  Puedes cambiar de modelo con libertad, y si usas modelos rápidos como Cerebras, se nota muchísimo la diferencia incluso en llamadas de herramientas interactivas.
  Si además le agregas memoria, reconocimiento de voz, etc., se vuelve mucho más eficiente. Se puede implementar en unos minutos y es realmente divertido.

  • Tengo curiosidad por saber qué modelo de reconocimiento de voz usan. Whisper era lento y no muy preciso, y los modelos de audio de GPT rechazan respuestas con frecuencia.
    Los modelos de Google tenían baja calidad, y los de Mistral son rápidos pero a veces reaccionan al texto.
    Así que a veces termina transcribiendo no lo que dije, sino el flujo de conciencia del LLM.
  • Me encanta la expresión “build your own lightsaber”.
    Al principio lo hice para entender la estructura interna, pero como resultó ser más simple de lo que pensaba, ahora le estoy agregando directamente las funciones que quiero.
    Puedo incorporar funciones más rápido que un producto de equipo. Los agentes tienen una estructura sorprendentemente simple.
  • No sabría por dónde empezar para entrar en esto. Ni siquiera había oído hablar de Cerebras. Por ahora solo uso Copilot en VS Code.
    Me pregunto si eso está basado en modelos locales.
  • Cerebras ahora ofrece glm 4.6. Sigue siendo increíblemente rápido, y ahora además es mucho más inteligente.

• Este texto da ganas de volver a crear la filosofía Unix —herramientas que hacen bien una sola cosa—.
  No solo simplifica los agentes, también mejora la seguridad.

  • En 2021 hice un agente para probar conexiones de red, y si le delegas herramientas básicas como ping, dig, traceroute, da resultados bastante buenos.
    No era tan perfecto como un sistema de telemetría construido directamente por humanos, pero podías lograr un 90% de utilidad con mucha más facilidad.
  • También se puede imaginar un conjunto de herramientas de propósito limitado expuesto directamente a humanos.
  • Para hacer bien una sola cosa hacen falta más herramientas, y con eso también crece la comprensión del contexto.
    Creo que el tamaño ideal de un LLM estaría en un punto intermedio, un poco por encima de las herramientas Unix tradicionales.

• Me surge la duda: ¿de verdad hace falta construir agentes?
  Con todos los proveedores de IA operando con pérdidas, soy escéptico de que pueda existir un modelo de ingresos sostenible.

  • Si lo construyes tú mismo, puedes entender intuitivamente cómo funciona un agente y cuáles son sus límites. Ese es el punto clave.
  • Esto es simplemente un texto sobre experimentar con la tecnología por diversión. No tiene nada que ver con monetización.
    Es una lógica parecida a citar las pérdidas de Astral como razón para no usar Python.
  • No todas las empresas de IA operan con pérdidas.
    Necesitan financiamiento porque el costo de entrenar el siguiente modelo es alto, pero la etapa de inferencia sí es rentable.
  • Incluso tú mismo podrías convertirte en proveedor de IA.
  • Este comentario transmite un poco de cansancio emocional. Me pregunto si será un desarrollador con muchos años de experiencia.

• La parte de ingeniería de contexto me llegó especialmente.
  Estoy construyendo un asistente personal, y tiene más memoria, seguimiento de tareas y capacidad de resolución de problemas que un agente general.
  Lo diseñé para que varios agentes conversen entre sí y resuelvan problemas, y el primer agente cumple el rol de supervisor de gestión de tareas.
  Cuanto más se profundiza en este proceso, más se convierte en un problema de ingeniería.
  Lo expliqué con más detalle en mi post del blog.

  • Suena como un proyecto realmente genial.

• A todos les gusta construir agentes, pero a nadie le gusta depurarlos.
  Al principio funcionan como por arte de magia, pero luego se van acumulando fallas probabilísticas y se vuelve difícil reproducirlas.
  Si cada paso toma 0.5 segundos, terminas esperando de 10 a 20 minutos para averiguar en qué parte falló.

  • Por eso construí una herramienta de ejecución paralela para correr cientos de veces el código corregido
    y también volver a ejecutar escenarios anteriores para verificar que nada se haya roto.

• Basándome en el código proporcionado, construí un MCP: gurddy-mcp.fly.dev
  El código fuente puede verse en el repositorio de GitHub