Cuándo usar cadena fija y cuándo usar un agente en un Content Factory

Cuando construyes un pipeline con LLMs, la primera decisión no es qué modelo usar. Es quién decide el orden del trabajo. Si ese orden ya lo conoces, conviene codificarlo como una cadena fija. Si el siguiente paso depende de leer el caso y elegir entre varias acciones posibles, ahí sí vale la pena un agente.

Esa frontera evita dos errores comunes. El primero es meter agencia donde no hace falta y pagar más latencia, más costo y más dificultad para depurar. El segundo es tratar como simple un problema que en realidad exige diagnóstico y decisión en tiempo de ejecución.

La regla de diseño que sí se puede reutilizar

La regla práctica es directa: cadena fija cuando el procedimiento se conoce; agente cuando lo que hay que decidir es el procedimiento mismo. En una cadena, el desarrollador decide el orden de los pasos. En un agente, ese orden se resuelve durante la ejecución según lo que va encontrando el modelo. [49][48]

Esa diferencia parece pequeña, pero cambia el costo del sistema. Un agente agrega llamadas al modelo, hace crecer el contexto en cada vuelta y complica la depuración. En un caso complejo, un sobrecosto de cinco veces frente a un pipeline equivalente es una cifra realista. Por eso conviene empezar cerca del extremo determinista y añadir autonomía sólo cuando el problema la exige. [48][51]

La alternativa descartada queda clara con un ejemplo de generación editorial. Si tu flujo ya está decidido, darle al modelo la tarea de escoger el orden no resuelve el problema difícil. Sólo añade imprevisibilidad y costo para decidir algo que el código ya sabe hacer. [49][69][87]

Un ejemplo concreto: análisis, índice, secciones y ensamblado

Un pipeline de generación puede organizarse como una cadena fija de cuatro pasos: analizar el corpus, proponer el índice, escribir cada sección y ensamblar el resultado final. Ese orden fue definido de antemano y no cambia run por run. La parte transferible no es el detalle exacto de esos cuatro pasos. La lección reusable es otra: si tu proceso ya tiene una secuencia estable, trátalo como secuencia estable. [49][69][87]

En un sistema real, cada paso puede vivir como trabajo en cola con su propio checkpoint persistido. Las secciones sí pueden correr en paralelo entre sí, porque ese trabajo es genuinamente independiente. Cuando ese lote termina, se dispara el ensamblado. [49][53][69]

El flujo objetivo del sistema también marca por qué esa cadena existe. La meta no es que la IA escriba sola. La meta es bajar la revisión humana a cerca del 20% del trabajo en vez del 100%. Para que eso pase, la salida tiene que llegar estructurada, citada y con huecos declarados. Si una persona tiene que revisar todo desde cero, el pipeline no ahorra nada. [100]

Ese criterio te sirve para tus propias decisiones. Usa cadena fija cuando ya sabes qué salida debe producir cada etapa y en qué orden se conectan. Cambia a un mecanismo más abierto sólo cuando aparezcan decisiones que no puedes anticipar con reglas simples.

Por qué los checkpoints persistidos cambian la operación diaria

Un pipeline útil no sólo produce resultados. Sobrevive a fallos parciales. Para eso sirve persistir checkpoints en cada paso. En el caso descrito por el corpus, el estado no vive en memoria. Vive en la base de datos, en filas de pasos con su resultado. [53]

Esa persistencia compra cuatro cosas concretas.

Primero, reintentos. Si falla un paso, no necesitas reiniciar toda la corrida. Puedes volver sobre el punto exacto que se rompió. [49][55]

Segundo, inspección. El contexto de recuperación y diagnóstico cabe completo en el propio run, sus checkpoints y sus pasos. En ese caso no hace falta recuperación documental; basta con pasar todo el estado relevante porque es conocido y acotado. [11]

Tercero, recuperación parcial. Si el ensamblado quedó a medias, puedes reanudarlo. Si una sección falló, puedes decidir omitir sólo esa sección. El trabajo previo no se pierde. [87][89]

Cuarto, diagnóstico. Cuando un run falla, el problema ya no es generar texto sino entender qué salió mal. Los checkpoints permiten releer errores, mirar salidas intermedias y decidir la reparación sobre evidencia, no a ciegas. [49][87]

Aquí también hay un criterio general. Si quieres que tu sistema resista caídas a mitad del proceso, el estado de cada etapa tiene que existir fuera de la memoria del worker. Sin ese estado persistido, no hay punto intermedio al cual volver.

