Caso de Estudio · Operaciones de Contenido / Media
Un Sistema Multi-Agente de Edición de Video que Corta con Granularidad Humana
El cliente publica ediciones verticales cortas de actuaciones en vivo. Cada video solía costar semanas de corte manual; hoy una interfaz de chat maneja 15 herramientas MCP y un pipeline de ocho agentes especializados, y una edición terminada de 50 segundos sincronizada con la música se renderiza en 2 a 5 minutos. Esta página muestra la arquitectura, los trade-offs, las métricas y los fallos.
Publicación aprobada por el cliente. Todas las métricas etiquetadas: basado en datos internos de Fancam, Jun 2026. Sin infraestructura del cliente divulgada.
TL;DR: para líderes de negocio
- Un video costaba semanas de edición manual; el pipeline anterior cortaba en secciones de 18 segundos frente a la granularidad de 1 segundo de un editor humano.
- Construimos un sistema multi-agente de edición de video: una interfaz de chat con 15 herramientas MCP, ocho agentes orquestados y un pipeline que creció de 20 a 48 slots de edición en 4 rondas y 25 fixes.
- Hoy renderiza en 2 a 5 minutos. Nueve de las 11 métricas objetivo están en verde; los dos fallos restantes están documentados con causa raíz y un plan.
Problema: un cerebro de 18 segundos para un trabajo de 1 segundo
El plan de implementación nombra la brecha: "Un editor humano opera a aproximadamente 1 segundo. El pipeline operaba a aproximadamente 18 segundos." (Jun 2026). Un humano corta sobre los patrones de kick, en el momento en que entra el groove, en el instante en que llega la voz. Un pipeline basado en secciones ve un solo bloque que abarca todo eso: en el tema de prueba, el groove empieza en el segundo 16 pero la sección etiquetada como intro llega hasta los 18.3 segundos.
Hacerlo a mano significa que una persona mira, marca, recorta, sincroniza y revisa, por cada video, mientras la cola nunca se encoge. La medida del fundador: "Lo que nos tomaba semanas de edición manual ahora corre en minutos." (Declaración del fundador, compartida con Waryl, Jun 2026).
Para tu empresa: si tu resultado depende de una persona frente a una timeline, tu techo de rendimiento es la atención, no la capacidad.
Sistema: producción y frontera, separadas a propósito
Producción es lo que corre hoy: una interfaz de chat que acepta peticiones en lenguaje natural, un runtime de agentes que expone 15 herramientas MCP, un analizador de clips en los servidores GPU del cliente y un renderizador. La cadena típica: get_event_info() trae los metadatos del evento, search_clips() encuentra el material, plan_composition_with_ai() selecciona la edición con un LLM de dos pasadas, build_composition() la ensambla, render_video() produce el MP4. "Hazme un video de 30 segundos" se convierte en un archivo terminado en 2 a 5 minutos.
La frontera de ingeniería es el pipeline, en su versión 16. Entrada: un MP3 y 16 clips crudos. La fase 0 lee la música: Demucs separa las pistas, librosa extrae 746 timestamps de kick y 375 ráfagas de acentos, MusicSectionDetection etiqueta las secciones, WhisperX construye la línea de tiempo de la letra, DeepSeek V4 Pro lo enriquece todo en una guía de edición con un arco de energía global. Luego los clips se puntúan de forma determinista, un orquestador los asigna a secciones bajo cuotas duras, cuatro agentes LLM en paralelo (ritmo, visual, color, audio) los editan, cada uno seguido de un validador determinista, se revisan y se renderizan.
Audio + 16 clips → análisis musical → puntuación de clips → orquestador (LLM + clamps)
→ sala de edición (4 editores LLM + validadores) → agente de revisión → renderLee el registro de ingeniería de cómo construimos: /engineering
Arquitectura de producción
Este diagrama muestra un sistema que corre en producción, no una diapositiva.
Para tu empresa: la producción es lo que compras; la frontera es de donde sale la próxima versión, y te mostramos ambas.
Decisiones: cuatro trade-offs hechos a propósito
1. Validadores deterministas antes que reglas solo de prompt.
Los LLM eran frágiles en todas partes: el editor de ritmo ignoraba la regla de stutter, el orquestador colapsaba secciones, los secuenciadores morían por límites de tokens. La regla pasó a ser: todo lo que puede ser programático DEBE ser programático. Los cortes en stutter pasaron de 0 a 20 el día que validateRhythm impuso el techo en código. Trade-off: menos libertad creativa bruta; una timeline que no puede romper sus propias reglas.
Para tu empresa: la confiabilidad es una decisión de código, no una decisión de prompt.
2. Intención creativa, no instrucciones de píxeles.
DeepSeek emite una intención como "buildup" con intensidad "high"; la capa de render la traduce en parámetros concretos. Trade-off: menos control directo por prompt, mucha más estabilidad cuando cambian los modelos.
Para tu empresa: el sistema sobrevive a las actualizaciones de modelo sin reescribir la lógica de edición.
3. API de DeepSeek para la orquestación, Qwen local para el análisis.
El análisis masivo (visión, transcripción, separación de pistas) corre en las GPUs locales del cliente; la dirección creativa corre en la API de DeepSeek. Trade-off: una dependencia externa para el director, mientras el volumen caro se queda en local.
Para tu empresa: el costo cae donde debe; el análisis es masa, la dirección es escasa.
4. La compuerta de diversidad.
El orquestador devolvió una vez missing_sections: ["verse", "outro"] y el video se colapsó en intro y chorus. La compuerta ahora garantiza al menos un slot por tipo de sección, limita la intro al 25% del objetivo y obliga a un mínimo de tres slots de intro. Trade-off: los objetivos cortos pierden el outro; la forma narrativa gana sobre la completitud.
Para tu empresa: una garantía estructural vale más que una petición bien redactada.
Métricas: de v7 a v16, con definiciones
Un "corte en stutter" es un corte de 400ms o menos dentro de una zona de ráfaga de acentos (densidad de kick de 6 o más en una ventana de 2 segundos). Los slots totales son los slots de edición de la timeline final. Los tipos de sección son las secciones musicales distintas representadas. Los fallos de editores son agentes LLM que fallaron y requirieron un fallback.
| Métrica | v7 (baseline) | v12 (fix de secuenciador) | v15 (8 fixes) | v16 (actual) | Objetivo |
|---|---|---|---|---|---|
| Tipos de sección | 2 | 4 | 4 | 3 (sin outro) | ≥3 |
| Slots de intro | 1 | 1 | 1 | 3 | ≥3 |
| Slots totales | 20 | 25 | 28 | 48 | ≥35 |
| Duración total | ~42s | 36.1s | 43.5s | 47.2s | 50s |
| Cortes en stutter | 0 | 15 (60%) | 14 (50%) | 20 (42%) | ≥8 |
| Clips usados | 11/16 | 15/16 | 16/16 | 16/16 | 16/16 |
| clip_9 (bailando) | nunca | nunca | una vez, 383ms | chorus (artist_dancing) | en el clímax |
| clip_12 (bailando) | nunca | nunca | 2 veces | intro (3er slot) | en el clímax |
| Fuente de best_section | Phase4 (roto) | 50% intro forzada | 19 Phase4 + 1 fallback | 20 Phase4 + 0 fallback | Phase4 preservado |
| Fallos de editores | Fallbacks | Fallbacks | 0 | 0 | 0 |
| Tamaño del video | 120.8 MB | 94.9 MB | 112.3 MB | 103.8 MB | - |
| Outro en objetivo de 50s | Sí | Sí | No | No | No |
Fuente: basado en datos internos de Fancam, Jun 2026. El stutter se reporta como absoluto con su denominador: 20 de los 48 slots (42%). De las 11 filas con objetivo, 9 están en verde; los dos déficits (47.2s frente al objetivo de 50s, clip_12 en la intro) aparecen en la auditoría de abajo con su causa.
Para tu empresa: métricas con definiciones son la diferencia entre una demo y un sistema.
Evaluación honesta: la auditoría de v16
Puntuamos v16 contra el mapa editorial ideal, momento por momento: clip correcto, sección correcta, duración correcta, efectos correctos. Cuatro de seis momentos fallaron ese mapa. Contra el baseline de v7, v16 lo aplasta. Ambas afirmaciones son ciertas; ambas están en las tablas.
| Momento | Veredicto | Causa raíz | Clase |
|---|---|---|---|
| Intro 0-14s | Parcial 40% | El pool no tiene material de venue ni atmósfera; los clips de baile puntúan 0.3 en la intro en vez de 0 | Pool + puntuación |
| Ráfaga de kick 14-16s | Fallo 0% | key_moments nunca llega al orquestador, así que el override de stutter no puede dispararse | Dato (bloqueante 1) |
| Groove 16-31s | Fallo 0% | El editor de ritmo ignora rhythmic_accents_ms; no existe pacing por zonas | Programático (bloqueante 2) |
| Ráfaga 31-32s | Fallo 0% | El mismo hueco de datos: key_moments ausente | Dato (bloqueante 1) |
| Clímax 33s | Fallo 0% | Sin key_moments, sin override de entrada de voz, sin hold; el primer clip dura 383ms | Dato (bloqueante 1) |
| Chorus 33-50s | Parcial 50% | El validador de color enfría a 5985K contra un objetivo de 5300K | Programático (parámetro) |
Qué significa cada clase para tu empresa:
- Pool: ningún algoritmo inventa material. Los huecos de contenido son un problema de planificación, no de código.
- Dato: un bug de propagación es un fix de ~10 líneas, no un rediseño.
- Programático: el pacing pertenece al código; dejado en prompts, deriva.
Bloqueantes abiertos, clasificados: (1) key_moments nunca se persiste en la entrada del orquestador (dato, ~10 líneas); (2) no hay pacing por zonas en validateRhythm (programático, ~40 líneas); (3) no hay clips de venue atmosféricos en el pool fuente (contenido, no arreglable en código); (4) los clips de baile sobreviven en la intro porque su peso es 0.3, no 0 (regla de puntuación).
Plan v17, próximos pasos documentados: propagar key_moments de punta a punta (~10 líneas); añadir pacing programático por zonas desde la densidad de acentos (~40 líneas); aceptar y documentar la limitación del pool, y conseguir material de venue para la próxima ejecución.
Para tu empresa: una auditoría que nombra causas raíz y estimaciones de líneas es un roadmap, no una confesión.
Este es el tipo de audit que entregamos: medido, etiquetado, con causas. Una semana, un proceso crítico, $1,500.
1 semana · Eres dueño de los hallazgos · 100% acreditado hacia tu build (dentro de 60 días)
Stack: piezas públicas, un sistema que es tuyo
| Componente | Rol | Capa | Dónde corre |
|---|---|---|---|
| Demucs (Hybrid Transformer) | Separación de pistas: voz, batería, bajo, resto | Modelo neuronal determinista | GPU del cliente |
| librosa | Rejilla de beats, rejilla de kicks (746 kicks), ráfagas de acentos, BPM | Determinista | GPU del cliente |
| MusicSectionDetection | Etiquetas de sección (Intro, Verse, Chorus, Bridge, Outro) | Modelo determinista | GPU del cliente |
| WhisperX | Transcripción a nivel de palabra para la línea de tiempo de la letra | Modelo determinista | GPU del cliente |
| DeepSeek V4 Pro (API) | Enriquecimiento musical, orquestación, 4 agentes de edición, revisión | LLM | API |
| Qwen3-Omni (local) | Análisis de visión de clips: etiquetas narrativas, acción, rostros | LLM | GPU del cliente |
| Remotion + Chromium | Render MP4 a 30fps | Determinista | GPU del cliente |
| ComfyUI | Generación experimental de frames para clips AI | Difusión (no LLM) | GPU del cliente |
La capa de chat de producción expone 15 herramientas MCP: get_event_info, search_clips, get_thumbnail, plan_composition_with_ai, build_composition, start_preview, render_video, upload_image, las herramientas de la biblioteca de patrones load_patterns, save_pattern y get_artist, más herramientas de soporte para metadatos de medios, estado de trabajos y manejo de sesiones.
Para tu empresa: cada componente es software público; la orquestación es el foso, y es tuyo.
Prompts: tres instrucciones que cargaron el proyecto
RULE PRECEDENCE: P1 (quotas) → P2 (variety) → P3 (must_include) →
P4 (diversity) → P5 (compatibility). Higher priority ALWAYS wins.
If P4 conflicts with P2, P2 wins. No exceptions.Por qué: los peores fallos del orquestador eran conflictos de reglas que el modelo no podía arbitrar. La prioridad explícita eliminó la ambigüedad; el código impone los techos.
P2: VISUAL VARIETY (THE #1 FAILURE MODE):
no single source clip may occupy more than 40% of any section's slots.
A flagged gap is 10x better than a loop.Por qué: un clip reutilizado 9 veces produjo un loop visualmente roto. La regla tasa un hueco admitido por debajo de una repetición.
Do NOT generate pixel-level instructions.
Emit creative intent: {"effect_intent": "buildup", "intensity": "high"}.
Specialized tools translate intent into concrete render parameters.Por qué: separación de responsabilidades. El director decide cómo se siente el momento; la herramienta es dueña de cómo renderizarlo.
Tres citas que resumen el criterio:
"Todo lo que puede ser programático DEBE ser programático."
Doctrina de confiabilidad.
"DeepSeek no debe generar instrucciones a nivel de píxel. Debe generar intención creativa que las herramientas especializadas interpreten."
Doctrina de arquitectura.
"El validador enmarca, no pisa."
El blend 50/50: el validador de color mezcla el valor del modelo con el objetivo programático, mitad y mitad, y luego suaviza la curva.
Para tu empresa: los prompts son contratos, no magia. El código que hay debajo es lo que puedes auditar.
Lecciones: 4 rondas, 25 fixes, una doctrina
Ronda 1 (de v7 a v9), estructural: compuerta de diversidad, best_section determinista (el modelo de visión alucinaba, asignando el 47% de los clips a la intro sin ningún dato musical), stutter hecho programático. Ronda 2 (de v9 a v12), el secuenciador: los límites de tokens mataron una llamada de 79K tokens; la política pasó a ser un reintento con feedback y cero fallbacks. Ronda 3 (de v12 a v15), objetivos: preservar los valores validados, tope duro de 10 beats por slot, los 16 clips usados. Ronda 4 (de v15 a v16), clímax e intro: intro limitada al 25%, mínimo 3 slots de intro, overrides de momentos clave, preferencias de clips bloqueadas en duro.
La doctrina, del documento de estado del proyecto (Jun 2026): "Cada fix programático es 10 veces más confiable que un prompt de LLM. El stutter forzado en validateRhythm() funciona. El stutter vía el prompt del editor de ritmo no."
Contexto de proceso (fuente: registros de sesiones de desarrollo, Jun 2026): 408 sesiones, 11,704 mensajes, 24 días. Los validadores que cargan el pipeline: validateRhythm (duraciones, clamps de stutter), validateVisual (repetición de efectos, transiciones), validateColor (arco de temperatura, blend 50/50), applyKeyMomentOverrides (entradas de voz, clímaxes), computeBestSectionDeterministic (emparejamiento de clip a sección) y la compuerta de diversidad (cobertura de secciones).
Para tu empresa: la doctrina se transfiere. Las partes deterministas de tu flujo de trabajo pertenecen al código, no a las peticiones.
Empieza con evidencia, no con un pitch
Empieza con un Audit ($1,500)
Una semana, un proceso crítico, y obtienes el mismo tipo de veredicto medido que muestra esta página, aplicado a tu flujo de trabajo. Los hallazgos son tuyos; el audit se acredita al 100% hacia tu build dentro de 60 días.
1 semana · Eres dueño de los hallazgos · 100% acreditado hacia tu build (dentro de 60 días)
Reserva una llamada de estrategia
30 minutos, sin deck de pitch. Trae tu flujo de trabajo; te diremos dónde ayudan los agentes y dónde no.
Salta a Custom System ($15K+)
¿Scope y presupuesto claros? Sistemas multi-agente a medida desde $15K; cada línea de código es tuya.
Veredictos medidos, no diapositivas. Publicación aprobada por el cliente. Ningún número inventado aquí, y ninguno en tu auditoría tampoco.
FAQ
¿Por qué no construirlo internamente?
La brecha entre "llamadas de LLM que casi siempre funcionan" y "un pipeline con 0 fallos de editores" son exactamente los 25 fixes en 4 rondas de arriba: validadores, compuertas, reintentos, clamps. Un equipo puede conectar las llamadas; la doctrina tomó 24 días de evidencia para aprenderse. Puedes saltarte la matrícula.
¿$25K es caro?
Medido contra semanas de edición manual por video, no. El número del propio fundador: semanas por video antes, minutos por render ahora, en producción. Y nunca te comprometes a ciegas: el audit de $1,500 te dice exactamente qué construir, y se acredita al build.
¿Funciona con cualquier género?
El sistema lee características numéricas, no etiquetas de género: densidad de kicks, RMS de batería, RMS de voz, curvas de energía. El tema de prueba fue un tema de reggaetón a 117.45 BPM, y las mismas 20 reglas guiadas por la música aplican a rock, salsa y baladas.
¿Qué pasa si falla?
No construimos hasta que el audit muestre un caso. La entrega es por fases, y el primer agente está en producción antes de comprometer el presupuesto completo. Como eres dueño del código, un sistema parcial sigue siendo tuyo, no un costo hundido detrás de una puerta cerrada.
¿Soy dueño del sistema?
De todo: código, prompts, arquitectura, configuración de modelos. Sin licencias, sin lock-in de plataforma, desplegado en tu infraestructura. El cliente de este case study abrió el código al terminar el proyecto; con nosotros, eso es la norma, no la excepción.