Diseñar agentes sigue siendo difícil

• El proceso de construir agentes sigue siendo complejo, y las abstracciones de los SDK suelen romperse en la etapa real de uso de herramientas
• La gestión de caché varía según la plataforma, por lo que manejarla manualmente resulta más predecible y eficiente; se prefiere el enfoque de puntos de caché explícitos del SDK de Anthropic
• El bucle de refuerzo (reinforcement loop) cumple un papel clave en el seguimiento del estado de las tareas y en la recuperación ante fallos; los fallos deben aislarse por separado para evitar el colapso del bucle
• Para la gestión de estado compartido, es importante una jerarquía similar a la de un sistema de archivos, usada como infraestructura base para el intercambio de datos entre herramientas de ejecución de código e inferencia
• Las herramientas de salida y la selección de modelos siguen siendo complicadas; modelos como Haiku, Sonnet y Gemini se mantienen entre las principales opciones, lo que refleja que la complejidad del diseño de agentes continúa

---

Elección del SDK para agentes

• Al construir un agente, hay que decidir entre usar directamente los SDK base de OpenAI, Anthropic y otros, o usar capas de abstracción de alto nivel como Vercel AI SDK o Pydantic
  • El autor menciona que antes usó solo la abstracción de proveedores de Vercel AI SDK, pero que hoy no repetiría esa elección
• Como las diferencias entre modelos son grandes, hay que construir una capa de abstracción de agentes propia, y las abstracciones de los SDK existentes no encajan bien
  • Hay diferencias sutiles en control de caché, requisitos de refuerzo y prompts de herramientas
• Vercel SDK presenta problemas con el manejo de herramientas del lado del proveedor
  • Existe un caso en el que la herramienta de búsqueda web de Anthropic daña el historial de mensajes
  • Al usar directamente el SDK de Anthropic, la gestión de caché y los mensajes de error resultan más claros
• En conclusión, por ahora se considera más conveniente usar directamente los SDK sin una capa de abstracción

Lecciones sobre la gestión de caché

• El enfoque de caché difiere entre plataformas, y Anthropic cobra por el caché y exige una gestión explícita
  • Se prefiere el manejo manual porque hace más predecibles el costo y el uso del caché
• El caché explícito permite ejecutar ramas de conversación o editar el contexto
  • Se pueden definir varios puntos de caché, por ejemplo después del prompt del sistema o al inicio de la conversación
• Para mantener el caché, el prompt del sistema y la selección de herramientas deben ser estáticos, mientras que la información dinámica, como la hora, debe enviarse en mensajes posteriores
• Se aprovecha activamente el bucle de refuerzo junto con el caché para mejorar la previsibilidad de costos y el control

Refuerzo dentro del bucle del agente

• Al ejecutar herramientas, además de devolver un resultado simple, es posible reinyectar al bucle información como objetivos, estado de la tarea o causas de fallo
• Herramientas de autorrefuerzo (self-reinforcement) como la herramienta de escritura de tareas pendientes de Claude Code ayudan al avance del bucle
• En cambios del entorno o momentos de recuperación tras fallos, se puede inyectar información de cambio de estado para asegurar la estabilidad del bucle
  • Ejemplo: si se reintenta con datos dañados, se inserta un mensaje para volver a una etapa anterior

Aislar fallos (Isolate Failures)

• Las tareas en las que se esperan fallos repetidos se ejecutan por separado en un subagente (subagent), y solo los resultados exitosos se reportan al bucle superior
  • El resumen de intentos fallidos se aprovecha como material de aprendizaje para la siguiente tarea
• En el SDK de Anthropic, la función de edición de contexto (context editing) permite eliminar el registro de fallos
  • No se conserva toda la información de fallos, sino solo las partes necesarias
  • Sin embargo, la edición de contexto puede invalidar el caché y aumentar el costo

Subagentes y sistema de archivos compartido

• La mayoría de los agentes se basan en ejecución y generación de código, por lo que necesitan un almacén de datos común
  • Para eso se usa un sistema de archivos virtual (VFS)
• Herramientas diversas como generación de imágenes, compresión e inferencia deben compartir las mismas rutas de archivo
  • Las herramientas ExecuteCode y RunInference deben poder acceder al mismo sistema de archivos
• Esta estructura es esencial para eliminar cuellos de botella en el intercambio de datos y procesar trabajo continuo dentro del bucle

Herramienta de salida (Output Tool)

• El agente no opera como una sesión de chat, sino como un bucle interno de mensajes privado, y la comunicación con el exterior se realiza mediante una herramienta de salida
  • La herramienta de salida se encarga de la comunicación externa, como el envío de correos electrónicos
• Es difícil controlar el tono y el estilo de la herramienta de salida, y al usar un LLM auxiliar (Gemini 2.5 Flash) aparecen caída de calidad y demoras
  • Como la herramienta secundaria no tiene suficiente contexto, puede generar resultados inexactos
