Los equipos que trabajan con inteligencia artificial suelen empezar por la capa equivocada, según Ambarish Majumdar, de Meta. En vez de construir un agente completo desde el inicio, propone partir de las habilidades individuales que ese sistema necesitará para operar.
Una habilidad, explica, hace bien una sola tarea: recuperar información, resumir un documento, clasificar una solicitud o validar una salida. Un agente, en cambio, decide qué capacidades usar, en qué orden y qué hacer con los resultados. La diferencia importa porque permite combinar piezas bien diseñadas para producir comportamiento agente sin levantar un sistema grande y complicado.
Majumdar recuerda una distinción similar en Anthropic entre flujos de trabajo y agentes. En los primeros, modelos y herramientas siguen rutas predefinidas. En los segundos, el modelo determina dinámicamente cómo resolver la tarea. Esa separación, dice, ayuda a pensar primero en capacidades concretas y después en la orquestación.
El argumento central es práctico: construir habilidades enfocadas, probarlas por separado y luego conectarlas. Pone como ejemplo la atención al cliente. Una habilidad puede identificar el problema del cliente, otra recuperar información de la cuenta, una tercera proponer una resolución y una cuarta validar la propuesta frente a la política de la empresa. Ninguna necesita ser un agente por sí sola.
La evaluación también mejora cuando el sistema se divide. La recuperación puede medirse por si encuentra la información correcta; la clasificación, contra ejemplos conocidos; la validación, por si detecta errores específicos. Cuando todo queda dentro de un gran prompt, identificar qué falló se vuelve mucho más difícil.
Majumdar también insiste en que el contexto es un recurso finito. Aunque los modelos actuales admiten ventanas de contexto más grandes, eso no significa que cada habilidad deba recibirlo todo. Pasar historial, documentos e instrucciones innecesarias consume tokens, puede aumentar la latencia y obliga al modelo a procesar más información de la cuenta.
Por eso propone tratar el contexto como parte de la interfaz de una habilidad. No basta con definir entradas y salidas; también hay que definir qué contexto necesita. El orquestador puede conservar el estado amplio del flujo y pasar solo la información relevante a cada paso, ya sea en forma estructurada o con resúmenes breves.
Otro punto clave es separar instrucciones, estado y conocimiento. Las instrucciones dicen qué debe hacer la habilidad; el estado recoge lo que ya ocurrió en el flujo; el conocimiento aporta la información externa necesaria para completar la tarea. Mantener esas fronteras claras facilita el mantenimiento y el diagnóstico.
La conclusión es sencilla: no empezar preguntando cómo construir un agente para todo el proceso, sino qué capacidades requiere realmente ese proceso. Primero las habilidades. Después la orquestación. Y solo al final, si hace falta, más autonomía. En un mercado donde la complejidad tecnológica puede inflar costos y ralentizar la implementación, ese orden tiene una lógica de productividad muy difícil de discutir.