Ansiedad de tokens y el harness v1.0 de Don Nelson

Dia 14 / 60

Nueva semana en el desafio de Don Nelson: un estudio aprobado por el CEN.

La semana pasada no avance mucho tecnicamente. Y creo que eso es lo mas importante que tengo para contar hoy.

Ansiedad de tokens y psicosis de IA

La semana pasada no avance mucho.

Soy trabajolico, eso no es nuevo. Pero desde que trabajo con agentes de IA hay algo distinto: la sensacion de que siempre puedes hacer mas, que si no estas corriendo experimentos o quemando tokens estas desperdiciando potencial. El modelo siempre esta disponible. No hay excusa para parar.

Resulta que Andrej Karpathy le puso nombre a esto hace unos dias en el podcast No Priors: "me pongo nervioso cuando me sobra suscripcion". Lo llamo ansiedad de tokens. Yo lo habia estado viviendo sin saber como describirlo.

Decidi bajar el ritmo conscientemente. No porque no hubiera cosas que hacer — siempre tengo — sino porque me estaba pasando la cuenta. Creo que es importante decirlo en este blog, que es sobre construir en publico: la IA amplifica tu capacidad de hacer, pero si no administras eso, te amplifica tambien el burnout.

El descansar me ayudo a pensar y descurir lo siguiente, el cuello de botella ya no es escribir codigo. Es saber dirigir bien. Karpathy lo llama "skill issue" — el que puede descomponer tareas con precision y revisar outputs eficientemente gana, independiente de su habilidad tecnica pura. Eso me parece tanto una oportunidad como una responsabilidad nueva.

El episodio de No Priors con Karpathy, si quieres escucharlo:

• Andrej Karpathy on token anxiety
• Post en X

En que esta Don Nelson

A pesar de la semana mas relax, el universo me ayudo a desbloquear las dos cosas que mas me estaban bloqueando.

Tengo un caso de estudio real. Una carta escenario concreta que pide un estudio de flujo de potencia y un estudio de capacidad de barra.

Tengo acceso a dos licencias de DIgSILENT. Una de red y una comercial sin limite de barras, lo que significa que ya puedo correr flujos de potencia como corresponde, sin las restricciones que me frenaban antes.

Ahora depende solo de mi avanzar.

El Harness de Don Nelson v1.0

