--- title: "voxcog: agentes de IA que aguantan en producción" description: "Cómo se reconstruyó la plataforma de agentes de voxcog en torno a un agente con 55 herramientas, tres niveles de modelo y una evaluación que corre en CI." url: https://torn.studio/es/trabajos/voxcog-agentes-de-ia-en-produccion locale: es published: 2026-08-31 updated: 2026-08-26 --- # voxcog: agentes de IA que aguantan en producción > **Respuesta breve:** Torn Studio construyó la plataforma de agentes de voxcog: 55 herramientas detrás de un agente que las carga cuando hacen falta, tres niveles de modelo para que cada llamada vaya al más barato capaz de resolverla, y una evaluación que corre en CI con cada cambio. Se entregó en agosto de 2026. **Cliente:** voxcog · **Entregado:** 2026-08-26 **La relación del estudio con el cliente:** voxcog es un producto que Torn Studio construyó y en el que el estudio tiene una participación. El estudio llevó la gestión de producto, la arquitectura y la construcción hasta la entrega en agosto de 2026. ## El encargo voxcog necesitaba un agente capaz de alcanzar todo el producto en una sola conversación — documentos, señales, tareas, calendario, investigación y entregables de producto — y de funcionar en producción para varios clientes a la vez. ## Lo que lo hizo difícil - Una versión anterior metía unas cuarenta herramientas y un prompt de sistema largo en cada llamada, lo que chocaba con el techo de Anthropic de 50.000 tokens por minuto y bloqueaba el chat para todos los clientes a la vez. - La ejecución ocurre en una plataforma sin servidor con 270 segundos de reloj por turno, así que cada corrida del agente tiene que terminar dentro de ese margen. - Las respuestas tienen que sostenerse después, lo que exige medir la calidad de forma continua y que esa medición corra en CI contra corridas grabadas. ## Cifras que se pueden contar | Cifras que se pueden contar | | | | --- | --- | --- | | 55 | herramientas tras un agente | Registradas en un módulo y contables ahí. El agente lleva un conjunto fijo pequeño en el prompt y carga el resto cuando la conversación lo pide. | | 3 | niveles de modelo | Haiku 4.5, Sonnet 4.6 y Opus 4.6, declarados en un archivo de doce líneas. Mover un carril entero entre niveles es cambiar una línea. | | 50.000 | tokens por minuto, el techo | El límite con el que chocaba la topología anterior. La nueva sostiene el mismo catálogo bajo el mismo techo manteniendo el prompt pequeño. | | 20 | pasos como máximo por corrida | El tope del modo de investigación más profundo. El comentario del código dice que solo sube tras volver a medir el reloj, lo que convierte el tope en una decisión con regla de revisión. | ## Cómo se hizo ### Un agente y herramientas bajo demanda Cinco agentes especialistas se sustituyeron por un director con un conjunto fijo y pequeño de herramientas. El resto del catálogo lo alcanza mediante una búsqueda que carga una herramienta justo cuando hace falta, lo que mantiene cada llamada pequeña aunque el catálogo crezca. ### Tres niveles de modelo con límites claros Haiku 4.5 clasifica y responde lo sencillo, Sonnet 4.6 hace el razonamiento y escribe los entregables, Opus 4.6 queda en reserva para lo más pesado. Cada llamada va al nivel más barato capaz de resolverla, y una respuesta 429 se reintenta según la cabecera retry-after del propio servidor. ### Presupuestos que son código Cada encargo de investigación lleva un tope de pasos fijado por profundidad — cuatro, seis o veinte — dimensionado sabiendo que una llamada a herramienta tarda unos cinco segundos. El tope vive en una función con sus propias pruebas, y el comentario encima dice que veinte solo sube tras volver a medir el reloj. ### Una evaluación que corre cada vez Una corrida grabada se guarda como artefacto y se reproduce offline, lo que da a CI una puerta determinista que funciona con material grabado. Encima van una corrida juzgada cada noche y muestreos continuos de relevancia, alucinación y tono. **Tecnología:** Next.js 16, Mastra, Claude Haiku 4.5, Claude Sonnet 4.6, Supabase, Postgres, pgvector, Vitest ## Hasta dónde llega esta prueba Esto demuestra que una plataforma de agentes puede construirse de forma que aguante en operación y se pueda medir. De su valor de mercado dice poco: la plataforma se entregó antes del lanzamiento y en ese momento tenía cero usuarios de pago. ## Preguntas frecuentes ### ¿Por qué un solo agente carga todo el catálogo de herramientas? Con cinco agentes, cada traspaso comprimía un razonamiento a prosa, y esa compresión costaba más calidad de la que devolvía la especialización. Un director con herramientas bajo demanda mantiene todo el contexto en un mismo sitio. ### ¿Cómo evitáis que una corrida del agente se descontrole? Cada modo lleva un tope de pasos en código, fijado según lo que tarda de verdad una llamada a herramienta. El último paso fuerza una respuesta apagando la elección de herramienta, así que una corrida termina respondiendo aunque agote el presupuesto. ### ¿Cómo sabéis que la calidad de las respuestas se mantiene? Una corrida grabada se guarda como artefacto y se reproduce en CI, lo que da una puerta determinista que funciona con material grabado. Encima van una corrida juzgada cada noche y muestreos de relevancia y alucinación. ### ¿Cuánto cuesta operar una plataforma así? El coste depende de qué modelo responde cada llamada, y por eso el enrutado vive en código: la clasificación sencilla corre en el modelo más barato y solo el razonamiento pesado llega al caro. Mover un carril entero es cambiar una línea. ### ¿Se puede aplicar el mismo diseño a nuestros sistemas internos? Sí, el patrón es independiente del producto. Un director, un catálogo de herramientas bajo demanda, presupuestos en código y una evaluación en CI son las mismas cuatro piezas, lean las herramientas tu base de datos o tu sistema de tickets. ### ¿Cuánto tardó la plataforma de agentes? La reconstrucción se planificó en abril de 2026 y la puerta de evaluación en mayo, y ambas estaban en producción antes de la entrega de agosto. El trabajo corrió en paralelo al resto de la plataforma y lo hizo una sola persona.