Fundador de IA construyendo un negocio autónomo comparte cómo crear flujos de trabajo agénticos para la entrega de proyectos y soporte al cliente
Amos Bar Joseph es un emprendedor en serie que aprendió de sus errores anteriores con la gestión de proyectos tradicional, estrategias de salida al mercado y modelos de negocio. Como resultado, su último negocio, Swan AI, se está volviendo completamente autónomo. Y eso significa que la inteligencia artificial gestionará sus proyectos —y prácticamente todo lo demás—.
Amos Bar Joseph
CEO de Swanai
De la planificación a la velocidad de decisión: La gestión de proyectos tradicional se centra fuertemente en la planificación, documentación y coordinación. Amos demuestra que en una empresa con enfoque en IA, la ejecución se vuelve barata y rápida, por lo que el verdadero cuello de botella es la velocidad con la que reconoces patrones y tomas decisiones.
Flujos de trabajo autónomos: Swan AI eliminó las reuniones de estado, los extensos planes de proyecto, las cadenas de aprobación y revisiones trimestrales — reemplazándolos por actualizaciones asíncronas, definiciones de resultados, derechos de decisión claros y señales automatizadas de retroalimentación. Este cambio redujo el tiempo de coordinación del 60% al 10%, permitiendo que el equipo dedique la mayor parte de su tiempo a trabajar realmente, no a hablar sobre el trabajo.
Los roles humanos deben definirse: Los roles humanos deben definirse antes de automatizar con IA, porque las implementaciones fallan no por limitaciones de la IA, sino porque los equipos nunca aclaran qué tareas deben ser responsabilidad de los humanos; Amos explica que la IA debe encargarse completamente de tareas de bajo impacto y baja complejidad, asistir en áreas donde la complejidad o el riesgo son mayores, y dejar las decisiones de alto impacto y alta complejidad a los humanos.
Nos sentamos con Amos para entender qué significa esto en la práctica. Esto es lo que nos contó.
Cómo un modelo de negocio autónomo transforma la entrega de proyectos
Soy el cofundador y CEO de Swan AI, una plataforma de automatización GTM que se integra con canales de comunicación (correo electrónico, Slack, etc.), CRM y fuentes de datos B2B para gestionar flujos de trabajo GTM. La usamos internamente para la entrega de proyectos y gestión de clientes.
Estamos construyendo el primer negocio autónomo con la misión de alcanzar $10M ARR por empleado con un equipo pequeño y un ejército de agentes de IA. Nuestro negocio autónomo está diseñado para la colaboración entre humanos e IA, no para la coordinación de humano a humano, y puede escalar con inteligencia — no con incremento de personal.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Esta restricción se convirtió en un laboratorio accidental para la entrega de proyectos. Cuando no puedes resolver los problemas contratando más gente, cada decisión de proyecto se vuelve existencial: ¿Multiplicará esto por diez nuestro resultado, o es solo actividad que da la sensación de progreso?
Ese filtro brutal reveló patrones que no pude ver cuando tenía el lujo de asignar personas a problemas en mis dos startups anteriores, que fundé y escalé siguiendo el antiguo manual de crecimiento a cualquier costo. Ahora, después de observar a más de 200 empresas implementar IA con el producto de Swan, puedo identificar los patrones de fracaso al instante.
Por qué la IA está cambiando la entrega de proyectos de la planificación al reconocimiento de patrones y la velocidad de decisión
El cambio más drástico es cómo distribuyo mi tiempo — y está casi invertido respecto a la gestión de proyectos tradicional. Dedico muy poco tiempo a tareas que antes ocupaban mi atención, como la planificación inicial, reuniones de seguimiento y documentación que nadie lee. Más sobre esto en un momento.
Esto es lo que capta mi atención ahora:
- 60% al reconocimiento de patrones y la toma de decisiones: Analizo en tiempo real qué funciona en nuestras más de 200 implementaciones. No son revisiones mensuales — es detectar patrones a diario. ¿Qué implementaciones están generando resultados compuestos frente a cuáles se estancan? ¿Dónde aparecen realmente los cuellos de botella vs. donde creíamos que lo harían? Ahora el juego consiste en decidir rápidamente qué eliminar y en qué redoblar esfuerzos; y eso no se puede hacer en una revisión trimestral. Para esto, tenemos un panel de Retool para la salud del cliente y alertas en Slack. También uso Metabase, donde disponemos de analíticas de producto por cliente.
- 30% en el diseño de ciclos de retroalimentación: ¿Cómo sabemos en 48 horas si una implementación de IA está funcionando? ¿Qué señales nos indican si debemos cambiar de rumbo o persistir? Estoy creando "sistemas de detección de fallos": formas de detectar cuando la IA se sale de lo previsto o un flujo de trabajo no da resultados antes de que sea una crisis. Para lograr esto, es importante establecer un plan claro que empiece con pasos pequeños y fáciles de medir. Los PM tradicionales planificaban para el éxito; yo diseño sistemas que muestran los fracasos de inmediato para poder solucionarlos mientras son pequeños.
- 10% es el verdadero “lanzamiento del proyecto”: Antes, esto era la culminación de meses de planificación. Ahora es simplemente martes. Constantemente lanzamos versiones v1 y tratamos el lanzamiento como el comienzo de un aprendizaje, no el final de la planificación. Lanzar ya no es un éxito mediante sí mismo, es solo el permiso para comenzar a obtener retroalimentación real.
En un mundo donde la IA es lo primero, la ejecución es barata y rápida. El cuello de botella es la velocidad de decisión. Mi rol pasó de “hacer el plan perfecto” a “tomar decisiones rápidas basadas en retroalimentación real”. Por eso dedico el 90% de mi tiempo a sistemas de aprendizaje, no a sistemas de ejecución.
En un mundo donde la IA es lo primero, la ejecución es barata y rápida. El cuello de botella es la velocidad de decisión.
Cómo eliminar el impuesto de coordinación en la entrega de proyectos
Nuestro cambio de la gestión de proyectos tradicional a una liviana no fue un cambio de metodología, sino eliminar rituales específicos que nos ralentizaban. Esto es lo que desapareció y lo que lo reemplazó:
Reuniones de estado (40% del calendario) → Actualizaciones asíncronas (ahora 5% del tiempo)
- Eliminado: Reuniones semanales de estado del proyecto con presentaciones en diapositivas
- Reemplazado por: Breves actualizaciones por Slack cuando cambia algo, no en un horario fijo
- Por qué funciona: La información fluye cuando importa, no cuando lo dice el calendario
- Resultado: Recuperadas más de 15 horas/semana por fundador
Planes de proyecto detallados (2-4 semanas al inicio) → Definición de resultados (2-4 horas)
- Eliminado: Documentación exhaustiva de requisitos, mapas de flujo de trabajo, matrices de riesgos
- Reemplazado por: Resultado claro que queremos y primer experimento a realizar
- Por qué funciona: Los planes se vuelven obsoletos de inmediato; los resultados siguen siendo relevantes
- Resultado: Se entregan las primeras versiones en días, no en meses
Cadenas de aprobación → Derechos de decisión claros
- Eliminado: "Consulta esto con la dirección" para decisiones pequeñas
- Reemplazado por: Umbrales definidos — por debajo de $X o impacto Y, simplemente hazlo
- Por qué funciona: La velocidad importa más que prevenir errores menores
- Resultado: El tiempo de decisión a acción se redujo de días a horas
Revisiones trimestrales → Señales de retroalimentación diaria
- Eliminado: Reuniones programadas de "veamos cómo va este proyecto"
- Reemplazado por: Métricas automatizadas que nos alertan cuando algo va mal
- Por qué funciona: Se detectan problemas al día 2, no en el mes 3
- Resultado: Se resuelven los problemas antes de que se conviertan en crisis
Pasamos de dedicar el 60% del tiempo a coordinar el trabajo a dedicar el 90% del tiempo a hacer trabajo. No porque seamos más disciplinados, sino porque eliminamos el coste de coordinación que crea la gestión de proyectos tradicional.
Cómo la IA cambia los rituales de entrega al requerir un contexto más rico
El pensamiento tradicional asume que la IA significa menos comunicación humana. Nuestra realidad es todo lo contrario: incorporar IA en el equipo significa que nos comunicamos más explícitamente, porque la IA necesita contexto para ser útil.
Esto es especialmente relevante para nosotros porque estamos usando nuestro propio producto para eliminar el "impuesto de contexto"—es decir, que se integra en nuestros canales de comunicación para recopilar y recuperar contexto. Escucha.
Esto tiene un gran impacto en nuestros rituales. Los proyectos de éxito del cliente son un buen ejemplo. Cuando un cliente reporta un problema o solicita algo, nuestros fundadores se comunican intencionalmente con más profundidad de la necesaria entre ellos, porque sabemos que la IA lo recopila.
Así es como se ve esto en la práctica:
En lugar de: "El cliente X quiere la función Y, lo hablamos mañana"
Escribimos: "El cliente X solicitó la función Y. Contexto: están encontrando problemas de escalabilidad con 200 leads/día, su equipo de 3 SDR está sobrepasado, y esta función les permitiría manejar 500/día sin contratar. Esto se alinea con nuestro ICP de escalamiento SMB. Urgencia: alta—esta semana están evaluando competidores."
Después, cuando cualquier persona del equipo — incluida la IA — interactúa con ese cliente, tenemos acceso al contexto relevante.
Sí, esto toma 2-3 minutos extra por comunicación. Pero ahorra horas en:
- Reuniones de alineación — la IA mantiene a todos sincronizados
- Recopilación de contexto — la IA ya conoce la situación
- Transferencias — la IA mantiene el contexto en todas las interacciones
Cuando tratas a la IA como a un miembro del equipo que debe estar al tanto de todo, tus rituales de comunicación y documentación cambian fundamentalmente — y es allí cuando la IA se vuelve realmente útil, no solo una función.
Por qué definir los roles humanos primero es esencial para una implementación exitosa de IA
Los fracasos en la implementación de IA casi nunca ocurren porque la IA no sea lo suficientemente capaz. Fallan porque los equipos nunca respondieron una pregunta más fundamental: "¿De qué deberían encargarse realmente los humanos en este flujo de trabajo?"
Este es el patrón que veo constantemente en nuestras más de 200 implementaciones:
Los equipos pasan semanas preguntándose "¿Puede la IA manejar esta tarea?" Mapean el proceso actual, identifican lo que la IA puede automatizar, construyen el sistema y lo lanzan. La IA funciona. Puede hacer el 70-80% de la tarea de forma confiable.
Luego todo se desmorona. No porque la IA falle, sino porque nadie definió qué deberían hacer los humanos con el 20-30% restante. Así que suceden una de dos cosas:
- Los humanos micromanagementean todo. No confían en la IA y revisan cada decisión, convirtiendo un proyecto de IA de $20K en una herramienta cara de sugerencias. El equipo se quema revisando el trabajo de la IA.
- Los humanos abandonan completamente la responsabilidad. Asumen que “la IA lo está gestionando” y dejan de prestar atención. Luego algo falla o se sale del guion, y nadie se da cuenta hasta que es una crisis con el cliente.
Esto se debe a que abordamos la implementación de la IA al revés. Preguntamos "¿Qué podemos automatizar?" en lugar de "¿Dónde es irremplazable el juicio humano y cómo construimos IA que amplifique ese juicio?"
En su lugar, comienza cada proyecto de IA definiendo primero el papel humano. ¿Qué decisiones requieren intuición? ¿Dónde es fundamental el contexto? ¿Qué modos de fallo necesitan supervisión humana? Luego, construye la IA para que se encargue del resto y muestre las señales correctas en el momento adecuado para la toma de decisiones humanas.
Parece obvio en retrospectiva. Pero cuando te entusiasman las capacidades de la IA, es increíblemente fácil saltarse este paso y centrarse únicamente en lo que la IA puede hacer, en lugar de diseñar la colaboración entre humano e IA desde el principio.
Un marco práctico para decidir qué debe automatizar la IA
Pienso en las decisiones de automatización en dos dimensiones: el impacto del error y la complejidad del juicio requerido. Esto genera cuatro categorías claras, que cubriré en un momento.
A medida que aumenta la complejidad o el impacto, el papel de la IA cambia de "dueño" a "asistente". Pero debes definir qué papel juega la IA en cada flujo de trabajo desde el inicio — no después del lanzamiento, cuando los humanos no saben si deben confiar o anular las decisiones de la IA.
El marco no trata sobre lo que la IA puede hacer técnicamente. Se trata de lo que la IA debe asumir según el perfil de riesgo y el juicio necesario.
Bajo impacto + baja complejidad = automatización total
Ejemplo 1: Enriquecimiento de datos e investigación
- La IA recopila información de la empresa, stack tecnológico, perfiles sociales
- Si comete un error, los humanos lo detectan durante la revisión
- No se requiere juicio — solo recopilación de datos
- Implementación: Integraciones API, IA estructura la salida, ligera comprobación humana
Ejemplo 2: Puntuación y asignación inicial de clientes potenciales
- La IA puntúa según criterios ICP definidos, asigna al flujo de trabajo apropiado
- Los envíos erróneos son obvios y fácilmente corregidos
- La lógica es codificable (tamaño de empresa, industria, señales de comportamiento)
- Implementación: Reglas + puntuación IA, el humano revisa casos límite
Bajo impacto + alta complejidad = IA prepara, humano decide
Ejemplo: Respuestas de atención al cliente
- La IA redacta respuestas basadas en casos previos similares
- Complejo porque el tono, el contexto y los casos límite importan
- Pero de bajo impacto si revisamos antes de enviar
- Implementación: IA redacta, humano revisa/edita, aprendemos de las ediciones
Alto impacto + baja complejidad = automatizado con salvaguardas
Ejemplo: Envío de mensajes salientes
- Alto impacto porque puede dañar tu marca/mercado si se hace mal
- Pero relativamente baja complejidad — y la calidad puede medirse
- Implementación: IA genera, flujos estrictos de aprobación, interruptores automáticos si baja el rendimiento
Alto impacto + alta complejidad = propiedad humana
Ejemplo: Cambios estratégicos en proyectos
- Decidir cancelar o redoblar la apuesta en una implementación
- Requiere reconocimiento de patrones en múltiples contextos
- Una decisión incorrecta es costosa por los recursos desperdiciados o la oportunidad perdida
- Implementación: IA muestra señales (caídas en el uso, patrones de feedback), el humano toma la decisión
Ejemplo: Negociaciones complejas con clientes
- Negociaciones sobre precios, conversaciones de expansión, riesgos en renovaciones
- Requiere leer la dinámica de las relaciones, el contexto político y preocupaciones no expresadas
- Un error daña la confianza y es difícil de recuperar
- Implementación: IA investiga y prepara, el humano dirige la conversación
Cómo los flujos de trabajo agentivos permitieron un sistema de soporte autoaprendizaje en 13 horas
Aquí tienes un ejemplo de la complejidad que hemos gestionado usando flujos de trabajo agentivos en la búsqueda de construir un negocio automatizado.
La restricción: Apuntar a $10M ARR por empleado con solo 3 fundadores significaba que no podíamos contratar personas para resolver los problemas. Cuando los tickets de soporte llegaron a más de 200 por semana, la respuesta tradicional — contratar 2 CSM — no era posible para nosotros. Cada ticket requería la atención total de un fundador: investigar la respuesta, redactar la contestación, documentarla en algún lado. Nos estábamos ahogando.
V1 (semana 1): Responder preguntas conocidas
Comenzamos con lo mínimo: un agente de IA en Slack que podía responder a unas 20 preguntas que ya habíamos documentado en Notion.
- Herramientas: Swan AI, Slack, Notion
- Configuración: 6 horas
- Resultado: 15% de los tickets gestionados
- Nuevo problema: Los clientes se frustraban recibiendo respuestas de "No lo sé". Seguíamos respondiendo manualmente el 85% de los casos.
V2 (semana 2): Escalar preguntas desconocidas
Agregamos una vía de escalamiento: la IA se mantiene en el hilo del cliente, pero nos alerta internamente cuando no sabe algo. Nosotros respondemos y la IA entrega nuestra respuesta.
- Configuración: 3 horas
- Resultado: 35% de resolución autónoma
- Nuevo problema: Notamos que estábamos respondiendo las mismas preguntas nuevas una y otra vez. Cada escalamiento no enseñaba nada a la IA — solo era un sistema de rutas.
V3 (semana 4): Aprender de los escalamientos
Construimos el ciclo de aprendizaje. Ahora, cuando respondemos una pregunta escalada, la IA captura automáticamente la pregunta y la respuesta, las estructura y las agrega a la base de conocimiento.
- Configuración: 4 horas
- Resultado: 70% de resolución autónoma en 2 semanas
Por qué esto funcionó: Cada versión tomó menos de 6 horas para construir porque no planeábamos la perfección — respondíamos a problemas concretos. La capacidad de "autoaprendizaje" no estaba en el plan original. Surgió naturalmente cuando preguntamos: "¿Por qué estamos respondiendo dos veces las mismas preguntas?"
Ahora, respondemos más de 200 tickets por semana, el 70% es de manera autónoma y nuestra base de conocimiento crece orgánicamente gracias a preguntas reales de los clientes.
Así que este es mi consejo: Lanza lo mínimo que resuelve el dolor inmediato. Observa dónde se rompe. Agrega la función mínima para solucionar ese quiebre. Repite. Llegamos a un sistema sofisticado de autoaprendizaje sin haberlo planeado de antemano.
Lanza lo mínimo que resuelve el dolor inmediato. Observa dónde se rompe. Agrega la función mínima para solucionar ese quiebre. Repite.
Otros ámbitos ideales para flujos de trabajo de agentes
También estamos utilizando flujos de trabajo con agentes en:
- Onboarding: Nuevo cliente → Swan guía la configuración de manera conversacional, hace preguntas sobre el perfil ideal de cliente (ICP), configura flujos de trabajo según las respuestas
- Éxito: Monitorea patrones de uso → señala oportunidades de expansión o riesgos → informa a los fundadores con recomendaciones
Por qué los ciclos de retroalimentación son más importantes que tu elección de herramienta de IA, y cómo construirlos
Todos preguntan: "¿Qué herramienta de IA debemos usar?" Es la pregunta equivocada.
Lo más valioso que nos ahorra tiempo no es una herramienta — es que sabemos en menos de 48 horas si algo falla.
Incorporamos ciclos de retroalimentación en cada implementación. Monitoreamos:
- Patrones de escalamiento: Cuando la IA transfiere a humanos, indica que necesita ayuda
- Tasas de sobrescritura: Cuando los humanos cambian las respuestas de la IA, indica que el juicio fue débil.
- Métricas de resultados: Reuniones agendadas, tickets resueltos, etc. — no solo actividad.
- Detonantes de fallo: Alertas automáticas cuando el rendimiento cae.
Sin ciclos de retroalimentación, lanzas IA y esperas que funcione. Cuando te das cuenta de que no lo hace — usualmente por quejas o revisiones trimestrales — ya habrás desperdiciado meses.
Con ciclos de retroalimentación, detectas problemas en días y los solucionas antes de que crezcan.
Hemos visto un impacto real:
- IA de soporte: de 35% → 70% autónomo en 2 semanas, viendo qué preguntas necesitaban mejores respuestas
- IA de calificación: 40% de mejora en precisión en 30 días monitoreando sobrescrituras humanas
La elección de tu herramienta de IA importa mucho menos que tu capacidad de detectar lo que no funciona y iterar rápidamente. El "instrumento" que más tiempo ahorra es el sistema que te dice qué debes arreglar antes de que sea una crisis.
Una pila tecnológica nativa de IA para la entrega autónoma de proyectos
Dicho esto, sí tengo algunos básicos:
- Proyectos Claude (Herramienta de productividad con IA): Creo y itero todos los documentos relacionados con proyectos en un Proyecto de Claude. De esta manera, el contexto de la IA se acumula y se vuelve más inteligente con cada conversación.
- Shortwave (Herramientas de comunicación con IA): Es un nuevo cliente de correo electrónico nativo de IA con un agente de IA integrado que me ayuda a recuperar fácilmente el contexto adecuado entre todo el desorden de mi bandeja de entrada. También me ayuda a escribir correos de calidad y mantener informados a los interesados sin cambiar de contexto ni perder tiempo buscando hilos anteriores.
- N8N (Software de automatización de flujos de trabajo con IA): Lo uso para crear agentes de IA conectados con nuestro Retool y Metabase, así podemos recibir actualizaciones de proyectos directamente en Slack.
Por qué la gestión de proyectos está evolucionando hacia la gestión de la velocidad
La IA en la gestión de proyectos evolucionará de la entrega de proyectos discretos a una gestión de la velocidad basada en la adaptación continua.
Creo que la IA hará que construir y cambiar cosas sea tan rápido que los proyectos con principios y finales definidos se volverán obsoletos. Para cuando termina un proyecto de 3 meses, los requisitos ya han cambiado, las capacidades de la IA han evolucionado y la "solución completa" ya está desactualizada.
Lo que lo reemplazará serán ciclos de mejora continua con bucles de retroalimentación rápidos. En vez de “lanzar el portal del cliente en el tercer trimestre”, pasa a ser “evolucionar continuamente las interacciones con el cliente, lanzar cambios cada día basados en retroalimentación real”.
Los "gestores de velocidad" se optimizarán para:
- Velocidad de respuesta ante comentarios — no fechas de entrega
- Frecuencia de iteración — no finalización de proyectos
- Velocidad de aprendizaje — no gestión del alcance
El éxito se definirá por la rapidez con la que detectes problemas y soluciones, no por cumplir hitos predefinidos.
Los PMs que sobreviven ya están desarrollando este músculo: lanzan versiones v1 imperfectas, iteran según el uso real y optimizan la velocidad sobre la perfección. Aquellos que siguen perfeccionando sus diagramas de Gantt no reconocerán el trabajo en cinco años.
Por qué la velocidad de iteración supera a la planificación y cómo los líderes pueden lanzar más rápido con IA
Aquí va mi consejo: Prioriza la velocidad de iteración, no la perfección en la implementación.
Detente: planificación de varias semanas, lanzamientos perfectos, evitar todos los errores.
Empieza: Lanza versiones mínimamente útiles en días, construye primero los bucles de retroalimentación, aprende de iteraciones rápidas.
Y hazlo práctico: reduce en un 75% la fase de planificación de tu próximo proyecto. Lanza esta misma semana algo imperfecto que te enseñe lo que realmente importa. Mide el éxito por la velocidad con la que pasas de "eso falló" a "aquí tienes la v2".
La velocidad de aprendizaje supera a la profundidad de la planificación siempre.
La velocidad de aprendizaje supera a la profundidad de la planificación siempre.
Sigue leyendo
Puedes seguir el trabajo de Amos automatizando flujos de trabajo GTM en LinkedIn y el boletín de Swan. También puedes conocer Swan y Autonamos, el clon digital de Amos.
¡Pronto más entrevistas con expertos en The Digital Project Manager!
