Lo que la Conferencia Signal de CrewAI reveló sobre el estado de los agentes

Algunas personas están llamando al 2025 "el año de los agentes", pero creo que es más preciso llamarlo "el año de los frameworks y entornos de ejecución para agentes". Construir un agente es fácil, la parte difícil es implementarlo.

Una vez que tu agente está en producción, de repente estás lidiando con todo lo que esperarías de un software en producción: monitoreo, seguimiento, evaluaciones y experimentos, controles de costos, versionado, además de una nueva categoría de incógnitas específicas del comportamiento autónomo. Afortunadamente, el ecosistema está creciendo rápidamente con plataformas como CrewAI Enterprise, LangSmith (de LangChain), AWS Bedrock y Google's Vertex AI Agent Engine que proporcionan a los equipos una base sólida para ejecutar agentes a escala.

Otra gran conclusión fue observar la rapidez con la que el ecosistema de agentes está creando categorías de productos completamente nuevas que giran en torno a las operaciones de agentes. Las categorías más destacadas se centran en la identidad del agente y la gestión de acciones: autenticación, autorización, delimitación de llamadas a herramientas y auditoría completa de cada acción que realiza un agente. Porque, en definitiva, si planeas implementar agentes para cualquier propósito, esta capa de seguridad y gobernanza no es opcional.

Un tema que surgió en casi todas las charlas: los agentes exitosos dependen de arquitecturas híbridas que combinan código determinista y razonamiento de LLM, ejecutándose lado a lado.

Este enfoque ahora está completamente respaldado en el marco de CrewAI a través de CrewAI Flows, que orquestan funciones deterministas (es decir, código tradicional) y pasos impulsados por LLM en un solo flujo de trabajo. Es un principio simple: si una tarea puede resolverse de manera determinista (como transformar datos estructurados, validar entradas o formatear una carga útil), así debería hacerse. Es consistente, rápido y económico.

El LLM debe manejar las partes ambiguas: interpretar la intención desordenada del usuario, seleccionar la siguiente acción, sintetizar información o generar un plan. Este enfoque hace que los sistemas sean más fáciles de depurar, más fáciles de observar y mucho más resilientes, porque el componente no determinista está aislado en los lugares donde realmente existe ambigüedad.

Incluso a medida que los LLM mejoren, este patrón no desaparecerá. De hecho, creo que aumentará, e incluso se trasladará al lado de la API de los LLM. Cuando un LLM determine que el código es la mejor solución para un problema, escribirá el código, lo ejecutará en un entorno aislado y presentará los resultados finales en su respuesta al usuario.

Another clear pattern from the conference: the leading teams aren’t treating agents as isolated features. They’re treating agents as full collaborators across the entire lifecycle of their domain, from the first conversation with a customer all the way through delivery, QA, and ongoing operations.

For consulting firms, this is a huge opportunity. Agents can sit in on early discovery calls, synthesize interviews, turn those into blueprints, expand those into PRDs and technical specifications, generate scaffolding for the implementation, produce tests, perform QA flows, and assist with UAT and documentation. In other words: everything that involves structured synthesis is now fair game.

Software teams should think about their internal SDLC the same way. Agents can assist with requirements gathering, architecture proposals, code generation, regression testing, and release notes. Software engineers have already been massively accelerated with coding agents like Cursor or Claude Code, the next natural steps are bringing in agents to assist with the fuzzy tasks that occur before and after code generation.

For SaaS companies, the opportunity exists on both sides of the fence:

1. Internal SDLC acceleration: The same lifecycle improvements consultants and engineering teams get.

2. Customer-facing agents: Most SaaS companies know their customers use only a fraction of their product. Agents can change that by acting as a 24/7 customer success engineer for every user with personalized, contextual support that understands the customer’s usage patterns, identifies pain points, helps configure features, and guides customers toward using more of the product they already pay for.

The takeaway across all of this is simple: Agents shouldn’t sit on the edges of your workflow. They should flow through the entire value chain.

Una de las lecciones más esclarecedoras para mí no vino de un ponente, sino de una conversación que tuve con un consultor de IBM que presentó un argumento convincente para explorar el RAG impulsado por grafos, donde se utiliza un grafo de conocimiento en lugar de una base de datos vectorial, junto con la recuperación vectorial estándar.