(Es realmente la v1.0? Tecnicamente nunca llego a produccion

En el post del Dia 4 hable del concepto de harness en general. Hoy quiero hablar del harness actual de Nelson — como esta construido y por que estaba asi.

Harness de Don Nelson v1.0

1. Entradas y salidas

Nelson no vive en una sola interfaz. Tiene un gateway que recibe mensajes desde Microsoft Teams o desde el frontend web, los normaliza, y los entrega al agente. La respuesta vuelve por el mismo camino. El agente nunca sabe si le hablo un usuario en Teams o alguien en el browser.

2. Orquestacion del pensamiento

Nelson tiene un router de 3 velocidades:

• Directo (~1 segundo): Para preguntas simples, saludos, meta-preguntas. Sin herramientas.
• ReAct (~5-15 segundos): Un loop donde el agente razona, elige una herramienta, la ejecuta, ve el resultado, y decide si necesita hacer algo mas.
• Plan-Execute (~20-60 segundos): Para tareas complejas. El agente primero genera un plan con tareas, y luego un executor las va resolviendo una por una — o en paralelo si hay VMs disponibles.

El clasificador es un sistema de dos fases: primero heuristicas (si el mensaje dice "hola", va directo), luego el modelo evalua la complejidad si las heuristicas no matchean.

Para estudios electricos, casi todo cae en Plan-Execute. El agente descompone "analiza la S/E Codegua" en 5-10 subtareas, cada una con sus herramientas especificas.

3. Manejo del contexto

El modelo tiene un limite de contexto. No puedo meterle las 58 herramientas con sus descripciones, mas el historial de conversacion, mas las instrucciones de cada tipo de analisis. No cabe — y aunque cupiera, el modelo se confunde.

Entonces el harness filtra. Cuando el executor recibe una tarea:

• Detecta que skills son relevantes (por keywords en el mensaje)
• Inyecta solo esos prompts especificos
• Filtra las herramientas de 58 a ~10-15 por tarea
• Trunca el historial de conversacion para evitar context bloat

Cada skill es un modulo con su propio system prompt. El de DIgSILENT Core le dice al agente como correr flujos de potencia. El de protecciones le explica que reles existen. El de reportes le ensena a generar PDFs.

La analogia: es como darle a un ingeniero junior solo los manuales que necesita para la tarea del dia, en vez de todo el estante de normas a la vez.

4. Persistencia del estado

Si Nelson desactiva una linea de transmision para simular una contingencia, el siguiente flujo de potencia tiene que ver esa linea desactivada. Pero el archivo .pfd se descarga de nuevo cada vez.

La solucion: un sistema de "overrides" en Firestore. Cada vez que Nelson modifica un elemento — desactiva una linea, cambia el tap de un transformador, ajusta la potencia de un generador — eso queda registrado. Cuando la siguiente herramienta se ejecuta, le pasa esos overrides al backend Python, que los aplica antes de correr cualquier calculo.

Es como una capa de estado que vive encima del modelo de PowerFactory. No es elegante, pero funciona.

5. Manejo de recursos

Nelson tiene un pool de VMs en Google Cloud, cada una con PowerFactory instalado y un backend Python que expone una API REST.

El harness maneja esto con un sistema de reservacion en Firestore:

• Antes de ejecutar una herramienta que necesita PowerFactory, el sistema busca una VM disponible
• Le hace un health check (estas viva?)
• La reserva con una transaccion atomica — para evitar race conditions si dos tareas piden VM al mismo tiempo
• Cuando la herramienta termina, la libera

En Plan-Execute, puedo pre-asignar una VM a todo el plan para que las tareas no compitan entre si. O asignar una VM por tarea para que corran en paralelo.

6. Herramientas

Nelson tiene 58 herramientas. 40 requieren DIgSILENT PowerFactory corriendo en una VM. Las otras 18 consultan datos del SEN, generan reportes o envian emails.

Cada herramienta sigue el mismo patron:

1. El modelo decide que herramienta llamar y con que parametros
2. La herramienta crea un "job" en Firestore con status pending
3. Reserva una VM disponible del pool
4. Envia un HTTP POST al backend Python corriendo en esa VM
5. El backend abre el archivo .pfd en PowerFactory, ejecuta la operacion, y guarda el resultado en Firestore
6. La herramienta hace polling cada 1-2 segundos hasta que el job cambia a completed o failed
7. Retorna el resultado al agente

Detalle importante: el modelo a veces alucina nombres de herramientas — llama power_flow en vez de run_power_flow. Para eso tengo un sistema de aliases, un diccionario que corrige los nombres mas comunes antes de que el sistema falle.

7. Ciclo de retroalimentacion

Cada paso que Nelson da queda registrado como un IterationStep en Firestore. El frontend muestra esto en tiempo real — puedes ver el razonamiento del agente, que herramientas eligio, que resultados obtuvo, y cuanto costo en tokens.

Esto no es solo para debugging. Es lo que le permite al ingeniero supervisar al agente y decidir si confia en los resultados.

Lo que viene

Ahora que tengo acceso a una licencia de DIgSILENT sin limites voy a cambiar la arquitectura de VMs. En vez de tener 5 maquinas corriendo en paralelo, voy a consolidar en una sola VM mas grande y capaz. Voy a comparar rendimiento entre la maquina actual, una mediana y una grande para encontrar el punto optimo.

Y lo mas importante: voy a refactorizar el harness. Hacerlo mas modular, mas simple. La semana de descanso me sirvio para ver con claridad que sobra y que falta. La simplicidad es dificil, pero es la unica forma de que esto escale.

Ahora empieza a darle en serio para lograr que Don Nelson presente un estudio en 46 dias.