Agente multi-herramienta para ingeniería eléctrica

Dia 30 / 60

Estos son los dias en que empiezo a sentir que tengo algo.

Darle herramientas a un LLM me esta mostrando cosas que esperaba que pasaran pero no tan bien. No es perfecto, el agente todavia alucina, todavia falla en formas absurdas, pero hay momentos donde hace exactamente lo que haria un ingeniero: analiza, decide, ejecuta, ajusta. Y lo hace solo.

Creo que esto es gracias a Gemini 3. El modelo se siente que tiene capacidades reales para usar herramientas, pero tambien limites claros que estoy aprendiendo a navegar. No es perfecto, pero se siente muy avanzado. Yo personalmente lo siento como progreso real.

Este proyecto es un experimento: que tan lejos puede llegar un agente autonomo enfrentado a una herramienta real, con errores, estados intermedios, decisiones tecnicas y uso de criterios que normalmente toma un ingeniero electrico.

Me impuse construir un agente capaz de realizar estudios de coordinacion de protecciones en 60 dias, y ya llevo 30 dias trabajando en esto.

Es un buen momento para detenerme y pensar:

• que he estado haciendo,
• que me falta,
• y que alcanzo a priorizar primero desde ahora hasta el 9 de febrero, cuando termina el hackathon de Gemini, y luego avanzar lo maximo posible hasta el 20 de febrero, que es mi plazo autoimpuesto.

Cosas que he estado haciendo bien y que deberia mantener

Escribir. Extrañamente (o no tanto), crear contenido ha sido una de las cosas que mas me han gustado del proceso. De hecho, tengo 4 entradas de blog pendientes de publicar, no he publicado porque no he tenido tiempo de ordenarlas y lanzarlas. El documentar igual me obliga a avanzar para documentar algo.

Entender mejor el problema. No habia tenido antes la oportunidad de hacer mucha coordinacion de protecciones en la practica. Eso me obligo a meterme de lleno en teoria, normas y criterios reales. Pronto voy a publicar un post dedicado exclusivamente a todo lo que he aprendido sobre coordinacion de protecciones, porque ha sido bastante mas profundo de lo que esperaba.

Como va el agente

He pasado casi el 100% del tiempo mejorando la tool de DIgSILENT PowerFactory. Pense que esto me iba a tomar bastante menos tiempo, pero cada dia que la mejoro se vuelve mas evidente como el agente empieza a hacer, por si solo, cosas cada vez mejores, utilizando las herramientas de simulacion que tengo disponibles.

Al principio me enfoque en lo basico:

• correr flujos de potencia,
• ejecutar cortocircuitos simples.

Pero a medida que fui entendiendo mejor el problema real, me di cuenta de que me faltaban muchisimas funciones que no habia considerado al inicio.

Ademas, me tome un par de dias completos para lograr correr multiples instancias de DIgSILENT en paralelo. La idea es simple: si el mismo agente puede simular en paralelo, el tiempo total de simulacion y analisis se puede reducir de forma sustancial.

Multiples instancias de DIgSILENT corriendo en paralelo

Agregue un lugar donde poder ver las tools que el agente decide tomar cada vez. No simplemente para ver las tools que tomo si no que espero tener tiempo para usar mi capacidad como ingeniero electrico y evaluar si el uso de las herramientas fue el adecuado y con eso retroalimentar al agente para que las proximas veces use las tools en un camino correcto.

Algo importante: yo no le digo que hacer ni como hacerlo. Solo le paso las herramientas y como usarlas.

En un caso simple —como ejecutar un cortocircuito— el agente decide, de manera bastante obvia, llamar a la tool correspondiente para hacer el corto circuito.

Flujo del agente ejecutando un cortocircuito

No todo es perfecto, obviamente. Por ejemplo, en un caso le pregunte que protecciones tenia el sistema. La respuesta fue correcta, pero internamente llamo una tool de forma incorrecta (No existe una tool para listar los reles, pero si existe otra tool para obtener la configuracion de los reles.)

Flujo del agente obteniendo protecciones

Aun asi, cuando le pido tareas largas —como literalmente realizar un estudio de coordinacion de protecciones completo— es cuando el agente empieza a sorprenderme de verdad.

Un ejemplo concreto

En uno de los tests no le pedi algo simple. El prompt fue deliberadamente complejo:

• realizar un estudio completo,
• prender y apagar generadores,
• ejecutar multiples simulaciones,
• ajustar reles,
• devolver tablas e imagenes como resultado.

Lo interesante de ese experimento fue lo siguiente:

• Corrio durante 9,6 minutos
• Utilizo 37 tools
• Ejecuto 46 pasos considerando razonamiento + acciones
• La respuesta no fue perfecta, pero logro coordinar los reles que efectivamente habia que coordinar
• El tiempo total de uso efectivo de tools fue de 7,1 minutos

