Cada vez escucho más pedidos que empiezan de una manera parecida:
“Necesitamos un agente.”
O:
“Esto lo podríamos resolver con IA.”
Es entendible. Los LLMs y los agentes abrieron posibilidades que hace pocos años eran difíciles de imaginar, y hoy podemos automatizar tareas que antes requerían necesariamente la intervención de una persona.
Pero hay un riesgo en empezar la conversación por la tecnología.
Muchas veces, después de entender el proceso, descubrimos que no necesitábamos un agente. Necesitábamos una integración entre dos sistemas, una regla de negocio mejor definida, un proceso más claro o, simplemente, un desarrollo tradicional.
La pregunta interesante entonces deja de ser:
¿Cómo podemos resolver esto con IA?
Y pasa a ser:
¿Cuál es el problema que realmente estamos tratando de resolver?
Muchas veces el pedido ya viene con la solución incluida
Esto no empezó con la inteligencia artificial.
Durante años escuchamos pedidos como:
“Necesitamos un dashboard.”
“Necesitamos cambiar el sistema.”
“Necesitamos automatizar este proceso.”
“Necesitamos una nueva aplicación.”
Ahora simplemente agregamos uno nuevo:
“Necesitamos un agente.”
No hay nada malo en que un stakeholder llegue con una solución propuesta. Quien trabaja todos los días sobre un proceso probablemente conoce aspectos del problema mucho mejor que Tecnología y, en muchos casos, su propuesta puede ser correcta.
El error sería tomar esa primera solución como una especificación y empezar a construir.
Cuando alguien me plantea una necesidad, las primeras preguntas que intento hacer son mucho más básicas:
¿Cuál es el problema?
¿Qué resultado esperamos obtener?
A partir de ahí empieza una conversación.
¿Qué ocurre hoy? ¿Dónde está el dolor? ¿Cuánto trabajo genera? ¿Quién interviene? ¿Qué excepciones existen? ¿Qué información necesita una persona para tomar una decisión?
Muchas veces, mientras respondemos esas preguntas, la solución original empieza a transformarse sola.
Antes de elegir la tecnología, entender el sistema
Me resulta útil ordenar esa conversación en cinco pasos:
1. Problema
¿Qué está ocurriendo realmente?
Este punto debería explicarlo principalmente quien vive el proceso todos los días. Tecnología pregunta, escucha y trata de separar el problema de la solución propuesta.
No qué sistema queremos construir.
No qué tecnología queremos incorporar.
Qué problema existe.
2. Resultado
¿Qué tendría que ser diferente cuando terminemos?
Acá negocio y tecnología deberían acordar un resultado observable: reducir tiempos, disminuir errores, eliminar tareas repetitivas, mejorar conversión, bajar costos, controlar riesgo o permitir crecer.
El resultado debería poder explicarse independientemente de la tecnología.
3. Dolor
¿Dónde se genera realmente el costo, la demora o la fricción?
Conviene recorrer el proceso con quienes lo ejecutan, porque el dolor visible no siempre está donde se origina el problema.
Un equipo puede pedir automatizar la carga manual de información en un sistema, por ejemplo. Pero al recorrer el proceso podemos descubrir que la carga existe porque otro sistema genera información incompleta.
Automatizar la carga atacaría el dolor.
Corregir el origen de la información atacaría el problema.
4. Restricciones
¿Qué cosas no podemos simplificar?
Regulación, seguridad, privacidad, decisiones humanas, sistemas existentes, reglas del negocio o integraciones con terceros.
Negocio aporta las restricciones del dominio. Tecnología ayuda a separar cuáles son realmente inherentes al problema y cuáles son consecuencia de decisiones anteriores.
5. Solución
Recién entonces tecnología debería plantear alternativas.
Y hay una pregunta que me gusta utilizar:
¿Cuál es la solución más simple que satisface todo lo anterior?
Puede ser IA.
Pero también puede ser una API, una regla, un formulario, una automatización tradicional, un cambio de proceso o incluso decidir no construir nada.
No hace falta convertir estos cinco pasos en un proceso burocrático. Muchas veces alcanzan treinta minutos frente a una pizarra con las personas correctas.
El valor no está en completar un framework.
Está en postergar la elección de la tecnología hasta haber entendido el problema.
¿Para qué necesitamos que razone?
Esto se volvió especialmente relevante con la aparición de los agentes.
Imaginemos un proceso operativo habitual.
Una persona consulta información en un sistema, verifica cinco condiciones perfectamente definidas, toma un valor y lo carga en otro sistema.
Podríamos construir un agente para hacerlo.
Pero hay una pregunta previa:
¿Para qué necesitamos que razone?
Si las entradas están estructuradas, las cinco reglas son conocidas y frente a las mismas condiciones esperamos siempre el mismo resultado, probablemente estemos frente a un problema determinístico.
Quizás necesitamos una integración y cinco reglas.
No un agente.
Y la diferencia es concreta.
Un agente implica llamadas al modelo, evaluación de respuestas, observabilidad, manejo del no determinismo y nuevos modos de falla.
Una integración con cinco reglas podría resolverse, en un caso sencillo, con poco desarrollo y tests unitarios completamente reproducibles.
Eso no hace que la segunda solución sea menos tecnológica.
La hace más adecuada al problema.
Determinístico no significa necesariamente hardcodeado
Hay otro matiz importante.
Que hoy podamos expresar un proceso mediante cinco reglas no significa que esas reglas sean estables.
Quizás cambian todos los meses.
Quizás negocio necesita modificarlas sin esperar un deployment.
Eso tampoco significa automáticamente que necesitemos un agente.
Puede significar que necesitamos configuración.
Las reglas pueden vivir fuera del código, ser versionadas, auditadas y modificadas por quienes corresponda.
Entonces aparecen tres problemas diferentes:
- reglas conocidas y estables → lógica determinística;
- reglas conocidas pero cambiantes → configuración;
- decisiones donde el camino depende del contexto, información ambigua o razonamiento → ahí un LLM o un agente empieza a ser mucho más interesante.
La arquitectura debería responder a la naturaleza del problema, no a la herramienta que queremos utilizar.
La solución más sofisticada no es necesariamente la más inteligente
Anthropic propone en Building Effective Agents empezar por la solución más simple posible e incrementar la complejidad cuando sea necesario. También señala un trade-off importante: los sistemas agénticos pueden mejorar el desempeño de determinadas tareas a cambio de mayor costo y latencia.
Microsoft describe, por su parte, distintos puntos de un espectro entre agentes que deciden dinámicamente y workflows cuyo comportamiento está controlado de manera determinística.
No existe una única arquitectura correcta.
Si necesitamos interpretar lenguaje no estructurado, comprender contexto, trabajar con información ambigua, elegir herramientas dinámicamente o resolver situaciones cuyo camino no podemos definir de antemano, un LLM puede aportar muchísimo valor.
Pero si tenemos:
Si A y B ocurren → ejecutar C
escribir exactamente eso puede ser una solución extraordinariamente buena.
Usar una tecnología más sofisticada no convierte automáticamente una solución en más inteligente.
La simpleza también tiene una arquitectura
Decir “hagamos lo más simple” no significa elegir siempre la solución más pequeña.
Una solución simple debería seguir siendo segura, observable, mantenible y capaz de responder a las necesidades reales del negocio.
Pero debería evitar complejidad que no necesitamos.
En 1986, Frederick Brooks planteó en No Silver Bullet una distinción que cuarenta años después sigue siendo útil: en software existe complejidad esencial, inherente al problema que intentamos resolver, y complejidad accidental, introducida por las herramientas y mecanismos que utilizamos para resolverlo.
Es una distinción particularmente interesante hoy.
Tenemos herramientas extraordinariamente poderosas.
Y justamente por eso tenemos muchas más oportunidades de agregar complejidad accidental.
Hay problemas que son genuinamente complejos
El otro error sería llevar la simpleza demasiado lejos.
Simple no significa simplista.
Trabajando con problemas relacionados con salud esto se vuelve muy evidente.
Desde afuera, un proceso puede parecer innecesariamente complejo. Después empezamos a entenderlo.
Hay regulaciones. Privacidad. Trazabilidad. Diferentes actores. Sistemas que deben interoperar. Excepciones clínicas. Requerimientos de auditoría. Información que no puede ser tratada de cualquier manera.
Podemos intentar simplificar la solución tecnológica.
Pero no podemos hacer desaparecer la complejidad del dominio simplemente porque nos incomoda.
No se trata de eliminar toda la complejidad. Se trata de eliminar la complejidad que nosotros agregamos innecesariamente.
Si el problema es complejo, la solución probablemente tendrá que representar parte de esa complejidad.
Lo que no necesitamos es agregar otra capa encima solo porque una tecnología está de moda.
Escuchar es parte del trabajo tecnológico
Una parte importante del trabajo de un líder de tecnología ocurre antes de discutir arquitectura.
Ocurre escuchando.
Un stakeholder puede decir:
“Necesito automatizar esto.”
Nuestra responsabilidad no debería ser responder inmediatamente con un diagrama.
Deberíamos entender qué hace hoy, por qué lo hace, qué información utiliza, dónde pierde tiempo, qué errores aparecen y qué resultado necesita conseguir.
Y hay algo importante en esto:
Tecnología no necesariamente conoce mejor el problema.
La persona que trabaja todos los días con un proceso tiene conocimiento que nosotros no tenemos.
Nuestro aporte está en combinar ese conocimiento del negocio con nuestra capacidad de mirar el sistema desde otro lugar.
El mejor resultado no aparece cuando Tecnología impone una solución.
Aparece cuando negocio y tecnología entienden juntos el problema.
Pero preguntar también tiene un costo
También podemos equivocarnos en la dirección contraria.
Podemos pasar semanas intentando comprender perfectamente un problema antes de construir absolutamente nada.
Eso tampoco siempre tiene sentido.
Hay situaciones en las que el stakeholder no puede explicar completamente lo que necesita hasta que ve algo funcionando.
En esos casos, un prototipo de dos días puede enseñarnos más que dos semanas de reuniones.
El discovery no debería convertirse en parálisis.
El objetivo no es entender absolutamente todo antes de movernos.
Es entender lo suficiente como para que construir sea la siguiente forma más barata de aprender.
A veces hay que preguntar.
A veces hay que modelar el proceso.
Y a veces hay que construir algo pequeño, ponerlo frente al usuario y seguir aprendiendo desde ahí.
La IA hace que esta conversación sea todavía más necesaria
Paradójicamente, cuanto mejores sean nuestras herramientas, más importante será esta discusión.
Hoy podemos construir software mucho más rápido.
Podemos generar código, integrar sistemas, procesar documentos, interpretar lenguaje y crear agentes capaces de utilizar herramientas.
Eso reduce muchísimo el costo de construir algunas soluciones.
Pero no reduce automáticamente el costo de construir la solución equivocada.
Incluso puede acelerarlo.
Podemos pasar meses construyendo algo incorrecto. O podemos construirlo incorrectamente en tres días.
La velocidad cambió.
La necesidad de entender el problema, no.
Primero el problema. Después la tecnología.
Me encanta la tecnología.
Justamente por eso intento no empezar por ella.
El valor de una tecnología no está en cuán sofisticada sea, sino en qué problema nos permite resolver y a qué costo.
Un agente puede ser la solución correcta.
Un modelo de IA también.
Pero una API, una regla de negocio o un desarrollo de veinte líneas pueden ser una decisión tecnológica igual de buena —o mejor—.
Y algunas veces, después de entender realmente el proceso, podemos descubrir que el problema ni siquiera necesitaba software.
Por eso, cuando alguien llega diciendo:
“Necesitamos un agente.”
mi primera pregunta seguiría siendo:
“¿Qué problema queremos resolver?”
Y después de entender el problema, el resultado esperado, los dolores y las restricciones, agregaría una más:
“¿Cuál es la forma más simple de resolverlo bien?”
Para mí, ahí empieza una buena decisión tecnológica.
No cuando elegimos la herramienta.
Cuando entendemos el problema.
Fuentes y lecturas
- Anthropic — Building Effective Agents — diciembre de 2024.
- Microsoft Agent Framework — Workflows.
- Microsoft — Map agent flows to requirements.
- Frederick P. Brooks Jr. — No Silver Bullet: Essence and Accident in Software Engineering — IEEE Computer, 1986.