• Si al finalizar el bucle no se llama a la herramienta de salida, se induce su invocación insertando un mensaje de refuerzo

Selección de modelos

• Haiku y Sonnet se usan como modelos principales del bucle porque tienen buen rendimiento en llamadas a herramientas
• Gemini 2.5 es adecuado para resumir documentos grandes, procesar PDF y extraer información de imágenes
  • El modelo Sonnet tiene la desventaja de activar con frecuencia filtros de seguridad
• Los modelos de la familia GPT no han mostrado grandes resultados en el bucle principal
• No se puede juzgar el costo total solo por el costo de tokens
  • Un mejor modelo para llamadas a herramientas puede completar la misma tarea con menos tokens

Pruebas y evaluación (Evals)

• Se señala que automatizar las pruebas y evaluaciones de agentes es el problema más difícil
  • A diferencia de los prompts, no se puede evaluar de forma simple desde sistemas externos
  • Se necesita observabilidad (observability) o instrumentación (instrumentation) basada en datos de ejecución reales
• Menciona que hasta ahora no ha encontrado un método de evaluación satisfactorio

Actualización sobre agentes de programación

• No ha habido grandes cambios en lo relacionado con agentes de programación
  • Recientemente está probando el agente Amp y valora mucho la estructura de interacción entre el subagente Oracle y el bucle principal
• Amp y Claude Code transmiten la sensación de estar diseñados por desarrolladores que realmente usan sus propias herramientas

[GN⁺]

Opiniones de Hacker News

• Fundé una empresa en este espacio hace unos 2 años. Ahora va bien
  Lo que aprendí en estos 2 años es que muchas técnicas son optimizaciones temporales para compensar las limitaciones actuales de los LLM. Como la tecnología avanza tan rápido, el problema de hoy puede desaparecer mañana
  Antes, cuando AWS no tenía cifrado de disco, el equipo pasó 3 meses implementándolo por su cuenta, y poco después AWS lanzó cifrado estándar con un solo clic. Al final fue una pérdida de tiempo
  Así que lo que aprendí es que, a veces, no hacer nada es lo mejor

  • Creo que esa es la idea clave. Estos días mis colegas hacen talleres de IA y dicen que “inventaron” nuevos patrones, pero la mayoría quedan obsoletos la semana siguiente
    Ya terminó la época en que aprendíamos patrones como lenguaje común; ahora la vida media de los patrones de IA es de una semana. Incluso si le preguntas a 10 expertos qué es un “agent”, obtendrás 10 respuestas distintas
  • Viendo la velocidad del progreso en IA, si esperas lo suficiente quizá todo termine reduciéndose a usar OpenAI directamente
  • Me pregunto si tienen una estructura rentable donde los ingresos superan los costos operativos. Siempre me ha costado creer que sea posible ganar dinero con agents. Me gustaría saber cuál es el secreto
  • Saber bien cuándo ‘no hacer nada’ tiene que ver con la capacidad de evaluar si el problema que maneja el equipo es central o periférico
  • De acuerdo. Hoy en día esperar también puede ser una estrategia. Pero si esperas demasiado, puedes caer en la trampa de no hacer nada hasta que llegue la AGI

• En los últimos 2 años probé varios SDK de agents, y al construir uno por mi cuenta resultó ser mucho más complejo de lo que pensaba
  El Claude Code SDK (ahora Agent SDK) es excelente, pero todavía no está totalmente desacoplado de Claude Code. Por ejemplo, los skills tienen que colocarse directamente en el sistema de archivos
  El SDK de OpenAI permite rastreo y evaluación automáticos desde el dashboard gracias a su fuerte integración con la plataforma, pero es difícil integrarlo con modelos de terceros
  Google Agent Kit todavía no tiene SDK de Typescript, y Mastra requiere levantar un servidor, lo cual es incómodo
  Ahora estoy probando el SDK de SmythOS, que da mucha libertad para elegir proveedor de modelos y definir la arquitectura
  Me pregunto si la estructura que usan actualmente es Agent → SubAgents → SubSubAgents, o si es de tipo planner-executor

  • La mayoría de los SDK se vuelven una pesadilla en cuanto sales de lo básico. Por eso implementé el mío usando la librería cliente de OpenRouter
    Hay más código, pero el modelo mental es simple, así que es mucho más fácil de entender. Hago un loop al estilo ReAct, repitiendo razonamiento y llamadas a herramientas
    Al final, incluso sin SDK puedes implementar por tu cuenta agent handoff o workflows
  • Creo que el término ‘sub-agent’ casi no sirve. Al final solo abstrae una llamada a herramienta, y fuera del loop principal lo único importante es un contrato simple de entrada y salida
  • Se dijo que Claude Code solo soporta modelos de Anthropic, pero con Claude Code Router también se pueden integrar otros modelos
  • Estoy usando la versión en Go de Google ADK; todavía está verde, pero me gusta por su composición de workflows y compatibilidad entre vendors
  • También probé el Strands Agents SDK de AWS, que soporta las APIs de los principales vendors incluso sin Bedrock, y el diseño de la API es muy flexible (trabajo en AWS, pero esta es mi opinión personal)

