El recorrido de la ruta 5: desde el agente que se ejecuta en tu máquina, pasando por agentes que viven en la nube, hasta un producto completo que otras personas usan y pagan.
Mapa de la ruta
Contenido detallado
📧 Proyecto: agente de soporte por correo electrónico con RAG
Un agente que lee las políticas de la empresa (PDF) para crear una base de conocimiento, clasifica cada correo electrónico recibido y redacta una respuesta respaldada por los documentos, y se niega a inventar cuando el tema está fuera de alcance. Construyes dos workflows (indexador + agente), conectas las credenciales, pruebas casos reales y aplicas los 6 enhancements.
Un agente que transforma documentos de políticas (devoluciones, garantía, plazos) en una base de conocimiento y la usa para responder correos electrónicos de soporte con fundamento.
Es el «hola, mundo» de los agentes útiles: combina RAG, clasificación y generación de texto en un caso de negocio real.
Alcance claro; borrador (sin envío automático); una persona debe aprobarlo.
Separar quién "aprende" (el indexador, que lee PDFs y llena el vector store) de quién "responde" (el agente, que se activa cuando llega un nuevo correo electrónico).
Separar la indexación de la consulta permite probar cada parte fácilmente y ejecutarla a bajo costo.
Indexador (manual) vs. agente (trigger); vector store compartido; embeddings.
Un único prompt en Plan Mode que describe el resultado completo (trigger, base de conocimientos, clasificación, borrador, fallback) y deja que la IA proponga el plan.
Un buen prompt inicial ahorra horas: la IA pregunta qué falta antes de construir.
Plan Mode primero; describir el resultado; responder las preguntas aclaratorias.
La IA arma el indexador (document loader → text splitter → embeddings → vector store) y el agente (Gmail trigger → classifier → retrieval → borrador).
Ver cómo se crean los nodos enseña la anatomía de un pipeline RAG real.
Ejecutar el indexador una vez; el agente lee del vector store; probar paso a paso.
Conectar la cuenta de correo electrónico (OAuth) y la clave de la IA — algo que TÚ haces manualmente, porque la IA no tiene acceso a tus secretos (ni debería tenerlo).
Es la frontera clara entre el trabajo de la IA y el tuyo; el secreto nunca va al chat.
OAuth = autorizar sin dar la contraseña; clave de API; la credencial queda en la herramienta.
Envía correos de prueba para cada escenario: uno sobre devolución, uno sobre garantía y uno fuera de alcance (que el agente debe rechazar, no inventar).
Verde ≠ correcto: solo la prueba con casos reales revela si el RAG está fundamentando las respuestas.
Casos límite; negarse a inventar; verificar las cifras con la política.
Seis mejoras incrementales en lenguaje natural: alternativa cuando no hay confianza, filtro por tiempo, ignorar correos automáticos, ajustar el tono, firmar con tu nombre y usar un score de confianza.
Muestra en la práctica la iteración por capas: una mejora a la vez, probando cada una.
Iterar; pedir cambios en PT; una capa a la vez; puntuación de confianza.
Una checklist objetiva: ¿indexa? ¿clasifica correctamente? ¿se basa en el documento? ¿rechaza lo que está fuera de alcance? ¿firma? ¿respeta el filtro de tiempo?
Definir "listo" evita el ciclo infinito de "una mejora más".
Definición de terminado; copia de seguridad (exportación JSON); una persona aprueba el borrador.
⏰ Proyecto: Agentes alojados (programado + webhook)
Sacar el agente de tu máquina y ponerlo en la nube para que funcione solo. Construyes dos: uno programado (cron → búsqueda en la web con Firecrawl → síntesis → Google Sheets) y un por evento (el webhook recibe un payload → genera un .docx → lo guarda en Drive). En el camino: OAuth refresh token, debug que solo aparece en producción, auth Bearer, formulario no-code y deploy automático mediante GitHub.
Un agente que se activa según una agenda (cron), busca contenido en la web (Firecrawl), lo resume y registra cada fila en una hoja de cálculo, sin que tú estés presente.
Es el primer agente que «vive solo»: cierra la brecha agentic entre el entorno local y producción.
Cron (5 campos); scraping; síntesis; salida estructurada en Sheets.
En la nube no hay ventana de inicio de sesión: el agente usa un refresh token para renovar el acceso por su cuenta, y cuando la interfaz falla, lo obtienes desde la terminal.
Es el problema clásico del alojamiento; conocer la alternativa permite destrabar el deploy.
Access vs refresh token; renovación automática; alternativa desde la terminal.
Errores que no ocurren localmente (timeout, variable de entorno ausente, formato de fecha) y cómo encontrarlos leyendo el trace y devolviendo el error con contexto a la IA.
La producción tiene su propia realidad; el ciclo humano de depuración es la habilidad central.
Trace = paso a paso; devolver el error; redeploy; logs significativos.
El segundo agente: recibe un payload mediante webhook, crea un documento .docx con formato y lo guarda en Google Drive, y devuelve el enlace.
Enseña la activación por evento: el agente responde a una solicitud externa, no a un reloj.
Payload = datos del pedido; generar el archivo; guardar y devolver el enlace.
Un webhook es una URL que, al «tocarla», activa el agente. Como es pública, la proteges con un token Bearer en el encabezado.
Sin auth, cualquiera puede tocar el timbre; Bearer es el candado básico.
URL de activación; header Authorization: Bearer; rechazar si no hay token.
Un formulario simple (no-code) que, al enviarse, hace la solicitud al webhook con el payload, y así ofrece una interfaz humana para el agente.
Conecta a una persona real con el agente sin que tengas que escribir todavía el frontend.
Form → POST; mapear campos en el payload; pasar el token.
Conectar el repositorio de GitHub a la plataforma de hosting para que cada push haga el deploy automáticamente.
Elimina el deploy manual del proceso; el código del repo es la fuente de la verdad.
commit/push; deploy al hacer push; .gitignore protege el .env.
Lee el panel: cada run (ejecución), su trace (paso a paso), el schedule activo y la separación entre dev y prod.
Si no estás presente, el dashboard es lo que te permite saber si el agente está funcionando bien.
Runs; traces; schedules; dev vs. prod; alertas ante fallos.
🚀 Proyecto: app full stack (Lead Qualifier) + frontend para n8n
El proyecto más ambicioso: una app que otras personas usan. Backend que califica leads (Trigger.dev) + frontend (Vercel), conectados mediante variables de entorno. Después agregas autenticación (Supabase + RLS), haces una auditoría de seguridad, cobras con Stripe (freemium) y también construyes un frontend para un workflow de n8n (form → webhook). Todo mediante iteraciones incrementales: diseño → autenticación → pago.
El modelo de dos extremos: el frontend (lo que ve el usuario, en Vercel) llama al backend (la lógica del agente, en Trigger.dev), que hace el trabajo pesado.
Entender la división entre front y back es lo que permite construir productos, no solo automatizaciones.
Frontend vs. backend; request/response; dos deploys separados.
Una app que recibe los datos de un lead, los puntúa/califica con IA y devuelve la clasificación, construida a partir de un prompt inicial completo.
Repite el patrón «describe el resultado completo» ahora en un contexto full-stack.
Entradas fijas; salida estructurada; lógica de calificación.
El frontend descubre dónde está el backend (y la clave de acceso) mediante variables de entorno, nunca mediante un valor escrito en el código.
Es la costura que hace que ambos extremos se comuniquen de forma segura.
Variable de entorno; URL del backend; clave en tiempo de ejecución, no en el código.
Agregar inicio de sesión (Supabase) y Row Level Security (RLS), que garantiza en la propia base de datos que cada usuario solo vea sus propios datos.
Sin RLS, incluso un usuario con el inicio de sesión correcto puede leer datos ajenos; RLS es la defensa a nivel de datos.
Auth; RLS; migration; cada fila pertenece a un usuario.
Pedirle a la IA un análisis: rutas sin protección, claves expuestas, env vars filtrándose al cliente, RLS ausente.
Una app abierta = riesgo: alguien puede gastar tus tokens o leer datos ajenos.
Superficie de ataque; clave en el servidor; ningún secreto en el cliente.
Agregar el checkout de Stripe y un modelo freemium: uso gratis hasta un límite; después, un plan pago habilitado por webhook.
Transforma una app en un producto: ingresos reales con un flujo que se puede probar.
Checkout; price ID; webhook secret; freemium; límite de uso.
Darle un aspecto amigable a un workflow de n8n: una página con un formulario que envía los datos al webhook del flujo y muestra el resultado.
Combina los dos mundos del curso: automatización n8n con interfaz de app.
Form → POST webhook; CORS; muestra la respuesta; URL del webhook en env var.
El orden que funciona: primero la app fea pero funcional, después el diseño, luego la autenticación y, por último, el pago: una capa a la vez.
Iterar por capas mantiene cada paso comprobable y reversible.
Primero el MVP; una capa a la vez; haz una copia de seguridad antes de cambiar; prueba en cada paso.