Polkan García explica por qué los agentes de IA requieren propósito, contexto, métricas, guardrails y control antes de operar en producción segura
Un agente de IA abre una discusión que va más allá de automatizar tareas con modelos de lenguaje, porque el debate central está en cuándo conviene entregar autonomía, acceso a sistemas externos, memoria operativa y capacidad de decisión a una herramienta que debe completar un flujo real.
En conversación con Pisapapeles, Polkan García, vocero de Oracle, abordó las diferencias entre un chatbot, un copiloto y un agente de IA desde una mirada que cruza arquitectura, costos, consumo de tokens, controles de producción, seguridad, selección de modelos y riesgos de sobreingeniería.
La conversación recapitula, en cierta medida, el debate sobre la sobreingeniería en IA desde otro ángulo: no basta con llamar agente a una automatización si no existe un propósito definido, una métrica de éxito y un marco claro para operar con contexto, restricciones y acceso a herramientas reales.
La conversación deja varios puntos útiles para entender por qué los agentes de IA no deberían evaluarse solo como una nueva interfaz conversacional, sino como una capa operativa que exige diseño, control y criterios de uso claros.
En la definición operativa que plantea García, la diferencia entre chatbot y agente no nace de la interfaz conversacional, sino del propósito que organiza la ejecución y de las restricciones que permiten evaluar si una tarea fue completada correctamente.
“Para explicar qué es un agente de IA, suelo usar la metáfora de las modalidades de transporte en una ciudad. Una persona puede caminar, usar una bicicleta pública, pedir un Uber o manejar su propio automóvil, y desde esa óptica general, un automóvil funciona como un agente porque cumple un propósito concreto: llevarte del punto A al punto B”.
La metáfora del transporte separa la respuesta conversacional de la ejecución con objetivo, porque el valor del agente depende de su capacidad para completar una tarea bajo condiciones definidas y no solo de entregar una explicación más elaborada.
“El criterio está definido por la tarea y por el objetivo. Si quiero transportarme desde un punto A hasta un punto B, también busco que el proceso tenga la menor fricción posible y el menor costo posible, de modo que si debo pagar por ese trayecto, voy a preferir una ruta con menos congestión, menor consumo de combustible o menor precio”.
La medición del resultado queda integrada al concepto de agente, ya que un sistema de este tipo necesita criterios de éxito, restricciones y un objetivo que pueda evaluarse durante o después de la ejecución.
“La diferencia importante frente a un chatbot tradicional está en que un agente tiene un propósito, un fin, métricas para saber si el proceso fue exitoso o no, y un objetivo específico que puede ser duradero en el tiempo o puede ser efímero”.
Bajo esa lectura, el agente se define por la capacidad de operar dentro de un marco que combina herramientas, costos, restricciones e infraestructura, con una tarea que debe avanzar hasta un cierre verificable.
“Los chatbots están pensados como herramientas permanentes, capaces de dar soporte en procesos que pueden definirse mediante palabras o acciones. En los agentes también hay planificación y otros componentes, pero la metáfora del transporte funciona bien porque muestra que un agente puede mover algo por ti, ejecutar una tarea y respetar condiciones”.
La idea de traslado también introduce el costo de ejecución, porque un agente no actúa en el vacío y necesita infraestructura, permisos, condiciones de operación y una carga asociada a cada acción que realiza.
“Cuando pido a un servicio de mensajería que tome un paquete en mi casa y lo lleve a la oficina, esa operación evita que yo haga el traslado, pero también tiene un costo que en estos sistemas puede entenderse como un payload. La tarea requiere una infraestructura encargada de ejecutarla, un propósito, un fin, un costo, una serie de acciones y restricciones: llevar el paquete entre ciertas horas y dentro de una franja determinada”.
La diferencia con el chatbot queda entonces en la forma de interacción y en el alcance de la tarea, porque la conversación tradicional mantiene una relación más lineal con la información, mientras que el agente suma planificación, acción y evaluación de condiciones.
“Un chatbot mantiene la experiencia típica de conversar con una entidad que entrega acceso a información de manera lineal, de acuerdo con una serie de condiciones estipuladas. Esa definición me funciona y sobre ella suelo basar muchas explicaciones”.
La automatización de procesos repetitivos es el caso más evidente, aunque no agota el campo de uso de los agentes cuando el sistema debe interpretar información dispersa, revisar documentos o cruzar datos que no siguen un camino predefinido.
“Las tareas no repetitivas también pueden entrar en este campo, porque hay procesos que combinan condiciones, fechas, posibles exenciones y mucha información distribuida. Hace un par de semanas construí un agente para una demostración y le di acceso a mi correo electrónico completo, donde llegan facturas, notificaciones de pagos, movimientos de tarjeta y registros de gastos”.
El ejemplo desplaza la discusión desde la automatización mecánica hacia la exploración de información, con un agente que no solo repite pasos, sino que revisa un entorno amplio y busca relaciones que no estaban preordenadas.
“Le pedí que revisara qué entró, qué salió y que después comparara esa información con la página de la administración de impuestos. Como era la primera vez que ejecutaba esa tarea, no había un camino específico ni una secuencia previamente articulada: yo le estaba pidiendo que descubriera qué encontraba dentro del correo”.
La capacidad de detectar oportunidades o problemas no identificados por el usuario exige contexto, acceso a datos e interpretación sobre información que no siempre llega estructurada como una regla fija.
“En ese tipo de casos, el agente puede sorprenderte al detectar un elemento que habría permitido generar una exención y que no se había considerado. Esa ya no es una tarea repetitiva, sino una tarea que requiere analizar muchos volúmenes de información desde una perspectiva amplia, y ahí aparecen más campos de acción para los agentes”.
El paralelo con la automatización clásica conserva utilidad, pero su límite aparece cuando el agente deja de reemplazar una secuencia de clics y debe decidir cómo avanzar en escenarios abiertos, sin una ruta única.
“El caso repetitivo sigue siendo el más obvio, porque hacer diez clics en un sitio para acceder a un reporte se parece a lo que hacía RPA, solo que definido en lenguaje natural. La diferencia aparece cuando la tarea requiere elementos multivariados y el sistema debe decidir cómo moverse entre ellos”.
La referencia al correo electrónico muestra que el agente opera mejor cuando puede explorar un espacio de información, recibir un objetivo y ajustar el camino según los elementos disponibles, en vez de seguir una ruta rígida.
“Al darle acceso al correo electrónico, el agente abrió un horizonte de elementos que yo mismo desconocía. Esa es una forma útil de pensarlo: le dices a un automóvil que vaya del punto A al punto B, que busque la ruta más eficiente y que, si conviene tomar una vía alternativa, lo haga siempre que cumpla las restricciones”.
La autonomía descrita por García no equivale a libertad absoluta, porque la operación sigue dependiendo de parámetros definidos por el usuario o por la organización, y el agente solo debería moverse dentro de ese perímetro.
“Cuando defino una serie de parámetros, el agente puede decidir si toma otra ruta, si retrocede o si cambia el camino, siempre que no rompa las reglas. En esa misma línea aparecen agentes que coordinan otros agentes, como ocurre con vehículos autónomos, y por eso el ejemplo del transporte define bastante bien lo que ocurre hoy con los agentes de IA”.
Un agente de IA que debe operar un flujo completo necesita más que una instrucción inicial, porque el acceso a contexto, memoria, permisos e información suficiente define si el sistema puede sostener una tarea o si queda limitado a una conversación sin continuidad operativa.
“El contexto es una condición central para que un agente funcione. Incluso con una instrucción imperfecta, un agente que tiene contexto o una forma de acceder a memoria, idealmente en tiempo real, ya tiene casi la mitad del problema resuelto”.
El contexto se expresa en ventana disponible, tokens procesados y mecanismos de consumo, mientras que la calidad de la instrucción ordena la tarea y reduce ambigüedad en la operación del agente.
“Dentro del contexto entran la ventana disponible, la cantidad de tokens que procesa y el mecanismo de consumo. Todo eso importa, y luego viene una instrucción bien dada, porque saber qué pedirle a un agente puede ser tan importante como la respuesta que entrega”.
La conversación sobre prompts queda ligada a una práctica más amplia de diagnóstico, donde preguntar bien permite delimitar el problema y evitar que el agente trabaje sobre una premisa equivocada.
“La discusión sobre ingeniería de prompts tiene un fondo más amplio: una buena pregunta permite llegar a la causa raíz de un problema. La teoría de los cinco porqués apunta a lo mismo, porque al preguntar varias veces puedes encontrar la causa real o darte cuenta de que estabas mirando el problema equivocado”.
En esa arquitectura, el costo deja de ser una variable secundaria, porque un agente puede ejecutar más pasos, consultar más datos y consumir más tokens que un chatbot tradicional.
“El contexto, la calidad de la instrucción y las restricciones son los tres elementos que deberías poder definir claramente para un agente. Esa combinación puede permitir que haga algo bien o, de lo contrario, que solo estés perdiendo dinero y tiempo”.
La restricción económica también condiciona el comportamiento técnico del sistema, que, según el caso, puede actuar de forma directa, iterar, detenerse antes o ajustar su respuesta a límites definidos por el usuario.
“La restricción de costo determina parte del comportamiento operativo del agente, aunque no es la única variable. Según ese marco, el sistema puede ser más directo, iterar, devolver una respuesta parcial o ajustar su comportamiento de acuerdo con las condiciones impuestas”.
La agentización amplía la ventana de trabajo de un modelo y cambia la naturaleza de la tarea, porque el sistema ya no solo entrega una respuesta textual, sino que procesa instrucciones, acciones, historial, herramientas y restricciones dentro de un mismo flujo.
“La agentización se está convirtiendo en el caso de uso más concreto de la inteligencia artificial generativa, especialmente para clientes corporativos. Escribir un correo, corregir un documento o traducir texto ya lo puede hacer un estudiante, una persona mayor o un niño, cada uno con su finalidad, mientras que los agentes permiten construir casos de uso genuinos para resolver problemas genuinos”.
La diferencia técnica no está únicamente en la interfaz, sino en la cantidad de contexto que el sistema debe procesar cuando cada acción y cada restricción agregan carga al flujo de trabajo.
“La diferencia técnica aparece cuando el modelo deja de responder solo a una consulta y empieza a trabajar con más contexto, acciones y restricciones. Los modelos generan inferencias mediante predicción de la siguiente palabra o de una secuencia de palabras, apoyados en arquitecturas como Transformers, pero en un flujo agéntico empiezan a ingerir muchos más tokens”.
Esa carga se vuelve visible al comparar la misma tarea en modo conversacional y en modo agente, ya que la segunda opción tiende a ampliar el historial considerado y a sostener más pasos internos antes de entregar un resultado.
“Al pedir una misma tarea simple en modo chatbot y en modo agente, se puede comparar cuántos tokens entran y salen en cada caso. En modo agente, el sistema intenta ser más formal y tomar una ventana de contexto mucho más amplia, incluso parte del historial de conversación, lo que aumenta el consumo”.
El aumento de consumo explica por qué muchas funciones agénticas aparecen asociadas a planes más avanzados o modelos de mayor costo, en una operación más extensa sobre contexto, herramientas y memoria.
“Los modelos más avanzados y los planes de mayor costo aparecen precisamente porque el agente no solo responde. También toma contexto, procesa restricciones, ejecuta acciones y necesita sostener coherencia durante más pasos, por lo que muchos fabricantes recomiendan usar sus modelos más capaces para construir agentes”.
En el desarrollo asistido por IA, el vibe coding describe una práctica en la que una persona construye software mediante instrucciones en lenguaje natural, revisa las salidas del modelo y ajusta el resultado por iteraciones sucesivas. Esta dinámica puede acelerar prototipos y reducir barreras de entrada, pero también puede ocultar decisiones de arquitectura, dependencias y criterios de mantenibilidad si el proceso no queda guiado por especificaciones claras.
La posibilidad de programar en lenguaje natural abre una puerta potente y, al mismo tiempo, instala una advertencia sobre el código generado por IA que funciona en el corto plazo, pero puede crear sistemas difíciles de mantener si no existe una arquitectura clara.
“La forma de construir software está cambiando porque mucha gente siente que puede ser ingeniera de software desde el momento en que el lenguaje de programación más usado se volvió el inglés, el español, el chino o cualquier idioma natural. Ese cambio entrega un gran poder, pero también una gran responsabilidad”.
El riesgo surge cuando el código funcional se confunde con un sistema mantenible, sobre todo si una aplicación opera correctamente en una demostración mientras esconde decisiones que nadie podrá explicar después.
“Estamos generando código que llega a producción y que a veces ni siquiera entendemos. Con eso podemos estar creando la siguiente generación de deuda técnica más grande en la historia, una deuda que otros tendrán que gestionar y administrar”.
La trazabilidad del desarrollo se vuelve crítica cuando el proceso depende de salidas generadas sin diseño claro, porque el mantenimiento futuro puede transformarse en una reconstrucción forense del sistema.
“El mantenimiento de muchos sistemas puede terminar convertido en arqueología de código fuente, con aplicaciones que nadie sabe cómo se hicieron, que simplemente funcionan y que nadie entiende cómo se guardan o cómo deben sostenerse. En algún momento, alguien tendrá que soportarlas”.
El paralelo con tecnologías heredadas ayuda a dimensionar el riesgo actual, con la diferencia de que ahora la generación de código puede multiplicarse con mucha más velocidad y sin que los equipos comprendan necesariamente su diseño.
“Lo ocurrido con Cobol muestra que una tecnología puede quedar instalada durante décadas en sistemas críticos. Mi profesor de Cobol de la universidad sigue trabajando y tiene más de noventa años; es un genio, pero sigue activo porque aprendió una lengua muerta que todavía sostiene sistemas críticos”.
La lección para la etapa actual no consiste en rechazar la programación asistida, sino en ubicarla dentro de una arquitectura donde las especificaciones impidan que la entrega inicial traslade el problema completo al mantenimiento.
“El vibe coding puede llevarnos a un punto similar si no se acompaña de arquitectura. Por eso conceptos como el diseño guiado por especificaciones tienen tanto sentido: lo que hay que buscar es arquitectura, no solo código generado por impulso, pensando en la siguiente generación de deuda técnica que puede venir”.
El uso de agentes no resuelve por sí mismo una mala definición del problema, y el mayor riesgo aparece cuando una organización adopta esta capa por tendencia, no porque el caso requiera autonomía, herramientas o planificación.
“El reto más grande está en entender realmente el problema, porque estamos intentando resolver todo con agentes y hay cosas que no los necesitan. Algunas tareas pueden resolverse con una consulta, de modo que entender bien el problema ya representa la mitad de la solución”.
La decisión de usar agentes debería partir del diagnóstico y no por la disponibilidad de una herramienta nueva, con una secuencia que mida eficiencia, costo y productividad antes de escalar la arquitectura.
“La evaluación debería partir por conocer el problema, entender cómo se quiere resolver y dar buenas instrucciones. Luego hay que mirar la eficiencia, el costo y el impacto real, porque cuando alguien dice que consumió 50 millones de tokens en un mes, la pregunta relevante es cuál fue el efecto concreto en productividad”.
La productividad necesita indicadores concretos, porque consumir más tokens o incorporar más herramientas no equivale automáticamente a mejorar un proceso ni a generar valor para una organización.
“La discusión debería traducirse en preguntas concretas: cuánto tiempo se ganó, cuántas facturas adicionales se emitieron o qué actividad mejoró. Todavía estamos en una etapa de descubrimiento y sí existe sobreingeniería, porque antes el impulso era usar ChatGPT y ahora es usar agentes o cualquier herramienta nueva para decir que se está haciendo algo avanzado”.
La comparación con los microservicios ayuda a explicar el punto, ya que una arquitectura distribuida puede ser valiosa, pero pierde sentido cuando se convierte en un bloque enorme que pretende resolver todo.
“Un agente debería tener un propósito simple como condición elemental. Si intentas que haga cien cosas, probablemente ese no era el problema o ese no era el enfoque correcto, porque cuando la herramienta intenta resolverlo todo, deja de ser la herramienta adecuada”.
El problema de fondo no está en usar agentes, sino en diseñarlos como unidades demasiado amplias, capaces de concentrar tareas sin límites claros y de recrear el silo que supuestamente debían superar.
“La experiencia con microservicios dejó una lección parecida, porque cuando un microservicio hace todo, ya no es un microservicio, sino un silo gigantesco. Con los agentes ocurre lo mismo: si hay propósito claro, tarea simple y un objetivo definido, es mucho más difícil caer en sobreingeniería”.
El apego a proveedores o productos de moda reduce flexibilidad arquitectónica cuando el equipo mira primero la herramienta y después intenta ajustar el problema a ella.
“La sobreingeniería aparece cuando se intenta estar en todos los hypes, porque cada semana surge uno distinto. En el momento en que te fijas más en el producto que en el problema, pierdes una mirada agnóstica y quedas demasiado acoplado a una herramienta; cuando quieras salir de ella porque hay una mejor o una forma distinta de hacer las cosas, va a costar tiempo, esfuerzo y dinero”.
Un agente experimental puede operar con datos anonimizados o en un entorno acotado, pero en producción la conversación cambia porque aparecen permisos, accesos, sistemas reales, políticas de seguridad y condiciones operativas.
“Cuando un cliente dice que cree tener un agente listo, los controles son lo primero que revisamos. Antes de pasar a producción hay que mirar guardrails, políticas de acceso a los datos y seguridad general del ambiente, porque ese punto es fundamental”.
La etapa de prueba permite reducir riesgo mediante entornos aislados y datos protegidos, aunque el salto a producción exige revisar cómo se resguardan los accesos y cómo se controla el comportamiento del agente.
“Durante la etapa previa se puede trabajar con un sandbox o con información anonimizada sin problema. Nuestro motor de base de datos puede anonimizar datos al vuelo, sin crear procesos previos para ocultar información, pero la característica principal sigue siendo el aseguramiento”.
Un sandbox es un entorno aislado para probar software, modelos o automatizaciones sin afectar sistemas productivos ni exponer datos sensibles. En proyectos con agentes de IA, permite validar comportamiento, permisos y respuestas antes de conectar la herramienta con servicios reales.
El diseño de producción debe precisar cada acceso y cada condición de operación, porque la autonomía del agente solo es aceptable si queda delimitada por políticas técnicas y de seguridad.
En este contexto, los guardrails funcionan como límites operativos y de seguridad que restringen lo que un agente puede hacer, consultar o ejecutar. Su utilidad está en reducir respuestas fuera de alcance, accesos indebidos y acciones no autorizadas cuando el sistema deja de operar como prueba aislada.
“Cuando alguien está listo para llevar un agente a producción, debe definir cuáles serán los guardrails, a qué tendrá acceso, qué bases de datos podrá consultar, qué contextos usará, con qué sistemas se conectará, cómo será el mecanismo de entrega y con qué frecuencia operará”.
Ese conjunto de decisiones se acerca a lo que ya se describe como LLMOps, una práctica que exige mecanismos de control, observabilidad y gobierno comparables a otras disciplinas maduras de infraestructura.
LLMOps adapta prácticas de operación, monitoreo y gobierno al ciclo de vida de modelos y agentes de IA. En vez de mirar solo el rendimiento del modelo, incorpora trazabilidad, control de contexto, gestión de permisos, evaluación de respuestas y comportamiento estable cuando el sistema trabaja con datos o servicios reales.
“Las condiciones operativas forman parte de lo que muchos llaman LLMOps. Ya existe una práctica orientada a entender cómo dar control a todos esos contextos para que las cosas funcionen de verdad y de la manera más segura posible”.
La seguridad funciona como el corte entre un prototipo útil y una operación real, especialmente cuando hay datos, APIs y servicios productivos que obligan a anticipar errores, permisos indebidos y usos fuera de alcance.
“La seguridad marca la diferencia entre una prueba de desarrollo y una operación en producción. Cuando un agente opera sobre datos, APIs, bases de datos y servicios reales, el diseño debe responder a esa exigencia”.
La selección de modelos no debería comenzar por el sistema más caro ni por la herramienta más visible del momento, porque en entornos corporativos resulta más razonable reducir el costo de experimentación, comparar respuestas, medir latencia, detectar alucinaciones y decidir qué modelo aporta valor real según el caso de uso.
“Generalmente, recomendamos comenzar con modelos open source para que el costo de experimentación sea muy bajo. Si partes de inmediato con un modelo comercial avanzado y con razonamiento extendido, experimentar se vuelve caro; en innovación siempre hay que intentar llevar el costo de experimentación casi a cero”.
Esa recomendación convierte la experimentación en una etapa de descarte técnico, orientada a comparar modelos antes de comprometer presupuesto, arquitectura o dependencia operativa.
“Una forma simple de experimentar consiste en usar endpoints con modelos open source y probar distintas alternativas. El cliente puede comparar qué respuesta entrega cada una, qué tan asertiva es y qué tan fácil resulta forzarla a alucinar, para luego hacer una prueba ácida, construir un benchmark y decidir cuáles funcionan”.
Un endpoint es un punto final de comunicación donde una aplicación o dispositivo recibe y envía datos específicos. En APIs suele ser una URL concreta; en seguridad, es cualquier equipo conectado que se protege frente a amenazas.
El criterio de selección también puede distribuir tareas entre modelos distintos, con una capa más económica para procesar volumen y otra más sofisticada para encargarse del análisis complejo.
“Después se pueden escoger los dos o tres modelos que mejor responden para un caso específico. Si una empresa analiza llamadas de un call center en tiempo real, quizá no necesita un modelo de pago para procesar todo; puede usar un modelo open source para generar una síntesis y luego enviar esa síntesis a un modelo comercial más inteligente para extraer causa raíz o evaluar si el problema fue resuelto”.
La lógica no consiste en usar un único modelo para todo, sino en construir capas que respondan a objetivos, costos y exigencias técnicas distintas.
“Las capas deben partir de tener claro el objetivo, el problema y el costo. También hay que saber hacer bien las preguntas, entender las restricciones y comprender la ventana de contexto”.
El enfoque agnóstico evita que la selección del modelo quede determinada por preferencia o moda, y obliga a decidir desde pruebas, métricas y ajuste al caso de uso.
“Con una infraestructura agnóstica a nivel de modelos, la recomendación es probar, ejecutar y usar el modelo que realmente funcione para el caso. No hay que casarse con un proveedor o una herramienta si el problema puede resolverse mejor de otra manera”.
La combinación de modelos funciona como una extensión natural de esa evaluación, porque un flujo agéntico puede usar distintas capacidades para distintas etapas de una tarea, comparar resultados y ajustar su ruta según el desempeño observado.
“La visión agéntica de los modelos consiste en que un agente pueda decidir qué modelo resuelve mejor un problema e incluso pueda hacerse benchmark a sí mismo. Al compararse, puede decidir cómo avanzar en una dirección u otra según el resultado”.
El cierre de la conversación llevó el foco hacia la formación técnica, porque el desafío para desarrolladores y arquitectos no está solo en aprender prompts o herramientas de moda, sino en comprender arquitectura, datos y especificaciones.
“Lo primero que alguien debería aprender es desarrollo de software basado en especificaciones, o spec-driven development. Esa tendencia está asociada directamente a la inteligencia artificial porque se relaciona con ser arquitecto e ingeniero, no solo con hacer vibe coding”.
El enfoque de spec-driven development parte de describir con precisión qué debe hacer el sistema, cuáles son sus límites, qué interfaces necesita y cómo se validará el resultado. En desarrollo asistido por IA, esa especificación funciona como una barrera contra soluciones improvisadas que pueden operar bien en una demostración, pero fallar al escalar.
La distinción entre construir rápido y construir bien atraviesa toda la conversación, ya que una herramienta puede generar código funcional sin garantizar que el resultado sea mantenible o escalable.
“El vibe coding se parece a tirar de una máquina de casino, porque puedes tener suerte y pedir una aplicación bonita que funcione, pero eso no asegura que sea mantenible, que tenga APIs o que permita reutilizar código. A un modelo de lenguaje no le importa reescribir una función cien veces”.
La arquitectura vuelve a quedar por encima de la herramienta cuando las especificaciones funcionan como una capa de control sobre lo que el modelo produce en un entorno de desarrollo asistido por IA.
“El diseño guiado por especificaciones importa porque las herramientas serias y escalables necesitan conocimiento de arquitectura, y ese conocimiento debe prevalecer. Si una persona está estudiando ingeniería de software o quiere ser desarrolladora, debe tener claros esos conceptos”.
La persistencia de datos aparece como segundo eje, porque sin una política clara de modelo de datos, el resultado puede funcionar en una demostración, pero volverse inmantenible cuando escala.
Un ORM, u Object-Relational Mapping, es una capa que permite a una aplicación trabajar con datos como objetos de programación y traducir esas operaciones hacia una base de datos relacional. Aunque simplifica el desarrollo, no reemplaza el diseño de datos ni la comprensión de cómo se almacena, consulta y mantiene la información.
“Aprender bases de datos sigue siendo fundamental, porque no conviene dejar que los ORM resuelvan solos el tema de la persistencia. Si los datos están ordenados, entregan mejores resultados; si los datos están mal, los resultados también serán malos”.
La advertencia apunta a una práctica frecuente en proyectos nuevos con IA, donde el modelo decide la estructura de datos sin dirección técnica y el equipo gana velocidad inicial a cambio de perder control futuro.
“Todavía hay que entender primitivas de acceso a datos, por qué se usan, cómo funcionan y cómo se hacen eficientes. Me encuentro con personas que dicen estar construyendo aplicaciones, pero cuando pregunto cuál es su política de modelo de datos con inteligencia artificial, muchas veces están dejando que la herramienta lo decida; eso será inmantenible en poco tiempo”.
La apertura técnica funciona como tercer punto de formación, porque en un entorno que cambia con rapidez, el valor no está en atarse a una sola herramienta, sino en comprender protocolos, frameworks y modelos que puedan integrarse.
“La mirada agnóstica importa porque no conviene casarse con una sola herramienta. Hay que seguir usando tecnologías open source que permitan integraciones profundas, como LangChain, LangGraph o AutoGen de Microsoft”.
LangChain, LangGraph y AutoGen forman parte del ecosistema usado para construir aplicaciones con modelos de lenguaje, flujos de agentes e integraciones con herramientas externas. Su presencia en la conversación apunta a una arquitectura más modular, donde el valor está en conectar capacidades y no en depender de un único modelo o proveedor.
La interoperabilidad gana relevancia cuando los agentes deben conectarse con modelos, sistemas y herramientas externas, un escenario donde conocer estándares importa más que depender solo de productos cerrados.
MCP, o Model Context Protocol, apunta a estandarizar la forma en que una aplicación entrega contexto, herramientas y datos a un modelo de IA. Su aparición refleja una necesidad práctica: que distintos sistemas puedan comunicarse con agentes y modelos sin crear integraciones aisladas para cada caso.
“Nuestro agent builder habla con esos lenguajes open source porque sigue especificaciones abiertas. También hay que conocer protocolos como MCP, que ya opera como un protocolo abierto con una comunidad detrás para asegurar que se use de forma estándar”.
La velocidad del cambio obliga a mantener una base técnica amplia, y la actualización permanente deja de ser una actividad complementaria para convertirse en parte del trabajo profesional en IA.
“Nunca antes había sido tan relevante saber un poco de todo, porque todo cambia muy rápido. Los años se volvieron meses, los meses semanas, las semanas días y los días horas; en este momento hay que tener la cabeza abierta para experimentar con distintas herramientas y probar cuál es mejor”.
El seguimiento activo de repositorios, herramientas emergentes y proyectos open source no implica adoptar cada novedad, sino evaluar qué puede convertirse en una solución útil antes de incorporarla a un flujo real.
“Dedico tiempo todas las semanas a revisar los repositorios más activos de GitHub. Entro, miro cuáles son los proyectos que más están sonando y pruebo herramientas; algunas tienen potencial y otras se descartan, pero estar en esa última línea también es parte del trabajo”.