El lugar donde sí conviene un agente: reparar corridas fallidas

La recuperación de una corrida fallida sí justifica un bucle agéntico. La razón es simple: no sabes de antemano qué falló ni qué acción conviene. Puede bastar un reintento. Puede convenir omitir una sección. Puede hacer falta reanudar el ensamblado. Ese procedimiento se decide leyendo el caso. [49][87]

En ese agente, la superficie de efecto debe ser pequeña. El corpus delimita tres acciones: reintentar el paso fallido, omitir la sección fallida y reanudar el ensamblado. No relanza el pipeline entero, no toca fuentes y no publica nada. Eso aplica el principio de mínimo privilegio a la operación del agente. [89]

Las herramientas del agente quedan así:

public function tools(): iterable
{
    return [
        // Lectura: sin aprobación, para que diagnosticar no interrumpa a nadie.
        new InspectRunTool($this->run),
        new InspectStepOutputTool($this->run),

        // Efecto: aprobables, porque cambian el estado de algo.
        new RetryFailedStepTool($this->run, $this->retry),
        new SkipFailedSectionTool($this->run, $this->skip),
        new ResumeAssemblyTool($this->run, $this->resume),
    ];
}

La consecuencia operativa es útil: el agente puede leer libremente para diagnosticar, pero las acciones que cambian estado quedan sujetas a aprobación humana. [88][89]

El manejo de errores también se vuelve más claro cuando separas clases de fallo. Los fallos transitorios, como un tiempo agotado o un 429, sí se reintentan con espera creciente. Los de contenido no conviene repetirlos sin cambiar instrucción o contexto. Los estructurales deben fallar y avisar. En el sistema descrito, los pasos de generación se reintentan una sola vez a nivel de trabajo; lo demás lo decide una persona con ayuda del agente de recuperación. [55]

Un agente así necesita límites explícitos. El corpus marca tres: máximo de vueltas, herramientas de escritura bajo aprobación humana y conversación persistida con llamadas y resultados para auditoría. Sin esas condiciones de parada, un bucle agéntico se convierte en una factura abierta. [51]

Persistir la conversación y mostrar qué se aprobará

La pausa por aprobación sólo funciona si la conversación del agente queda persistida. De otro modo no hay dónde retomar después. El SDK citado persiste conversaciones de agente en tablas creadas por migración, y esa persistencia es la base de cualquier flujo con aprobación humana. [133]

La instalación mostrada en el corpus es esta:

composer require laravel/ai
php artisan vendor:publish --provider="Laravel\Ai\AiServiceProvider"
php artisan migrate

Con eso tienes, entre otras cosas, las tablas donde se guardan las conversaciones. La consecuencia es práctica: puedes pausar una decisión y reanudarla sin perder el hilo. [133]

Cuando el agente pide ejecutar una herramienta de efecto, la interfaz no debe mostrar sólo que “quiere hacer algo”. Debe mostrar el motivo y los argumentos exactos. El corpus lo plantea así:

// Lo que espera decisión: id de la llamada => motivo que dio el agente.
$pending = $conversation->pendingApprovals($run);

// Y sus argumentos, para que la decisión no sea a ciegas.
foreach ($conversation->pendingCalls($run) as $call) {
    // $call['tool'], $call['arguments'], $call['reason']
}

Eso convierte la aprobación en una decisión informada. La persona ve qué va a cambiar, con qué valores y por qué. [89]

Si vas a empezar por una pieza mínima en Laravel, el propio material sugiere una secuencia razonable:

1. Instala el paquete y corre las migraciones para tener persistencia de conversaciones. [133][135]
2. Deja la generación principal como cadena fija si el orden ya lo conoces. [49][87]
3. Persiste el resultado de cada paso para poder inspeccionar y reanudar. [49][53]
4. Reserva un agente para recuperación de fallos, con pocas herramientas de efecto y aprobación humana. [88][89][51]
5. Mide si la salida llega con estructura, citas y huecos declarados, porque esa es la condición para reducir revisión humana. [100]

Hay un límite que conviene respetar al leer el material de apoyo. El corpus sí habla de grafos, enrutado condicional y paralelismo como ideas tomadas del espacio de orquestación, pero también aclara que esa implementación no se adoptó como framework en el sistema descrito. No conviene presentar ese material como si ya fuera una capacidad disponible de la solución actual. [53]