• Comparto algunos principios de diseño de agents que aprendimos

  1. Si generas mucho código, Claude Code / Agent SDK es lo más eficiente
  2. Un riesgo mayor que la dependencia de un vendor es construir un producto peor que ChatGPT
  3. Claude Code tiene muy buena autoconciencia, así que responde de inmediato y con precisión a preguntas sobre sí mismo
  4. Si le das una computadora real a un agent, se vuelve mucho más poderoso. Nosotros usamos e2b.dev, pero Modal también está bien
     Como referencia, nuestra empresa Definite es una plataforma de datos operada por ingenieros de datos con IA, al estilo Heroku
  • Claude es creativo, pero en bases de código complejas puede alucinar y hacer reward hacking. En esos casos Codex es más estable
  • Creo que el problema es que muchos productos salen con una calidad peor que la versión web de ChatGPT
  • En vez de construir a la fuerza un sistema propio de agents, conviene aprovechar herramientas terminadas como Claude Code y concentrarse en crear valor real
  • Claro, dejar “todo en manos del big tech” también es riesgoso. El proceso de construir, aprender y compartir por cuenta propia es importante. Yo también estoy creciendo rápido con ADK y extensiones de VS Code

• Llevo años construyendo agents, y lo mejor que hice fue crear mi propio framework
  Varias capas de abstracción open source se vuelven imposibles de mantener cuando cambian los SDK, y al final colapsan

  • Pienso igual. El núcleo de un agent es la entrada y salida estructuradas, el registro de herramientas y loop de invocación, y la delegación entre agents
    Construí OpusAgents sobre PydanticAI; es un framework open source simple pero escalable, más sencillo que un servidor MCP
  • Como autor del post, coincido. Organicé mis ideas relacionadas en este post
  • Nosotros también, al crear un chatbot de soporte al cliente, adoptamos una arquitectura basada en chatrooms en lugar de la estructura existente. El frontend solo envía mensajes, y el backend amplía funciones de forma gradual
  • Aun así, construir por cuenta propia un framework completo es un trabajo enorme. A largo plazo, es posible que las plataformas de agents se estandaricen como los motores de juego

• Últimamente se está repitiendo la sobreactuación de abstracciones y complejidad que vimos en los inicios de LangChain/RAG
  Al final, puedes pensar en un agent como una estructura REPL simple (Read, Eval, Print, Loop).
  Una versión liviana que implementé con esta idea fue mucho más estable que los SDK pesados

  • Pero en casos de uso realmente complejos sí se necesitan subagents especializados y una estructura para compartir datos. Un loop simple tiene sus límites

• El problema más difícil en agents es testing y evaluación (evals).
  Evaluarlo con sistemas externos es complicado porque hay demasiadas entradas y necesitas observar datos durante la ejecución
  Todavía no tengo claro qué enfoque funciona mejor

  • Me preocupa que muchos despliegues de agents de IA parezcan depender del instinto, sin pruebas formales
  • Si ves la documentación de evaluación de ADK de Google, dicen que como el resultado cambia en cada ejecución es difícil definir criterios de aprobado/reprobado. Al final terminan evaluando con otro LLM

• Incluso en lo más básico del desarrollo de agents faltan lineamientos claros
  Por ejemplo, al manejar tipos de entrada/salida en herramientas de función, al pasar IDs numéricos pueden ocurrir errores de serialización o pérdida de precisión
  Al final lo resolví convirtiéndolos en strings
  Si ves la documentación de OpenAI (link) y este issue de Google ADK (link),
  dicen que “el resultado debe ser un string”, pero en los ejemplos reales devuelven dicts o números. Esa inconsistencia genera confusión

• Estoy usando el producto de cierta empresa de agentic coding (prefiero no decir el nombre)
  Estoy satisfecho porque ellos se encargan de todo — releases de modelos, evaluaciones, gestión de subagents, facturación — y yo solo puedo concentrarme en mi trabajo

  • Probablemente esa empresa sea Amp de Sourcegraph. Al principio estaba verde, pero ahora tiene un nivel de madurez bastante bueno

• En los últimos dos meses implementé agents para distintas tareas. Al principio usé Claude Code, pero por la dependencia del vendor y los límites de uso terminé creando mi propio runtime
  Por ahora solo soporta OpenAI, pero lo diseñé para poder agregar Claude o Gemini también
  Lo publiqué como open source por si sirve de referencia → agent-composer

• Mi consejo es simple: no uses SDK; corre tú mismo un loop while y maneja JSON
  Solo si controlas directamente el tamaño del contexto y los errores puedes crear un agent realmente flexible