Workflow de Missão de Resgate
O ciclo estruturado de diagnóstico-correção-retomada para recuperar agentes travados e transformar falhas em contexto reutilizável.
Visão Geral
Uma Rescue Mission é o processo estruturado para recuperar um agente que travou — entrando em loop no mesmo erro, interpretando incorretamente uma especificação, violando restrições arquitetônicas ou esgotando seu Token Budget sem produzir uma saída utilizável. Em vez de tratar agentes travados como emergências ad-hoc, este padrão define um ciclo repetível de três etapas: Diagnosticar a causa raiz, Injetar contexto corretivo e Retomar a execução. Após cada resgate, uma etapa de feedback enriquece o Context Index para que o mesmo bloqueador não volte a ocorrer.
As missões de resgate situam-se na Fase 4 da Escada de Escala de Quatro Fases — elas são ativadas após as tentativas automáticas (Fase 1), ajustes de parâmetros (Fase 2) e a pausa da Blocker Flag (Fase 3) terem falhado em resolver o problema. O Agent Operator que monitora o agente sinaliza o problema. O Daily Flow Sync faz a triagem. E um engenheiro designado — geralmente o próprio Agent Operator ou um engenheiro sênior — executa o resgate.
O valor deste padrão se acumula com o tempo. Cada missão de resgate produz um diagnóstico documentado e uma atualização de contexto. Após alguns meses, o Context Index cobre os modos de falha que a equipe encontrou, e a frequência de resgates diminui. Equipes que monitoram o Mean Time To Unblock (MTTU) geralmente veem uma redução de 40-60% no primeiro trimestre de adoção deste workflow.
Problema
Os agentes travam por razões previsíveis, mas as equipes sem um workflow de resgate estruturado lidam mal com essas situações:
-
Correções ad-hoc que não persistem. Um engenheiro desbloqueia o agente com um ajuste rápido de prompt ou edição manual de código. A correção funciona uma vez, mas a causa subjacente — um arquivo de contexto ausente, uma seção de especificação ambígua, uma restrição não capturada na System Constitution — permanece. O próximo agente que encontrar a mesma situação travará novamente.
-
Sem análise de causa raiz. Sem uma etapa de diagnóstico, as equipes tratam os sintomas. Elas veem que "o agente produziu um SQL incorreto" e concluem que "o agente é ruim em SQL". A causa raiz real pode ser que o contexto do esquema do banco de dados não foi incluído no Context Packet, ou que a especificação não definiu qual ORM usar.
-
Escala inconsistente. Alguns engenheiros deixam os agentes rodando por horas antes de intervir. Outros encerram o agente ao primeiro sinal de problema e fazem o trabalho sozinhos. Sem um processo de escala definido, a equipe oscila entre desperdiçar tokens e desperdiçar tempo humano.
-
O conhecimento fica na cabeça das pessoas. O engenheiro que resgatou o agente sabe o que deu errado e como consertar. Esse conhecimento vive na memória deles, não no Context Index. Quando eles ficam doentes ou saem da equipe, o conhecimento vai embora com eles.
-
Sem visibilidade dos padrões de falha. Sem rastrear as missões de resgate, a equipe não consegue identificar problemas sistêmicos. Se 60% dos resgates são causados por especificações incompletas, a equipe deveria investir em uma melhor engenharia de especificações — mas eles não sabem disso sem dados.
Solução
Implemente o Workflow de Missão de Resgate como um processo de cinco etapas que cada membro da equipe segue quando um agente atinge a Fase 4 da escada de escala.
As Cinco Etapas
- Detectar — Identificar que o agente está travado por meio do Agentops Dashboard ou observação manual. Levantar uma Blocker Flag.
- Diagnosticar — Determinar a categoria da causa raiz. O diagnóstico direciona a correção.
- Injetar — Fornecer o contexto corretivo específico que o agente necessita.
- Retomar — Reiniciar a execução do agente com o contexto corrigido.
- Enriquecer — Atualizar o Context Index para evitar a recorrência.
Todo o ciclo deve levar de 15 a 45 minutos para uma equipe treinada. Se o diagnóstico demorar consistentemente mais tempo, as ferramentas de monitoramento e diagnóstico precisam de melhorias.
Implementação
Exemplos 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;
}Considerações
- • **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.