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 de campo 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 en el Campo
① El Problema de los Alcances Demasiado Pequeños
Intenté crear un agente para ventas que "investigara automáticamente cuando llegara un prospecto". 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 donde investiga la información cuando un nuevo registro llega a la base de datos de prospectos. 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 pasar la propiedad al equipo de campo, no habían automatizado los borradores de correos incluso después de varias semanas. Cuando los entrevisté, dijeron: "¡Ya es muy conveniente solo con que investigue los prospectos!" El equipo no se dio cuenta de que podían llegar hasta los borradores de correos, 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 de negocio 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 llegar a un 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 disminuye gradualmente. El promotor también se queda sin energía. Idealmente, el equipo de campo debería adoptar 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 agencia (quién lo posee) se diluye gradualmente.
Estos tres no son problemas independientes; todos están 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 en el campo, hay cuatro muros 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 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, sin embargo, muchas herramientas son débiles en esto. 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 baja temporalmente? ¿Qué pasa si se detiene por 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, sin embargo, 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 de negocio 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.
