Al promover la introducción de agentes de IA en otros departamentos de Notion como parte de mi trabajo y brindar soporte de implementación a empresas que utilizan el enfoque FDE, han surgido ciertos patrones. He creado agentes para ventas, ventas internas, marketing, desarrollo de productos, éxito del cliente y más, pero todos enfrentan barreras comunes a nivel operativo y barreras organizacionales a nivel empresarial. Ambas son inevitables, y creo que la mayoría de las empresas se quedan estancadas en los mismos puntos.
▍Barreras Operativas
① El Problema de los Alcances Demasiado Pequeños
Intenté crear un agente para ventas que "investigara automáticamente cuando llegara un lead". Imaginé el flujo de trabajo completo: cuando un prospecto entra en la lista, el agente investiga y analiza información interna y externa, y luego crea un borrador de correo electrónico. Empecé construyendo la parte en la que investiga información cuando una nueva entrada llega a la base de datos de leads. Mi intención era que, una vez que la base estuviera lista, automatizar la creación de correos sería fácil.
Sin embargo, después de configurar la construcción inicial y entregar la propiedad al equipo operativo, no habían automatizado los borradores de correo ni siquiera después de varias semanas. Cuando los entrevisté, dijeron: "¡Ya es muy conveniente solo con que investigue los leads!" El equipo no se dio cuenta de que podían llegar hasta los borradores de correo, o la idea de automatizar tanto ni siquiera se les había ocurrido. También parecía que dudaban porque les parecía difícil.
Este es el primer patrón donde la implementación del agente se estanca: hacer que el alcance del trabajo sea demasiado pequeño, lo que resulta en un uso de bajo rendimiento a pesar de haber construido el agente. Termina usándose solo para funciones aisladas o tareas menores.
② El Problema de Detenerse por Ser Demasiado Grande
El segundo problema es el opuesto: intentar convertir un proceso empresarial complejo en un agente solo para darse cuenta de que el proceso en sí no está estructurado con alta resolución. Diferentes personas hacen las cosas de manera diferente, o hay demasiado conocimiento tácito. Intentar ser demasiado minucioso hace que el tiempo se derrita solo durante las entrevistas, sin llegar nunca a la fase de construcción. El número de partes interesadas aumenta y el costo de generar consenso se dispara. El entusiasmo inicial se desvanece gradualmente...
Este es un problema de definición de alcance en la gestión de proyectos. ¿Qué quieres hacer con el agente? ¿Qué resultado quieres lograr? Si el resultado está decidido, el alcance necesario y suficiente para el agente está determinado. Apuntar vagamente a "eficiencia empresarial con agentes" lleva al barro.
③ Ausencia de Propiedad
Incluso si un promotor lo construye con impulso, si la responsabilidad de las mejoras o correcciones de errores es ambigua, el uso se desvanece gradualmente. El promotor también se queda sin energía. Idealmente, el equipo operativo debería cuidar el agente como propio. Si esto falta, las cosas se ven bien durante los primeros tres meses, pero no logran escalar. A medida que aumenta el número de partes interesadas, especialmente cuando el alcance del trabajo crece, la necesidad de consenso y confirmación aumenta, y el sentido de propiedad (quién lo posee) se diluye gradualmente.
Estos tres no son problemas independientes; están todos conectados. Si el diseño del alcance es incorrecto, la propiedad no se establecerá, y si no hay propietario, el alcance no se expandirá.
▍Barreras Organizacionales
Incluso si superas las barreras operativas, hay cuatro muros más más allá de simplemente "hacer algo que funcione" en una empresa.
④ Transparencia del Capital de Tokens
Incluso si el consumo de tokens es visible por departamento, a menudo no está claro "qué tipo de trabajo se realizó y qué resultado se obtuvo". Esto se convierte en un problema desde la perspectiva del capital de tokens y la gestión de tokens, lo que hace imposible justificar el presupuesto. En consecuencia, la gerencia ve los tokens solo como un costo de consumo, preguntando: "Entonces, ¿cuánto va a costar?"
⑤ Gobernanza
¿Quién puede crear agentes, quién puede verlos y quién los gestiona? Si esto es ambiguo, la organización se inundará de "agentes callejeros" o "agentes zombis" que se ejecutan pero nadie usa. Nadie asume la responsabilidad, no se asegura el presupuesto, los tokens se consumen de manera derrochadora y los riesgos de seguridad aumentan hasta que todo se detiene.
⑥ Observabilidad
¿Cuántas veces se ejecutó el agente, con qué frecuencia tuvo éxito y dónde falló? Este es un requisito mínimo para la operación, pero muchas herramientas son débiles en este aspecto. No puedes mejorar lo que no puedes ver. Solo con observabilidad puedes construir un ciclo de retroalimentación para la mejora del agente.
⑦ Flexibilidad en la Selección del Modelo
Depender demasiado de un proveedor específico de LLM es un riesgo. ¿Qué pasa si el rendimiento cae temporalmente? ¿Qué pasa si se detiene debido a una falla? ¿Qué pasa si las restricciones de exportación lo hacen no disponible? Si no puedes cambiar a otro proveedor de inmediato, no puedes implementar agentes directamente vinculados a las operaciones comerciales. La IA se ha convertido en infraestructura, pero la dependencia extrema se tolera ciegamente en la actualidad.
Resumen
La implementación de agentes parece una discusión técnica, pero en realidad se trata de diseño empresarial y propiedad. Para asegurarse de que no termine solo con "la IA es increíble", primero se necesitan bases para la gobernanza y la observabilidad.
Ni demasiado pequeño, ni demasiado grande, y nutrido por alguien con responsabilidad. Y un sistema para apoyar eso como organización. Creo que los agentes solo se arraigan cuando tanto el campo como la organización están alineados.
