Arquitectura nativa de agentes: pragmatismo frente a hype

La conversación técnica en torno a los agentes de IA lleva meses girando alrededor de los mismos conceptos: orquestación, herramientas, contexto. Pero la mayoría del software existente no se diseñó pensando en que un LLM lo fuera a operar. Conectar un agente encima de una arquitectura tradicional es posible, pero genera fricciones que se acumulan. Esa es la premisa central del artículo Pragmatic Agent-Native Architecture, publicado esta semana y recogido en Hacker News.

El autor, Geoff Mays, argumenta que hay una diferencia sustancial entre «software con IA» y «software nativo de agentes». El primero añade capacidades de LLM a sistemas preexistentes. El segundo se construye asumiendo desde el principio que sus consumidores principales serán agentes autónomos, no interfaces de usuario humanas.

Qué propone el artículo

Mays articula varios principios que, leídos en conjunto, forman una guía de diseño bastante aplicable:

• Superficies de acción pequeñas y bien delimitadas. En lugar de APIs genéricas que devuelven grandes bloques de datos, el software nativo de agentes expone operaciones atómicas con semántica clara. Un agente no debería tener que inferir qué hace un endpoint; el contrato debe ser explícito.
• Estado observable y recuperable. Los agentes fallan, se interrumpen y se reinician. Un sistema bien diseñado para ellos persiste estado intermedio y permite reanudar tareas sin repetir trabajo ya hecho.
• Errores como datos estructurados, no como excepciones opacas. Si un agente recibe un mensaje de error genérico, no puede razonar sobre él. Los errores necesitan códigos, contexto y, cuando es posible, sugerencias de corrección.
• Idempotencia como requisito, no como optimización. Un agente puede invocar la misma acción varias veces por diseño o por fallo. Las operaciones deben tolerar eso sin efectos secundarios no deseados.
• Contratos de capacidades explícitos. El sistema debe poder declarar qué sabe hacer, bajo qué condiciones y con qué limitaciones. Algo análogo a lo que MCP ya formaliza en el ecosistema Claude.

Por qué importa ahora

Este tipo de reflexión llega en un momento en que el uso de Claude Code con subagentes y MCP servers está normalizando que los agentes consuman directamente servicios y sistemas internos de las organizaciones. Cuando el consumidor de tu API es Claude Opus 4.7 orquestando tareas complejas con ventana de contexto de 1M de tokens, las asunciones de diseño cambian de forma no trivial.

Los patrones de uso que estamos viendo en integraciones con MCP sugieren exactamente lo que Mays describe: los agentes se benefician enormemente de superficies de acción bien acotadas. Un MCP server que expone cincuenta herramientas genéricas es mucho menos útil que uno que expone diez operaciones precisas con esquemas de entrada y salida bien definidos. La cantidad de tokens dedicados a resolver ambigüedad se reduce, y la tasa de error también.

En el contexto de Claude Code, esto se traduce en cómo se diseñan los plugins y los skills. Un skill que asume que el agente leerá documentación de referencia para entender cómo usarlo es un skill mal diseñado. La instrucción tiene que ser lo suficientemente auto-contenida para que el agente tome decisiones correctas sin contexto adicional.

Para quién es útil

El artículo está dirigido fundamentalmente a equipos de ingeniería que están construyendo o rediseñando servicios internos y quieren que esos servicios sean consumibles por agentes sin fricciones. También es relevante para quienes desarrollan MCP servers, plugins de Claude Code o cualquier sistema que vaya a ser invocado por agentes de forma programática.

No es un artículo para equipos que solo quieren añadir un chatbot a su producto. El enfoque es estructural: implica tomar decisiones de arquitectura que afectan al diseño de APIs, al manejo de estado y a la estrategia de errores desde el principio del ciclo de vida del sistema.

Los comentarios en Hacker News están todavía escasos en el momento de escribir esto, lo que probablemente refleja que la pieza es técnica y específica, no un titular de gran alcance. Eso no le resta valor; al contrario, es el tipo de contenido que se comparte internamente entre equipos antes de una decisión de arquitectura.

---

Opinión EP: Los principios que describe Mays no son nuevos en ingeniería de software, pero sistematizarlos con el agente como consumidor explícito es un ejercicio útil que faltaba hacer con rigor. Vale la pena tenerlo cerca la próxima vez que se diseñe un MCP server desde cero.