Su punto no era que los vectores sean incorrectos, sino que los grafos pueden representar estructuras y relaciones de una manera que los embeddings no pueden. Con una configuración RAG híbrida (vector + grafo), obtienes lo mejor de ambos mundos.

Antes de los LLMs, construir y mantener un grafo de conocimiento era lento, costoso y requería muchísimo trabajo manual: leer documentos, extraer entidades, etiquetar relaciones, diseñar una ontología y actualizarla continuamente. Pero con los LLMs, podemos delegar las tareas intensivas de extracción, agrupación y sugerencia de relaciones. La supervisión sigue siendo esencial, pero el trabajo más pesado ha desaparecido en gran medida. El RAG basado en grafos solía ser demasiado costoso para la mayoría de los equipos. Los LLMs han cambiado esa ecuación.

No necesitas adoptar un nuevo enfoque mañana mismo, pero si tu dominio es complejo, relacional o profundamente estructurado, vale la pena mantener el RAG híbrido en tu radar.

Otro tema de la conferencia: una vez que los agentes comienzan a realizar acciones reales, todo el modelo de seguridad cambia. Los sistemas tradicionales se preocupan por los usuarios y servicios, pero los agentes no son puramente uno u otro. Se sitúan en una nueva categoría que no encaja perfectamente en los modelos existentes.

Y esto no es una preocupación futura. Los equipos que construyen agentes de producción hoy ya han enfrentado estos problemas y han tenido que resolverlos por sí mismos o recurrir a los proveedores emergentes en este espacio.

Este nuevo paradigma de seguridad significa que necesitamos nuevas respuestas a preguntas fundamentales:

Identidad: ¿El agente opera con la identidad del usuario? ¿Su propia identidad? ¿Un token delegado? ¿Qué permisos hereda? ¿Cuáles no debería heredar?

Permisos: ¿Qué permisos tiene el agente? ¿Qué no puede hacer? Los agentes nunca deberían tener acceso general—necesitan permisos limitados y revocables.

Control de herramientas: ¿Qué herramientas puede llamar el agente? ¿Qué entradas puede pasar y bajo qué circunstancias? ¿Cuándo se requiere la aprobación humana? La mayor parte del riesgo en los agentes proviene de las acciones, no de la generación de texto.

Auditoría: Tan pronto como los agentes pueden modificar datos o activar flujos de trabajo, necesitas un registro detallado de qué hizo el agente, cuándo, por qué, qué herramienta llamó, con qué parámetros, y en nombre de quién.

Lo fascinante es la rapidez con la que se ha formado un ecosistema alrededor de esto. Ahora hay empresas enteras especializadas en autenticación de agentes, autorización delegada, gobernanza de herramientas y registros de auditoría completos a nivel de acción. Estos proveedores existen porque los primeros adoptantes los necesitaban, y todos los equipos de producción que les sigan también los necesitarán. Esta es la nueva capa de producción.

Al alejarme de las sesiones, conversaciones de pasillo y demostraciones en Signal, el patrón era difícil de ignorar: las mayores ganancias no provienen de modelos más grandes, sino de mejores sistemas. La verdadera oportunidad está en la capa de aplicación: arquitecturas híbridas, canales mejorados de recuperación de contexto, flujos de trabajo impulsados por agentes, y marcos adecuados de identidad y autorización.

Y debido a que la mayoría de las organizaciones aún no han implementado un solo agente, toda esta capa sigue completamente abierta. Los equipos que comiencen a construir sistemas de agentes confiables y de nivel de producción ahora tendrán una enorme ventaja, no porque estén utilizando un modelo secreto, sino porque han invertido en patrones de ingeniería, protecciones operativas y flujos de trabajo de dominio que permiten a los agentes realizar trabajo real.

Esta es la parte que me emociona. Estamos en los inicios de la era de los agentes, pero los cimientos son lo suficientemente estables para que cualquier persona con experiencia en software comience a construir aplicaciones agénticas significativas y de alto impacto. Las herramientas están madurando. Los marcos de trabajo ya están aquí. Y las empresas que están tomando la delantera son aquellas que tratan a los agentes no como prototipos o características secundarias, sino como participantes en todo su ciclo de creación de valor.

La capa de aplicación es donde los equipos se diferenciarán, y es donde se construirá la próxima generación de experiencias de software.