El Momento
Cada pocos años surge un nuevo lenguaje de patrones que cambia cómo construimos software.
En 1994, el Gang of Four nos dio Design Patterns. En 2003, Hohpe y Woolf nos dieron Enterprise Integration Patterns. Después vinieron: Microservices Patterns, Cloud Patterns, y ahora Agent Patterns.
Pero hay un vacío. Los agentes pueden conversar y razonar solos, pero no pueden “actuar” sin herramientas. Estándares como MCP han desbloqueado cómo los agentes descubren y llaman herramientas. La capa de protocolo está resuelta. Lo que falta es la capa de diseño: patrones para construir herramientas que los agentes puedan usar bien. Esa es la capa que hace falta.
Lo que Aprendimos
Hemos construido más de 8,000 herramientas en 100+ integraciones, el catálogo más grande de herramientas listas para agentes en producción. No son simples wrappers de API. Son herramientas de nivel productivo que manejan los casos límite: rate limits, paginación, refresco de auth, fallas parciales.
Cada error que se puede cometer lo cometimos: descripciones poco claras, errores inútiles, parámetros que tenían sentido para nosotros pero no para un LLM. Aprendimos que “funcionar” no es lo mismo que “ser usable por un agente”.
Una herramienta puede devolver los datos correctos y aun así fallar porque el agente no supo cuándo llamarla.
Tras miles de iteraciones, los patrones emergieron. Construimos checklists internos, procesos de revisión y, con el tiempo, un framework que nos permitió entregar herramientas de calidad de forma consistente. No es teoría: es lo que funciona cuando construyes herramientas que los agentes usan de verdad.
Los documentamos. Ahora los compartimos. Explora el catálogo completo en arcade.dev/patterns.
El Cambio de Paradigma
Durante dos décadas construimos integración sobre un modelo simple: el middleware orquesta, las aplicaciones consumen. Los ESBs enrutaban mensajes. Los motores de flujo de trabajo imponían el orden. La capa de integración decidía qué pasaba, cuándo y en qué secuencia.
Las herramientas para agentes colapsan toda esa capa. No hay bus. No hay flujo predeterminado. El agente decide qué herramienta llamar, interpreta los parámetros, maneja la respuesta y determina qué hacer después. La lógica de orquestación que vivía en tu middleware ahora es emergente, reconstruida por el agente en cada invocación, sin garantía de que se ejecute igual dos veces.
Esto no es integración tradicional con un nuevo consumidor. Es un tipo de consumidor completamente nuevo y los fundamentos han cambiado.
Aspecto | Tradicional (2003) | Herramientas para Agentes (2025+) |
Consumidor | Aplicaciones | Agentes de AI (LLMs) |
Modelo de Estado | Mensajes sin estado | Sesiones con estado |
Enrutamiento | Flujos predeterminados | Selección por agente (no determinístico) |
Manejo de Errores | Colas de mensajes fallidos | Guía de recuperación para reintentos |
Documentación | Legible por humanos | Optimizada para agentes |
Composición | Orquestación ESB | Encadenamiento por agente |
Cuando un LLM selecciona qué herramienta llamar, interpreta parámetros y decide qué hacer con los errores, las restricciones de diseño son fundamentalmente distintas. Los patrones viejos no encajan. Necesitamos unos nuevos.
¿Por dónde empiezas? Con una forma de clasificar lo que estás construyendo.
Tres Ejes de Clasificación
Cada herramienta existe en algún punto de tres dimensiones. Entender dónde te ayuda a elegir los patrones correctos.
La madurez es el eje vertical: qué tan sofisticada es tu herramienta. Las herramientas atómicas hacen una sola cosa: get_user(id). Las orquestadas coordinan muchas y gestionan estado entre llamadas. Profundizaremos en este eje en el modelo de madurez más adelante.
La integración es a qué se conecta tu herramienta: APIs, bases de datos, sistemas de archivos u operaciones de sistema. Cada una trae restricciones de diseño distintas. Las herramientas de base de datos necesitan el patrón de Operación Idempotente porque los agentes reintentarán al hacer timeout y tu herramienta debe manejar llamadas duplicadas sin problemas.
El acceso es cómo funciona la ejecución. Las herramientas síncronas son directas: llama, espera, responde. Pero una herramienta de generación de reportes que bloquea 45 segundos hará timeout o dejará al agente colgado. Ahí entra el patrón Async Job: el agente llama a generate_report(), recibe un job ID y hace polling con check_status(job_id) hasta que termina.
Tus coordenadas en los tres ejes determinan qué patrones necesitas. Una herramienta Compuesta × Base de Datos × Async tiene requisitos de diseño muy distintos a una Atómica × API × Sync.
Aspectos Transversales
Saber dónde se ubica tu herramienta en los tres ejes te dice cuáles patrones revisar. Pero cuatro aspectos atraviesan todos los ejes: experiencia del agente, límites de seguridad, recuperación guiada por errores y composición de herramientas. Si los ignoras, da igual qué tan bien clasificada esté tu herramienta.
Experiencia del Agente
Diseña para el LLM, no para el humano. Las descripciones de herramientas, nombres de parámetros y mensajes de error deben estar optimizados para la comprensión del agente.
El patrón de Coerción de Parámetros es un buen ejemplo: un agente puede pasar “2024-01-15”, “January 15” o “yesterday”, tu herramienta acepta todos y normaliza internamente.
Límites de Seguridad
Los prompts expresan intención, el código impone las reglas. Nunca le delegues la seguridad al agente. La autorización y los secretos deben manejarse del lado del servidor.
El patrón de Inyección de Contexto pasa la identidad del usuario, permisos y credenciales a través de un objeto de contexto del lado del servidor, nunca a través del LLM.
Recuperación Guiada por Errores
Los errores deben enseñar, no solo fallar. Cuando algo sale mal, da orientación accionable. ¿Qué debería intentar el agente a continuación? Un 429 en crudo no le dice nada a un LLM. Una respuesta que diga “rate limited, reintenta en 30 segundos o reduce el tamaño del batch a 50” le da un camino a seguir.
Composición de Herramientas
Las herramientas deben componerse bien, como pipes de Unix, no como una cadena de mando. Eso significa formas de respuesta consistentes para que el output de una herramienta sea el input limpio de otra, soporte de batch para que los agentes no iteren uno a uno, y múltiples niveles de abstracción para que el agente elija la granularidad correcta para la tarea.
El Panorama: 54 Patrones, 10 Categorías
Estos cuatro principios, experiencia del agente, límites de seguridad, recuperación guiada por errores y composición de herramientas, atraviesan todo. Se manifiestan de forma distinta según la herramienta, pero las preguntas que plantean son universales: ¿Cómo entenderán esto los agentes? ¿Cómo lo mantenemos seguro? ¿Qué pasa cuando falla? ¿Cómo encajan las herramientas sin dirigirse entre sí?
Organizamos las respuestas en 54 patrones distribuidos en 10 categorías. Cada categoría responde a una de esas preguntas recurrentes:
| Categoría | La Pregunta | Se Cruza Con |
|---|---|---|
| Tipos de Herramienta | ¿Query, Command o Discovery? | N/A |
| Interfaz de Herramienta | ¿Cómo la entenderán y llamarán los agentes? | Experiencia del Agente |
| Descubrimiento de Herramienta | ¿Cómo encuentran los agentes la herramienta correcta? | Experiencia del Agente |
| Composición de Herramienta | ¿Debe agrupar operaciones? | Madurez |
| Ejecución de Herramienta | ¿Síncrona, asíncrona o transaccional? | Patrón de Acceso |
| Respuesta de Herramienta | ¿Cómo deben verse los resultados? | Agente |
| Contexto de Herramienta | ¿Cómo se gestiona la identidad y el estado? | Límites de Seguridad |
| Resiliencia de Herramienta | ¿Cómo se recupera de fallas? | Recuperación Guiada por Errores |
| Seguridad de Herramienta | ¿Cómo se controla el acceso? | Límites de Seguridad |
| Integración | ¿Cómo se conecta a sistemas externos? | Tipo de Integración |
Cada patrón incluye el problema que resuelve, cuándo aplicarlo, consideraciones de implementación y ejemplos de código.
El catálogo completo está en arcade.dev/patterns.
¿Y cómo lo pones en práctica?
Construyendo Tu Primera Herramienta
Por dónde empiezas depende de dos cosas: dónde se ubica tu herramienta en los tres ejes y en qué nivel de madurez estás hoy.
Clasifica Tu Herramienta
Trabaja con cuatro preguntas: ¿Qué tipoes: Query, Command o Discovery? ¿Qué integración: API, Base de Datos, Sistema de Archivos o Sistema? ¿Qué patrón de acceso: síncrono, asíncrono, streaming o basado en eventos? ¿Y qué nivel de madurez: operación única o flujo de trabajo agrupado?
Encuentra Tu Nivel
Tu posición en el eje de madurez te indica con qué patrones empezar. No sobre-ingenierices: empieza atómico, observa cómo los agentes usan tus herramientas y sube de nivel cuando veas las señales en tus trazas.
Las señales observables entre niveles son cosas reales que encontrarás en tus logs: tasas altas de reintentos indican que tu herramienta necesita mejores descripciones y guía de errores. Secuencias repetidas de herramientas indican que es momento de agruparlas. Completaciones parciales en operaciones de varios pasos indican que necesitas límites de transacción y compensación.
Únete a Nosotros
Estos patrones existen gracias a la disciplina de ingeniería detrás de ellos. El equipo de ingeniería de Arcade.dev, en particular Eric, Renato, y Francisco , creó miles de herramientas y construyó los procesos de control de calidad que convirtieron lecciones difíciles en estándares repetibles.
Este trabajo se lo dedicamos a ellos, a la comunidad de ingeniería de herramientas y MCP, y a cada equipo que aprendió por las malas que “funcionar” y “ser usable por un agente” no son lo mismo.
El conjunto completo de patrones está en arcade.dev/patterns. Cada patrón incluye diagramas, ejemplos de código y consideraciones de implementación.
Publicamos estos patrones abiertamente porque mejores herramientas benefician a todos. Cuando el ecosistema construye mejores herramientas, los agentes se vuelven más capaces. Cuando los agentes se vuelven más capaces, más personas construyen con ellos. Ese es el futuro que queremos ayudar a crear.
¿Qué nos faltó? ¿Qué patrones has descubierto que no están aquí? ¿En qué nos equivocamos? Nos encantaría tu feedback: mándanos un mensaje, dinos qué no tiene sentido.
Este es un lenguaje compartido. Ayúdanos a hacer mejores herramientas.
*Explora el catálogo completo de patrones.
Los 54 patrones con ejemplos, trade-offs y guía de implementación:* *arcade.dev/patterns*
*¿Listo para construir?
Arcade te da el runtime, las herramientas y la capa de auth para lanzar agentes que realmente funcionan en producción.* *Empieza*
