cloud / sistemas
El primer artículo planteaba si conviene esperar o empezar otro tema. Este ejemplo mantiene un registro local del próximo intervalo en el que podría necesitarse atención.
No predice automáticamente la duración. Tú o tu agente comunicáis un estado y, cuando exista fundamento, un intervalo aproximado. El indicador hace visible esa información y señala cuándo caduca.
1. Probarlo por separado
Necesitas Python 3 en macOS o Linux. Compruébalo con python3 --version. Descarga e inspecciona agent-eta.py, guárdalo en un directorio temporal y ejecuta allí los comandos. No requiere paquetes adicionales ni cambios en Claude Code.
Usa una ruta JSON distinta por tarea. Varios agentes no deben escribir en el mismo archivo. El directorio padre debe existir.
python3 agent-eta.py --file ./eta-demo.json write --state working --phase verification --min 5 --max 12
python3 agent-eta.py --file ./eta-demo.json showLa salida inicial será aproximadamente:
verification | WORKING | rough next-attention window 5-12m | declared, not calibratedLos cinco a doce minutos son datos inventados para la demostración, no un benchmark ni una garantía. Describen cuándo podría necesitarse atención, no cuándo estará terminada una solución.
2. No inventar los tiempos desconocidos
Si no puedes justificar un intervalo, comunica solo el estado:
python3 agent-eta.py --file ./eta-demo.json write --state working --phase researchAparecerá next attention window unknown. Una estimación ausente no se convierte en cero. Si hay intervalo, se descuenta el tiempo transcurrido. Al superar el límite superior, aparece declared window expired; refresh needed.
3. Comunicar necesidades reales de atención
python3 agent-eta.py --file ./eta-demo.json write --state needs-input --phase implementation
python3 agent-eta.py --file ./eta-demo.json write --state waiting --phase external
python3 agent-eta.py --file ./eta-demo.json write --state ready --phase reviewEjecuta cada comando cuando ocurra la transición correspondiente; no son una secuencia para ejecutar sin pensar. INPUT NEEDED tiene prioridad sobre el intervalo. READY FOR REVIEW no afirma que las pruebas hayan pasado. Una espera externa sin intervalo sigue siendo desconocida.
El script no detecta permisos ni resultados de pruebas. El registro depende de la veracidad y actualidad de quien lo escribe.
4. Incorporar actualizaciones explícitas
En el primer ensayo, actualiza el archivo manualmente al cambiar de fase. Después puedes indicar a un agente que use el script revisado y su propio archivo, que actualice antes de pedir información y al terminar, y que omita intervalos sin fundamento.
Es una instrucción de trabajo, no una integración automática verificada con Claude Code. Un adaptador para status line o hooks sería un paso posterior. show imprime una instantánea; no crea un panel que se actualice solo.
Comprueba si te ayuda a elegir una actividad para el hueco. La cifra no garantiza ausencia de interrupciones: una pregunta puede aparecer antes.
5. Verificar límites y limpiar
El código se probó con relojes e inputs sintéticos: archivos ausentes o malformados, intervalos desconocidos o vencidos, atención requerida, rangos inválidos y cambios de reloj. Un registro de más de 24 horas se marca como obsoleto. No se ha medido precisión predictiva en tareas reales.
Solo guarda nombres fijos de estado y fase, la hora y el intervalo declarado. No hace llamadas de red ni captura prompts o historial. Las actualizaciones sobrescriben el archivo; no se borra automáticamente. Elimina eta-demo.json con el gestor de archivos al terminar. Quitar el script y ese archivo revierte el ejemplo; no hay ajustes del agente que restaurar.
La calibración histórica requiere tareas comparables terminadas. Hasta entonces, un intervalo declarado con caducidad visible es más honesto que una cifra exacta sin evidencia.