El departamento legal de IA a $20/día: arquitectura del sistema
33 de 37 tareas completadas, cero intervención humana, tope de $20/día. Arquitectura de nuestro motor de investigación legal.
33 de 37 tareas completadas. $20/día de costo operativo. Cero intervención humana durante la ejecución autónoma. Las 4 tareas restantes bloqueadas por una dependencia externa de financiamiento, no por una falla del sistema.
Esos son los números de nuestro motor autónomo de investigación legal, un sistema que construimos en 3 días y operamos en producción durante semanas. Reemplazo una función de investigación que habría requerido 3-5 analistas junior a $2-4K/mes cada uno.
Así es como funciona, que se rompió en el camino y como se vería desplegado para un cliente.
El Problema
Un venture de tecnología legal necesitaba validar cinco kill criteria simultáneamente: demanda de mercado para herramientas de búsqueda legal ecuatoriana, factibilidad de corpus (si los datos podían siquiera ser scrapeados e indexados), umbrales de precisión de IA, duración del ciclo de ventas y product-market fit. El equipo fundador tenía cero investigadores legales y ningún presupuesto para analistas de tiempo completo.
El camino tradicional: contratar 3-5 investigadores junior, gestionarlos con standups semanales, esperar 3-6 meses por resultados. Costo total: $6-12K/mes solo en salarios, más overhead de gestión.
Tomamos un camino diferente.
La Arquitectura
El sistema es una aplicación Flask corriendo como servicio systemd en un VPS de DigitalOcean (2 vCPU, 4GB RAM, $24/mes). Usa APScheduler para 6 trabajos programados y un hilo worker continuo de backlog para ejecución de sprints. El codebase tiene ~3,750 líneas de Python en 26 archivos, más 35 documentos de definición de agentes.
El loop del sprint funciona así:
- Cargar contexto de memoria desde archivos markdown de agent-memory y documentos de tracking del pipeline
- El agente orquestador planifica 2 tracks de investigación del backlog
- Ejecutar tracks secuencialmente (gate de presupuesto verificado entre cada uno)
- Calificar la calidad del output, rechazar cualquier cosa debajo de 0.4
- Escribir el historial del sprint, actualizar el dashboard de kill criteria
- Postear un digest por hora en Slack (suprimido si no paso nada)
La ejecución secuencial fue una decisión deliberada. Nuestro proxy de API local no puede manejar requests paralelos, y el procesamiento secuencial simplifica el debugging. Cuando algo falla, el trace de error apunta a exactamente un agente haciendo exactamente una cosa. La ejecución paralela es una mejora directa cuando la infraestructura lo soporte.
10 Agentes, 4 Equipos
Cada agente tiene un rol específico y una asignación de modelo específica. Las tareas de razonamiento más pesado corren en Claude Sonnet 4 ($3.00/$15.00 por millón de tokens). Las tareas más rutinarias corren en Claude Haiku 4 ($0.80/$4.00 por millón de tokens).
El legal-orchestrator maneja la planificación de sprints, coordinación y actualizaciones del dashboard. El corpus-engineer gestiona el pipeline de datos: scraping, OCR, indexación. El product-architect es dueno del diseño de sistema, specs de API y decisiones de arquitectura. El sales-strategist ejecuta análisis de go-to-market, investigación de precios y outreach de design partners. El compliance-specialist cubre la LOPDP (la ley de protección de datos de Ecuador), preparación SOC 2 y requisitos regulatorios. El market-researcher maneja análisis competitivo y dimensionamiento de mercado. El grant-writer produce solicitudes de financiamiento y materiales de pitch. El legal-domain-expert valida interpretaciones de ley ecuatoriana y calidad del corpus. El ux-designer investiga flujos de trabajo de abogados y patrones de interacción. El growth-hacker desarrolla estrategias de adquisición y retención de usuarios.
Estos 10 agentes se organizan en 4 configuraciones de equipo según el foco del sprint. Los equipos de validación de mercado emparejan al orquestador con los agentes de ventas, investigación de mercado y dominio legal. Los equipos técnicos combinan al orquestador con ingeniería de corpus, arquitectura de producto y cumplimiento. Los equipos de financiamiento reúnen al orquestador, redactor de grants, investigador de mercado y estratega de ventas. Los sprints de lanzamiento completo usan los 10.
La Historia de la Ingeniería de Calidad
Esta es la parte que más importa y que la mayoría de los demos de IA omiten por completo.
La primera versión del daemon no tenía gates de calidad. Apuntamos 10 agentes a un backlog de investigación y los dejamos correr. El output era técnicamente fluido y sustantivamente inútil. Los agentes producian análisis de 2,000 palabras con terminología legal correcta organizada en patrones sin sentido. Disparates que sonaban convincentes. Un agente escribio un “análisis de mercado” detallado que en realidad era una reformulación de sus propias instrucciones, rellenado con observaciones genericas sobre el sector legal tech.
La segunda versión agregó validación básica de output. Atrapaba la basura peor (respuestas vacias, rechazos explícitos, texto placeholder obvio) pero dejó pasar una categoría que empezamos a llamar “basura sofisticada”: outputs que pasaban chequeos superficiales pero no contenian información real. Un agente podia producir un análisis competitivo bien formateado con encabezados, bullet points y cifras porcentuales, donde cada porcentaje era inventado y cada nombre de empresa era real pero las afirmaciones sobre ellas eran fabricadas.
La tercera versión, la que corre en producción, tiene tres capas de control de calidad.
Detección de basura: 50+ patrones de strings atrapan rechazos (“as an AI, I cannot”), quejas de capacidad (“I don’t have access to”), planificación-sin-acción (“let me search for”), resultados de búsqueda vacíos presentados como hallazgos, y confusión de herramientas/funciones (el agente intentando invocar herramientas cuando corre en modo solo-síntesis). Cada patrón fue agregado después de una falla específica. La lista creció durante la primera semana de operación a medida que identificábamos nuevos modos de falla.
Scoring de contenido: Cada output recibe un puntaje en escala de 0.0 a 1.0. Base de 0.3 para cualquier contenido que exista. Bonos por conteo de palabras (100+ palabras = +0.1, 300+ palabras = +0.1), marcadores de sustancia (montos en dólares, porcentajes, URLs, fechas, tablas, encabezados estructurados = hasta +0.3 combinado). Penalización de -0.15 por lenguaje pesado en planificación. Cualquier cosa debajo de 0.4 se rechaza.
Tope de reintentos: 3 intentos por tarea. Después de 3 outputs basura, la tarea queda permanentemente bloqueada y marcada para revisión humana. Esto evita que el sistema queme presupuesto en tareas que no puede completar. De las 37 tareas totales, 33 se completaron exitosamente. Las 4 que se bloquearon estaban todas en la categoría de financiamiento, esperando timelines de grants externos en lugar de fallar gates de calidad.
Una decisión arquitectónica que vale la pena explicar: los agentes corren con tools=[] durante la ejecución de sprints. Esto significa que sintetizan a partir del contexto cargado en su prompt en lugar de intentar llamadas de herramientas en vivo. Las versiones tempranas intentaban invocar búsqueda web y operaciones de archivos a mitad del sprint, lo cual causaba errores de permisos y output confuso. Al restringir a los agentes a modo solo-síntesis durante la ejecución (el uso real de herramientas ocurre en la fase de planificación del orquestador), eliminamos una categoría entera de fallas de runtime.
Controles de Presupuesto
El sistema aplica un tope de $20/día via una tabla SQLite api_calls. Antes de cada ejecución de track, el daemon verifica el gasto acumulado del día. Si se alcanza el tope, el sprint pausa hasta medianoche UTC.
Cada llamada de API registra su costo: tokens de entrada multiplicados por la tarifa por token del modelo, más tokens de salida multiplicados por la tarifa de salida. Los resúmenes de fin de día se registran sin borrar datos (queries filtrados por fecha manejan la contabilidad). El endpoint de salud en /health reporta gasto diario actual, presupuesto restante, estadísticas del backlog y estado del worker.
Costo operativo mensual: $224-624 dependiendo de la frecuencia de sprints. El VPS cuesta $24/mes. Los costos de API van de $200-600/mes. Slack y Notion son $0 incrementales ya que el workspace ya existe.
Compara eso con la alternativa: 3 investigadores junior a $2-4K/mes cada uno, más un manager dedicando 5-10 horas semanales a coordinación. $6-12K/mes, mínimo.
Auto-Reparación
Después de 3 fallas consecutivas de sprint, el daemon ejecuta un sprint de diagnóstico. Lee los logs de errores recientes, diagnóstica la causa raiz, recomienda correcciones y postea el diagnóstico en Slack. Si el sprint de diagnóstico también falla, el sistema pausa completamente y espera una llamada manual POST /reset-failures.
Esto ocurrió dos veces durante la primera semana. Una vez cuando el proxy de API alcanzó un rate limit que no habíamos anticipado, y otra cuando un job de consolidación de memoria corrió durante un sprint y creó un conflicto de file lock. Ambas veces, el sprint de diagnóstico identificó correctamente el problema y la corrección se aplicó en menos de 10 minutos.
Operaciones Programadas
El daemon ejecuta 6 trabajos programados más allá del loop central de sprints:
Los digests por hora van a Slack con una actualización de estado limpia. Se suprimen si nada ocurrió en la hora anterior, para que el canal se mantenga legible. Los reportes diarios a las 13:00 UTC incluyen un resumen generado por IA con datos de presupuesto y métricas de progreso. Las revisiones de kill criteria corren cada lunes a las 14:00 UTC con una evaluación detallada GO/NO-GO en los 5 criterios. La consolidación de memoria corre cada domingo a las 06:00 UTC, fusionando las docenas de archivos de memoria pequenos generados durante la semana en 4 documentos por categoría (investigación de mercado, hallazgos técnicos, inteligencia de financiamiento, análisis de cumplimiento). Un verificador de timeout de aprobaciones corre cada 15 minutos para manejar solicitudes de aprobación obsoletas en Slack. Un job de reset de presupuesto corre a medianoche UTC para registrar el resumen de fin de día.
Cómo se ve un deployment para cliente
El framework esta diseñado para ser redesplegado en diferentes dominios. La arquitectura del loop de sprints, el algoritmo de scoring de calidad, el tracking de presupuesto, el schema de SQLite, el endpoint de salud Flask, la integración con APScheduler, el handler de interacción con Slack, el patrón de worker continuo de backlog, el diagnóstico de auto-reparación y el pipeline de consolidación de memoria son toda infraestructura fija.
Lo que cambia por cliente: el número de agentes, sus instrucciones, composiciones de equipo, patrones de detección de calidad (un bufete de abogados necesita patrones de basura diferentes a una empresa de logística), topes de presupuesto, frecuencia de sprints, canales de Slack, bases de datos de Notion, kill criteria, timing de jobs programados y bonos de scoring específicos del dominio.
Timeline de deployment:
| Fase | Duración | Actividades |
|---|---|---|
| Discovery y scoping | 3-5 días | Definir preguntas de investigación, backlog, expertise de dominio, integraciones |
| Personalización de agentes | 3-5 días | Reescribir instrucciones de agentes, ajustar composiciones de equipo, configurar patrones de calidad |
| Configuración de integraciones | 2-3 días | App de Slack, bases de datos de Notion, API keys, aprovisionamiento de VPS |
| Testing y calibración | 3-5 días | Correr sprints de prueba, ajustar umbrales de calidad, validar output |
| Handoff y monitoreo | 2-3 días | Documentación, configuración de monitoreo, entrenamiento de Slack |
| Total | 13-21 días |
La Evaluación Honesta
Este sistema es bueno para síntesis de investigación: tomar una pregunta definida, reunir contexto relevante, producir análisis estructurado e iterar en calidad. Completo el 89% de sus tareas asignadas de forma autónoma.
No es bueno en tareas que requieren acceso a datos externos en tiempo real (la restricción de solo-síntesis significa que los agentes trabajan desde contexto pre-cargado, no busquedas web en vivo durante sprints). No es bueno en tareas con dependencias externas (las 4 tareas bloqueadas estaban esperando timelines de financiamiento que ninguna cantidad de inteligencia de agentes podia acelerar). Y requirió 3 reescrituras completas de la capa de ingeniería de calidad antes de dejar de producir basura.
Las 3 reescrituras son la parte importante. Cualquiera que venda deployments de agentes de IA y afirme que su sistema funciono al primer intento esta mintiendo o no lo ha probado contra tareas reales. La ingeniería de calidad es el producto. Los agentes son infraestructura commodity.
Para una función de investigación legal, un equipo de análisis de cumplimiento, una unidad de inteligencia de mercado, o cualquier departamento que opere con investigación y síntesis estructurada, esta arquitectura funciona. $224-624/mes en lugar de $6-12K/mes, con calidad de output que mejora con el tiempo a medida que el sistema de memoria acumula conocimiento de dominio.
Synaptic construye sistemas autónomos de IA que reemplazan departamentos, no personas. Deployment en 13-21 días. synaptic.so