Flujo de Trabajo de Misión de Rescate
El ciclo estructurado de diagnóstico-corrección-reanudación para recuperar agentes estancados y convertir fallos en contexto reutilizable.
Resumen
Una Rescue Mission es el proceso estructurado para recuperar un agente que se ha quedado estancado — ciclando en el mismo error, malinterpretando una especificación, violando restricciones arquitectónicas o agotando su Token Budget sin producir un resultado utilizable. En lugar de tratar a los agentes estancados como emergencias ad-hoc, este patrón define un ciclo repetible de tres pasos: Diagnosticar la causa raíz, Inyectar contexto correctivo y Reanudar la ejecución. Después de cada rescate, un paso de retroalimentación enriquece el Context Index para que el mismo bloqueador no vuelva a ocurrir.
Las misiones de rescate se sitúan en la Fase 4 de la Escalera de Escalamiento de Cuatro Fases — se activan después de que los reintentos automáticos (Fase 1), los ajustes de parámetros (Fase 2) y la pausa por Blocker Flag (Fase 3) hayan fallado en resolver el problema. El Agent Operator que monitorea al agente señala el problema. El Daily Flow Sync lo clasifica. Y un ingeniero designado — a menudo el propio Agent Operator o un ingeniero sénior — ejecuta el rescate.
El valor de este patrón se acumula con el tiempo. Cada misión de rescate produce un diagnóstico documentado y una actualización de contexto. Después de varios meses, el Context Index cubre los modos de falla que el equipo ha encontrado, y la frecuencia de rescates disminuye. Los equipos que rastrean el Mean Time To Unblock (MTTU) suelen ver una reducción del 40-60% dentro del primer trimestre tras adoptar este flujo de trabajo.
Problema
Los agentes se estancan por razones predecibles, pero los equipos sin un flujo de trabajo de rescate estructurado manejan estas situaciones de manera deficiente:
-
Soluciones ad-hoc que no persisten. Un ingeniero desbloquea al agente con un ajuste rápido del prompt o una edición manual del código. La solución funciona una vez, pero la causa subyacente — un archivo de contexto faltante, una sección de especificaciones ambigua, una restricción no capturada en la Constitución del Sistema — permanece. El siguiente agente que encuentra la misma situación se estanca de nuevo.
-
Sin análisis de causa raíz. Sin un paso de diagnóstico, los equipos tratan los síntomas. Ven que "el agente produjo un SQL incorrecto" y concluyen que "el agente es malo en SQL". La causa raíz real podría ser que el contexto del esquema de la base de datos no se incluyó en el Context Packet, o que la especificación no indicaba qué ORM usar.
-
Escalamiento inconsistente. Algunos ingenieros dejan que los agentes den vueltas durante horas antes de intervenir. Otros eliminan al agente ante la primera señal de problemas y hacen el trabajo ellos mismos. Sin un proceso de escalamiento definido, el equipo oscila entre desperdiciar tokens y desperdiciar tiempo humano.
-
El conocimiento se queda en la cabeza de las personas. El ingeniero que rescató al agente sabe qué salió mal y cómo solucionarlo. Ese conocimiento vive en su memoria, no en el Context Index. Cuando están enfermos o dejan el equipo, el conocimiento se va con ellos.
-
Sin visibilidad de los patrones de falla. Sin rastrear las misiones de rescate, el equipo no puede identificar problemas sistémicos. Si el 60% de los rescates son causados por especificaciones incompletas, el equipo debería invertir en una mejor ingeniería de especificaciones, pero no lo sabrán sin datos.
Solución
Implemente el Flujo de Trabajo de Misión de Rescate como un proceso de cinco pasos que cada miembro del equipo sigue cuando un agente alcanza la Fase 4 de la escalera de escalamiento.
Los Cinco Pasos
- Detectar — Identificar que el agente está estancado a través del Agentops Dashboard o por observación manual. Levantar un Blocker Flag.
- Diagnosticar — Determinar la categoría de la causa raíz. El diagnóstico impulsa la corrección.
- Inyectar — Proporcionar el contexto correctivo específico que el agente necesita.
- Reanudar — Reiniciar la ejecución del agente con el contexto corregido.
- Enriquecer — Actualizar el Context Index para evitar la recurrencia.
El ciclo completo debería tomar entre 15 y 45 minutos para un equipo capacitado. Si el diagnóstico toma más tiempo de manera consistente, las herramientas de monitoreo y diagnóstico necesitan mejorar.
Implementación
Ejemplos de Código
// scripts/rescue-tracker.ts
interface RescueMission {
id: string;
taskId: string;
detectedAt: Date;
resolvedAt: Date | null;
diagnosis: {
category: string;
evidence: string[];
rootCause: string;
};
injection: {
description: string;
filesAdded: string[];
specChanges: string[];
};
outcome: "resolved" | "re-escalated" | "abandoned";
contextUpdates: string[];
mttu: number | null; // minutes from detection to resolution
}
function calculateMTTU(missions: RescueMission[]): number {
const resolved = missions.filter(
(m) => m.outcome === "resolved" && m.mttu !== null
);
if (resolved.length === 0) return 0;
return resolved.reduce((sum, m) => sum + (m.mttu ?? 0), 0) / resolved.length;
}
function categoryBreakdown(
missions: RescueMission[]
): Record<string, number> {
return missions.reduce(
(acc, m) => {
const cat = m.diagnosis.category;
acc[cat] = (acc[cat] || 0) + 1;
return acc;
},
{} as Record<string, number>
);
}
function generateRescueReport(missions: RescueMission[]): string {
const mttu = calculateMTTU(missions);
const breakdown = categoryBreakdown(missions);
const totalContextUpdates = missions.reduce(
(sum, m) => sum + m.contextUpdates.length,
0
);
return [
`## Rescue Mission Report`,
``,
`**Period:** Last 30 days`,
`**Total Rescues:** ${missions.length}`,
`**Average MTTU:** ${mttu.toFixed(0)} minutes`,
`**Context Updates Generated:** ${totalContextUpdates}`,
``,
`### Root Cause Breakdown`,
...Object.entries(breakdown)
.sort(([, a], [, b]) => b - a)
.map(
([cat, count]) =>
`- ${cat}: ${count} (${((count / missions.length) * 100).toFixed(0)}%)`
),
].join("\n");
}// scripts/detect-blockers.ts
interface AgentSession {
id: string;
taskId: string;
startedAt: Date;
tokenBudget: number;
tokensUsed: number;
retryCount: number;
lastGateResult: "pass" | "fail";
lastError: string | null;
expectedDurationMinutes: number;
}
interface BlockerAlert {
sessionId: string;
taskId: string;
reason: string;
severity: "warning" | "critical";
suggestedAction: string;
}
function detectBlockers(sessions: AgentSession[]): BlockerAlert[] {
const alerts: BlockerAlert[] = [];
const now = new Date();
for (const session of sessions) {
const elapsedMinutes =
(now.getTime() - session.startedAt.getTime()) / 60000;
const budgetPercent = (session.tokensUsed / session.tokenBudget) * 100;
// Check: token budget approaching limit
if (budgetPercent > 80 && session.lastGateResult === "fail") {
alerts.push({
sessionId: session.id,
taskId: session.taskId,
reason: `Token budget at ${budgetPercent.toFixed(0)}% with failing gates`,
severity: "critical",
suggestedAction: "Initiate rescue mission — budget exhaustion likely",
});
}
// Check: excessive retries
if (session.retryCount >= 3) {
alerts.push({
sessionId: session.id,
taskId: session.taskId,
reason: `${session.retryCount} retries with no improvement`,
severity: "critical",
suggestedAction:
"Raise blocker flag — automated retries are not resolving the issue",
});
}
// Check: running longer than expected
if (elapsedMinutes > session.expectedDurationMinutes * 2) {
alerts.push({
sessionId: session.id,
taskId: session.taskId,
reason: `Running ${elapsedMinutes.toFixed(0)}min (expected ${session.expectedDurationMinutes}min)`,
severity: "warning",
suggestedAction:
"Check agent progress — may be stuck or working on out-of-scope items",
});
}
}
return alerts;
}Consideraciones
- • **Faster unblocking.** A structured diagnosis checklist eliminates the guesswork that makes ad-hoc rescues slow. Teams that follow this workflow consistently report [[mean-time-to-unblock]] improvements of 40-60% within three months.
- • **Compound improvement.** Every rescue enriches the [[context-index]]. The first rescue for a given blocker type costs 45 minutes. The fifth rescue for a similar blocker costs 15 minutes because the context already exists. After enough rescues, the blocker category stops occurring entirely.
- • **Systematic knowledge capture.** Rescue injection records and context updates convert individual troubleshooting knowledge into team-level assets. The [[context-index]] grows from rescue missions, not from planned documentation sprints.
- • **Data-driven process improvement.** Tracking rescue frequency by root cause category reveals where the team should invest. If 40% of rescues are caused by ambiguous specs, improving spec quality yields the highest return. Without tracking, the investment decision is a guess.
- • **Reduced recurring failures.** The enrichment step (Step 5) is the key differentiator from ad-hoc fixes. Each rescue addresses the root cause in the [[context-index]], not just the symptom in the current task. Over time, the team encounters fewer novel blockers.
- • **Requires real-time monitoring.** The detection step depends on visibility into agent execution state. Teams without an [[agentops-dashboard]] or equivalent monitoring must rely on manual observation, which delays detection and increases MTTU.
- • **Diagnosis skill takes practice.** The five-category diagnosis framework is straightforward in theory but requires pattern recognition that develops over weeks. Expect diagnosis to take 20-30 minutes initially; it should drop to 5-10 minutes after a dozen rescues.
- • **Balancing speed and thoroughness.** Under deadline pressure, teams skip the enrichment step (Step 5) to save time. This creates technical debt in the [[context-index]] and guarantees the same blocker will recur. The Flow Manager should track enrichment completion rates and flag gaps.
- • **Post-rescue context review burden.** Each rescue generates context updates that should be reviewed like code — incorrect context injections can cause new problems. Include rescue-generated context updates in the weekly Architecture Governance Review.
- • **Requires team discipline.** The workflow only works if every team member follows it consistently. One engineer who bypasses the process and applies quick fixes without enrichment undermines the compound improvement benefit. The [[daily-flow-sync]] should include a brief review of rescue completion status.