Workflows de IA multi-herramienta

El problema

La mayoría de los desarrolladores usan una sola herramienta de IA — ChatGPT, Copilot, o Claude. Es como tener una caja de herramientas con solo un martillo. Diferentes tareas necesitan diferentes herramientas, y el verdadero poder viene de conectarlas entre sí.

Nuestro stack real

Esto es lo que corremos diariamente, cada herramienta elegida por una razón específica:

Seis categorías, cada una sirviendo una función distinta. Elegí herramientas que funcionen headless (sin GUI requerida) y que puedan llamarse desde scripts.

Cómo elegimos la herramienta correcta

El framework de decisión es simple:

Para razonamiento y generación: Claude. Cuando necesitamos análisis, escritura, código, o pensamiento estratégico — no hay sustituto para un modelo de frontera.

Para procesamiento de audio: Testeá con tu formato de audio real. Diferentes servicios de transcripción manejan diferentes codificaciones. Descubrimos que los modelos más nuevos no siempre manejan todos los formatos — a veces un modelo más viejo y probado en batalla funciona mejor. Siempre testeá con datos reales, no benchmarks.

Para operaciones de archivos: Las herramientas de sync basadas en CLI le ganan a las bibliotecas de SDK para tareas simples. Un comando para copiar un archivo le gana a 20 líneas de boilerplate de API:

# Ejemplo: sincronizar un archivo a almacenamiento en la nube
your-sync-tool copy local-file.md remote:folder/

Sin SDK, sin código de autenticación, sin boilerplate.

Para control de versiones: Las herramientas de CLI te permiten crear un branch, pushear, y abrir un PR en tres comandos:

git checkout -b feature/new-article
git push origin feature/new-article
gh pr create --title "feat: New article" --body "Description here"

Experimento: construyendo un pipeline de voz-a-PR

Acá hay un workflow real que encadena múltiples herramientas:

1. Input de voz (plataforma de mensajería) → archivo de audio crudo guardado en disco
2. Servicio de transcripción convierte audio → instrucción de texto
3. Modelo de IA interpreta la instrucción y escribe código/contenido
4. CLI de control de versiones crea un branch, commitea, pushea, abre un PR
5. Herramienta de sync en la nube respalda artefactos al almacenamiento en la nube
6. Motor de TTS narra un resumen como audio
7. API de mensajería entrega la nota de voz de vuelta al usuario

Siete categorías de herramientas en un solo workflow. Cada una maneja lo que mejor hace. Ninguna herramienta sola podría hacer todo esto.

Lo que aprendimos: La capa de orquestación importa más que cualquier herramienta individual. Claude actúa como el cerebro — decide qué hacer y llama a las otras herramientas. Pero es el pipeline el que crea el valor, no ninguna herramienta individual en aislamiento.

Errores de selección de herramientas que cometimos

Error 1: Intentar usar una herramienta para todo. Al principio, intentamos que Claude manejara uploads de archivos directamente. No puede — genera contenido, pero las operaciones de archivos necesitan herramientas dedicadas. Separar "pensar" de "hacer" fue un insight clave.

Error 2: Elegir el modelo de transcripción equivocado. Inicialmente asumimos que el modelo más nuevo de nuestro proveedor de transcripción sería el mejor. No lo fue — falló con nuestra codificación de audio específica. La lección: testeá con tu formato de datos real, no con benchmarks.

Error 3: Sobre-ingeniería de la integración de almacenamiento en la nube. Inicialmente armamos un entorno virtual de Python con una biblioteca de SDK completa. Después nos dimos cuenta de que una herramienta de sync por CLI hace lo mismo en un comando. Las herramientas más simples ganan cuando la tarea es simple.

Cuándo agregar una herramienta nueva

Usamos este checklist antes de agregar otra herramienta al stack:

1. ¿Hay una tarea real que resuelve? No teórica — algo que realmente necesitamos hacer repetidamente.
2. ¿Se solapa con una herramienta existente? Si sí, ¿es significativamente mejor para el caso de uso específico?
3. ¿Puede correr headless? Necesitamos herramientas que funcionen desde scripts y cron jobs, no solo GUIs.
4. ¿Cuál es el modo de falla? Si esta herramienta se cae, ¿qué se rompe? ¿Podemos tener fallback elegante?

Identificamos 23 brechas de herramientas a través de una auditoría sistemática (ver el Reporte Estratégico de Herramientas de IA). Pero las brechas no son problemas urgentes — son oportunidades para evaluar cuando surge la necesidad.

Lo que no usamos (todavía)

Siendo honestos sobre nuestras brechas conocidas:

• Sin LangChain/LangGraph — orquestamos a través de nuestra plataforma de agentes, no un framework dedicado
• Sin base de datos vectorial — sin búsqueda semántica sobre nuestro propio contenido
• Sin Ollama/modelos locales — completamente dependientes de APIs en la nube
• Sin herramientas de observabilidad — sin LangSmith o Langfuse rastreando nuestras llamadas de IA

Estas no son descuidos — son trade-offs conscientes. Nuestro stack actual resuelve nuestros problemas actuales. Las brechas se vuelven relevantes cuando pasemos de "AI power user" a "AI builder" (Módulos 3-6).

El principio

Adaptá herramientas a tareas, no tareas a herramientas. Empezá con lo que necesitás lograr, después encontrá la herramienta más simple que lo haga de forma confiable. La complejidad debería venir de combinar herramientas simples, no de usar herramientas complejas.

Fuentes

• Docs de la API de Deepgram — servicio de transcripción
• Documentación de rclone — CLI de almacenamiento en la nube
• Manual de GitHub CLI — operaciones programáticas de GitHub
• API de Brave Search — búsqueda web para agentes