Flujo completo del agente realizando un ECAP

Cuando vi ese numero (7,1 minutos de uso real de tools) fue cuando agradeci haber invertido tiempo en permitir multiples maquinas corriendo DIgSILENT en paralelo. Si agrego otra maquina mas, podria reducir ese tiempo practicamente a la mitad.

Cosas que todavia no estan bien

No todo ha me ha funcionado, he tenido problemas con lo siguiente:

Alucinaciones en la creacion de imagenes y en uso de herramientas. El agente suele fallar al generar imagenes. Si le pido 2, a veces no genera ninguna o solo una; si le pido 6, igualmente termina devolviendo una. Todavia no tengo claro si esto se debe a una ventana de contexto demasiado corta, a un prompt mal planteado, o derechamente a una mala definicion de la tool asociada a la generacion de imagenes.

Un par de veces he visto que usa tools con argumentos que no deberia.

Escalabilidad a sistemas grandes. Me preocupa como se va a comportar este enfoque en sistemas reales de gran tamano. Por ejemplo, el sistema del CEN tiene mas de 2.500 barras, y los estudios de coordinacion ahi no solo crecen en tamano, sino tambien en complejidad operativa y combinatoria. Aun no esta claro si el enfoque actual escala de forma razonable.

Memoria demasiado simple. El agente tiene, por ahora, un sistema de memoria muy basico. Funciona para tareas acotadas, pero no es evidente si es suficiente para estudios largos, iterativos y con multiples decisiones intermedias. Todavia estoy evaluando si vale la pena complejizar este componente o si el problema se puede resolver mejor a nivel de planificacion y estado. Le estoy pasando las ultimas respuestas, literalmente la peor opcion posible. No ha colapsado por que Gemini 3, tiene 1 millon de tokens en el contexto, lo que me permite hacer este tipo de experimentos, pero tengo que trabajar en esto.

Un cuello de botella que no esperaba

Hay algo que no he mencionado y que probablemente explica algunas de las alucinaciones: el agente tiene 21 herramientas disponibles.

Analisis de Red: PowerFlowTool (Flujo de potencia), ShortCircuitTool (Cortocircuito)

Gestion de Elementos: ListElementsTool, ElementControlTool (abrir/cerrar), ModifyTransformerTool

Transformadores de Instrumento: AddCurrentTransformerTool, AddVoltageTransformerTool, ListInstrumentTransformersTool

Reles de Proteccion: AddOvercurrentRelayTool, AddDirectionalOCRelayTool, AddDistanceRelayTool, ModifyDistanceRelayTool, AddDifferentialRelayTool, AddVoltageRelayTool, AddFrequencyRelayTool

Configuracion de Reles: GetRelaySettingsTool, ModifyRelaySettingsTool

Lineas de Transmision: GetLineParametersTool, AnalyzeDistanceReachTool

Visualizacion: GenerateTccPlotTool, GenerateRxPlotTool

En teoria, los LLMs modernos pueden manejar muchas tools. En la practica, el numero real es menor. Por lo que he visto experimentando, Gemini 3 se comporta bien con algo entre 15 y 20 herramientas — y yo estoy justo en el borde.

Las 21 tools cubren todo lo que necesita un estudio ECAP: analisis de red (flujos de potencia, cortocircuitos), gestion de elementos, transformadores de instrumento, distintos tipos de reles de proteccion, configuracion de ajustes, parametros de lineas y visualizacion de curvas TCC y diagramas R-X.

El problema es que cuando el agente tiene demasiadas opciones, a veces elige mal. O peor: inventa una que no existe. Esto podria explicar por que a veces falla en tareas que deberian ser simples.

La solucion probable: un sistema multiagente. En vez de un agente que lo sabe todo, tener agentes especializados — uno para simulaciones, otro para protecciones, otro para visualizacion — que se coordinen entre si. Es mas complejo de implementar, pero probablemente mas robusto.

Por ahora sigo con los 21 tools y observo donde falla. Pero es algo que voy a tener que resolver si quiero escalar a sistemas mas grandes.

Reflexion final

¿Voy a llegar? Creo que si.

Siempre he funcionado asi: los ultimos dias antes del plazo son donde mas avanzo. Ya vengo con buen ritmo y deberia ir en aumento. Planeo escribir mas, documentar mas — no solo porque sirve para el proyecto, sino porque me motiva a seguir avanzando.

Cada vez noto mas claro que una de las metas actuales de los developers es lograr flujos que puedan correr por largos periodos de tiempo y lograr la coordinacion de muchos agentes trabajando para un humano. Creo que una habilidad clave en 2025 va a ser aprender a delegarle tareas a los agentes. Programar cada vez se siente menos programar y mas delegar.