Philia Sophia – Javier Forero

Lo que de verdad delegamos cuando decimos “agente”

Casi todas las conversaciones sobre agentes que tengo con empresas empiezan por la herramienta: ¿uso ChatGPT, Claude, Gemini o una plataforma de automatización? Y casi siempre llegan con prisa: el competidor ya anunció el suyo, el proveedor lo trae en la próxima versión, el comité pregunta por qué todavía no tenemos uno. Es comprensible, pero la pregunta llega demasiado pronto. La pregunta no es qué herramienta usar. La pregunta es qué vas a delegar, y qué necesitaría alguien —o algo— para hacerlo bien sin ti al lado.

Piensa en tres encargos: revisar tu entrenamiento, mantener al día un tablero de datos o convertir una idea en una publicación. En los tres delegas trabajo a un sistema, pero cada uno necesita información, herramientas y libertad muy distintas.

He construido soluciones para esas tres necesidades, y me dejaron dos lecciones que no esperaba. La primera: usar inteligencia artificial (IA) para construir un sistema no te obliga a usarla para operarlo. La segunda: autonomía e IA son cosas distintas. El más autónomo de mis tres sistemas es, justamente, el único que no usa un modelo de IA.

En mi guía de agentes de IA de 2025 exploré el paso de conversar con la IA a encargarle acciones. Aquí doy el paso siguiente: cómo diseñar el encargo antes de que la presión decida por ti.

Quien cuida tu casa

Antes del concepto, una imagen. Te vas de viaje dos semanas y una persona de confianza va a cuidar tu casa. ¿Qué le dejas?

• Le cuentas dónde está cada cosa, qué plantas son delicadas y qué correo esperas. Eso es contexto.
• Le explicas qué hacer si llueve, qué es urgente y qué puede esperar, y cómo sabrás que todo salió bien. Eso es criterio.
• Le das llaves: la de la puerta, quizá la del garaje, no la de la caja fuerte. Esas son las manos, con sus permisos.
• Le dices cuándo pasar: los martes, si llega un paquete, si el vecino avisa de algo o cuando tú le escribas. Ese es el disparador.

Y le dices algo más, que casi nadie escribe: si algo se rompe, no lo arregles; llámame. Es parte del criterio, pero merece nombre propio porque es lo primero que se olvida: la salida, el momento en que el sistema te devuelve el control.

Ahora, el giro. Para regar las plantas cada martes a las seis no necesitas a nadie: un temporizador de riego lo hace sin cansancio y sin pedir explicaciones. No le pagas a una persona —ni a un modelo de IA— para abrir una llave a una hora fija. Ese es el corazón de este artículo.

La presión por tener agentes

Hoy la palabra “agente” se usa para casi todo, y la presión llega por dos lados.

Desde la oferta, muchos productos que ya existían se rebautizan. Gartner lo llama agent washing: presentar como agentes a asistentes de IA, a chatbots y a robots de software —RPA, programas que repiten clics y tecleos como lo haría una persona— sin que ganen autonomía real. En junio de 2025 estimó que, de los miles de proveedores que se presentan como “agénticos”, solo unos 130 lo son de verdad, y pronosticó que más del 40 % de los proyectos de IA agéntica se cancelarán antes de terminar 2027 por costos crecientes, valor de negocio poco claro o controles de riesgo insuficientes (Gartner, 2025).

Desde la demanda pasa lo contrario, y es lo que veo en consultoría: empresas que piden “un agente” cuando lo que necesitan es una automatización con reglas. En el artículo sobre los dos mapas para usar la IA con criterio lo comparé con pagarle a un abogado por hora para que llene un formulario. Nadie quiere llevarle al comité directivo “una automatización”; “un agente” suena a futuro. Así, la conversación empieza por la etiqueta y no por el encargo.

Lo más revelador es quién pide prudencia. Anthropic, que vende los modelos con los que se construyen agentes, recomienda “encontrar la solución más simple posible y aumentar la complejidad solo cuando haga falta”, y añade que eso “podría significar no construir sistemas agénticos en absoluto” (Building effective agents). OpenAI pide validar primero que el caso implique decisiones complejas, reglas difíciles de mantener o mucha información no estructurada; si no, “una solución determinista puede bastar” (guía práctica de OpenAI). Las traducciones son mías. Cuando el fabricante te dice que quizá no necesitas su producto estrella, vale la pena escucharlo.

Un dato de 2026 conecta con algo que he repetido en este blog: Gartner proyecta que en 2028 los agentes de IA superarán diez a uno a los vendedores, pero que menos del 40 % de los vendedores dirá que mejoraron su productividad. Su explicación: “si esos sistemas están fragmentados, los agentes escalarán la fragmentación” (Gartner, 2026). Es la tesis de la IA no hace inteligente a tu empresa: solo amplifica lo que ya es. Un agente no arregla el proceso que encuentra; lo multiplica.

La presión por tener agentes empuja a empezar por la etiqueta. El valor está en empezar por el encargo.

Construir con IA y operar con IA son decisiones distintas

Durante la construcción, una IA puede ayudarte a diseñar un proceso, escribir el código y preparar las pruebas. Después, el programa resultante puede consultar fuentes, validar datos y guardar resultados con reglas, sin volver a llamar a un modelo.

Ese programa seguirá necesitando infraestructura, accesos y mantenimiento. Pero si mientras funciona interpreta lenguaje o decide acciones con un modelo, además tendrás que evaluar esas respuestas y decisiones. Es una carga distinta, y conviene saber de antemano cuál vas a asumir.

Por eso separo tres momentos. Cambia de pestaña y mira cómo se ven en mi tubería de tasas de cambio, que presento más adelante:

Fíjate en lo que pasa con la revisión: no desaparece, se muda. Con IA en la construcción revisas el código una vez, con pruebas y a tu ritmo, y después lo vigilas. Con IA en la operación revisas salidas todo el tiempo, todas o por muestreo. Y el código escrito con ayuda de IA también hay que entenderlo: si nadie en tu equipo puede explicarlo, no lo construiste, lo heredaste.

Usar IA para construir un sistema no te obliga a usarla para operarlo.

Agentes, automatizaciones y chatbots: precisemos el encargo

La idea de agente es anterior a los modelos generativos. En 1995, Michael Wooldridge y Nicholas Jennings publicaron una revisión que ya recogía distintas interpretaciones del término, y el libro de texto más usado de la disciplina, el de Stuart Russell y Peter Norvig, define un agente como cualquier cosa que percibe su entorno y actúa sobre él. Por eso, cuando alguien me dice “quiero un agente”, le pido que me explique cómo funcionaría, no cómo se llamaría.

Hay cuatro formas comunes de organizar el trabajo:

Desliza la tabla →

Un modelo de lenguaje —el motor de ChatGPT, Claude o Gemini— es un sistema entrenado para predecir texto; de ahí salen su capacidad de interpretar y de redactar. Anthropic separa los dos últimos casos con precisión —la traducción es mía—: en los flujos, los modelos y las herramientas se coordinan “mediante rutas de código predefinidas”; en los agentes, los modelos “dirigen de forma dinámica sus propios procesos y el uso de herramientas” (Building effective agents). Y advierte el precio: la autonomía trae “costos más altos y la posibilidad de errores que se acumulan”.

Las categorías se solapan, y está bien. Lo útil es poder responder tres preguntas sobre tu tarea; las tomé de los criterios que propone la guía de OpenAI:

Un chatbot, por su parte, describe una forma de interacción, no un nivel de autonomía: puede limitarse a responder o estar conectado a un sistema que ejecuta trabajo.

La activación manual es compatible con el trabajo delegado. Que un sistema espere tu solicitud no determina cuánta autonomía tendrá después, y los objetivos, los permisos y las consecuencias siguen teniendo dueño.

Las cuatro piezas de la delegación

Son dimensiones de diseño, no cuatro pasos obligatorios en ese orden. El disparador inicia la ejecución; las demás piezas orientan su recorrido. Explóralas una por una:

Skills, plugins y MCP: quién hace qué

Aquí es donde más se enreda la conversación, porque los nombres comerciales cambian de una plataforma a otra. Vamos por función.

Una habilidad guarda el procedimiento

Una skill, o habilidad, es una carpeta con instrucciones y recursos para una tarea repetible: puede incluir ejemplos, plantillas y programas auxiliares. El formato Agent Skills lo desarrolló Anthropic, lo liberó como estándar abierto y hoy lo admiten herramientas de distintos fabricantes, como Cursor, GitHub Copilot, Gemini CLI o Codex, de OpenAI. Un detalle de diseño que me gusta: el agente solo lee el nombre y la descripción de cada habilidad hasta que una tarea la necesita; entonces carga el resto.

En nuestro marco, la habilidad conserva sobre todo criterio: cómo revisar fuentes o comprobar una entrega, escrito una vez y corregido con el uso. Dos advertencias: compartir un formato no garantiza el mismo comportamiento en todas las plataformas, y una habilidad puede traer programas que se ejecutan en tu equipo. Anthropic recomienda instalarlas solo de fuentes de confianza y auditar las demás antes de usarlas.

Y no confundas repetible con programada: la habilidad permite repetir el procedimiento, pero necesita otro mecanismo para correr a cierta hora sin que nadie la pida.

Un plugin reúne varias piezas

Un plugin, o complemento, es un paquete. En Claude Code, por ejemplo, reúne habilidades, agentes, hooks —acciones que se ejecutan en momentos definidos— y servidores MCP que se instalan como una unidad. Habilidad y plugin no son sinónimos: uno puede contener a la otra.

Un conector abre el acceso; MCP lo estandariza

Un conector integra una aplicación con otra. MCP, sigla de Model Context Protocol (protocolo de contexto del modelo), es un estándar de código abierto para conectar aplicaciones de IA con sistemas externos: datos, herramientas y flujos de trabajo. Su documentación oficial lo compara con un puerto USB-C. Yo prefiero las tuberías: MCP define las medidas comunes de los tubos para que cualquier grifo conecte con cualquier tanque. Pero no decide qué agua pasa ni cuándo se abre la llave, y no todos los conectores lo usan. Cuando lo que se conecta son agentes entre sí, existe otro estándar, A2A, que Google creó y entregó a la Linux Foundation en junio de 2025.

Esta separación tiene una ventaja práctica: puedes actualizar el procedimiento sin tocar el horario. Pero no te confundas con la otra dirección: cada conexión nueva es una llave más. Conectar un servidor MCP le da al agente la autoridad de las herramientas que ese servidor expone, por eso la guía de seguridad de MCP recomienda empezar con los permisos mínimos y ampliarlos solo cuando una operación concreta lo exige.

Tres casos propios para aterrizarlo

Mi entrenador personal: antecedentes y actividades de Strava

Como corredor aficionado, reuní mediciones físicas, pruebas de esfuerzo, exámenes médicos, resultados de carreras y una ficha de mi trayectoria. Añadí guías de entrenamiento funcional y atlético, y le di al asistente la capacidad de conectarse a Strava —la aplicación donde registro mis actividades— para consultar lo que he hecho.

Cuando lo necesito, le pido que analice esa información y prepare planes o recomendaciones. Un encargo típico sería: “Compara mis actividades recientes con mis antecedentes y propón cómo organizar la próxima semana. Explica qué datos usaste y qué falta”. Es un ejemplo ilustrativo, no un plan validado.

También lo he usado para consultar inquietudes ante lesiones. Ahí pongo un límite claro: sus sugerencias las reviso con un profesional de la salud. No diagnostica ni me autoriza a volver a entrenar, y tener mis exámenes cargados no equivale a una evaluación clínica. Hay una segunda lección que aplica a cualquier empresa: lo que pones en el contexto sale de tu perímetro. Mis exámenes están ahí porque decidí compartirlos con ese proveedor, no porque sea inocuo hacerlo.

Una precisión: mantener antecedentes permite comparar; no significa que el modelo se reentrene con mis datos.

Mi tubería de tasas: la operación queda en código

Construí un tablero de tasas de cambio de América Latina alimentado por una tubería de datos que documenté en GitHub, la plataforma donde se guarda y versiona código: fx-bancos-centrales. Hoy reúne las tasas oficiales de siete bancos centrales —México, Colombia, Argentina, Brasil, Chile, Uruguay y Perú— y las cruzadas que se calculan entre ellas.

El tablero es la parte visible. Detrás, un programa consulta las fuentes oficiales, valida, transforma y publica archivos. GitHub Actions, el servicio que ejecuta tareas de un repositorio de forma automática, lo pone en marcha con una configuración de horarios: de lunes a viernes a las 19:30 UTC (14:30 en Bogotá) y todos los días a la 01:00 UTC. También puedo lanzarla a mano. Revisé el recorrido en el código coordinador: ningún modelo de IA decide una descarga o un cálculo.

La construí con Claude, que escribió en Python un conector para cada banco central, y la publiqué en GitHub. Lo que no podía delegar fue entender la API de cada país —cómo publica, en qué formato, con qué reglas—, y para México y Chile tuve que tramitar mi propio token de acceso. Usé IA para construirla; para operarla, no la necesito.

Lo interesante es que el criterio quedó escrito:

• Una fuente caída nunca borra datos buenos. Si un banco central no responde, la serie conserva su histórico y queda marcada con error o como desactualizada.
• Cada tasa viene de quien la define. En Colombia, además, cada dato se verifica contra una segunda publicación oficial; ese contraste no existe para todos los países.
• Las tasas cruzadas se declaran como cálculos propios, no como cotizaciones oficiales, y la tubería se niega a cruzar dos series con distinta base temporal.
• Cuando algo se degrada, avisa. Abre un aviso en el repositorio —un issue— y lo cierra solo cuando una corrida posterior termina con todas las series en orden. Esa es su salida: devuelve el control a una persona.

Además construí un modelo semántico: una ficha que describe qué significa cada dato, de dónde sale y qué se puede hacer con él —aquí “modelo” no significa IA—. Está documentado, y el código lo aplica igual cada vez. Dividir dos números es fácil; saber cuáles corresponde dividir requiere entenderlos.

Como conté en el artículo sobre Claude Dashboards, esa ficha permitió que una IA diseñara un tablero correcto sobre estos datos en una sola conversación; en este video muestro el proceso.

Las reglas tampoco son gratis. Los servicios de los bancos centrales cambian, y una regla escrita para el formato de ayer puede fallar en silencio con el de hoy. Por eso la tubería prueba cada lunes, en vivo, el contrato de cada fuente y abre otro aviso si detecta un cambio. La diferencia está en la frecuencia: a una regla la vigilas; a las salidas de un modelo las revisas.

Las salidas de un modelo se revisan siempre, todas o por muestreo. Una regla se revisa cuando se escribe y se vigila después.

Esa es la razón de fondo para dejar la operación en código: no acumular deuda de revisión, la brecha entre lo que un sistema produce y lo que alguien alcanza a revisar con criterio.

Synco: una idea, un criterio de comunicador y varias versiones

Synco es una aplicación que construí en el ecosistema de Google y que siempre he llamado agente. Le construí un “cerebro” con mi experiencia en comunicaciones y publicidad: las reglas y buenas prácticas de cada plataforma, y cómo se adapta un mensaje a una audiencia. El usuario escribe su idea e indica su tono de marca; un modelo de Gemini la convierte en publicaciones ajustadas a cada red y produce varias versiones de cada una. Además, genera con modelos de Gemini la imagen que acompaña cada texto, porque una imagen que no tiene que ver con el mensaje le resta fuerza.

Las versiones responden a la escala del negocio digital: una sola idea se convierte en opciones para pruebas A/B o para audiencias distintas. Pero Synco entrega las variantes; cuál gana lo decide la audiencia en una prueba real, no el modelo. Publicar solo, programar o leer métricas serían capacidades distintas, con su propia implementación.

En la revisión importa que el mensaje conserve la intención, que no atribuya hechos o experiencias inexistentes y que la imagen no muestre algo que no existe. Crear una propuesta y autorizar que se publique en tu nombre son decisiones separadas. Si quieres ver otras aplicaciones, están en mi página de soluciones de IA.

Mis tres casos, con mi propia tabla

Sería fácil exigir precisión a los demás y no aplicármela. Con la tabla de arriba, el entrenador es un agente basado en un modelo: es el modelo el que decide cuándo consultar Strava y qué hacer con lo que encuentra. La tubería es una automatización con reglas, la más autónoma de las tres: publica sin pedirme permiso. Y Synco, que siempre he llamado agente, encadena etapas fijas —idea, redacción por plataforma, variantes e imagen— y genera versiones en paralelo. En el vocabulario de Anthropic, encadenar y paralelizar son patrones de flujo, no de agente: el modelo trabaja dentro de un recorrido que yo diseñé. Es un flujo con IA, y uno bien hecho, porque su valor no está en la autonomía sino en el cerebro que le escribí. Es decir, en el criterio. La etiqueta comercial también me ganó a mí, y lo dejo escrito porque es justo la presión de la que habla este artículo.

Actuar, comprobar y conservar el control

Durante el trabajo, las piezas se conectan en un ciclo: consultar información, elegir una acción, ejecutarla y comprobar si corresponde continuar, terminar o pedir ayuda. A veces una regla decide el siguiente paso; otras veces participa un modelo.

Imagina un boletín semanal hipotético. Una habilidad guarda los criterios de relevancia y verificación, una conexión permite consultar documentos autorizados y un horario inicia la ejecución. El sistema investiga y prepara un borrador; si dos fuentes se contradicen, deja la incertidumbre a la vista, y la persona responsable decide qué hacer con los hallazgos.

La autonomía se concede por acciones concretas, no en bloque. Consultar, recomendar y actuar tienen consecuencias distintas. Sube la escalera y mira qué cambia en cada peldaño:

Esta escalera no es solo mía. En mayo de 2026, Gartner propuso cuatro niveles muy parecidos —observar, aconsejar, actuar con aprobación y actuar de forma autónoma—, advirtió que aplicar el mismo gobierno a todos los agentes lleva al fracaso y proyectó que, para 2027, el 40 % de las empresas degradará o retirará agentes autónomos por brechas de gobierno que solo aparecen después de un incidente (Gartner, 2026). Es la misma lógica de la matriz de proporcionalidad del control: el control se ajusta a la consecuencia del error, no a la moda.

Los permisos y los límites deben configurarse en las herramientas, no solo describirse en las instrucciones. Una instrucción es una petición; un permiso es una cerradura. En julio de 2025, un inversionista que probaba la plataforma de programación Replit contó que el asistente de IA borró una base de datos durante un congelamiento de código que él mismo había ordenado. Los detalles se discutieron —era un proyecto de prueba y había respaldos—, pero la respuesta de la empresa fue la lección: separar automáticamente las bases de datos de desarrollo y de producción (The Stack). La instrucción decía “no toques nada”; el permiso permitía tocarlo todo.

Hay otro riesgo cuando un modelo lee contenido externo: una página puede incluir órdenes ajenas a tu encargo, escritas para que el modelo las obedezca. Se llama inyección de instrucciones (prompt injection). El investigador Simon Willison describió la combinación que lo vuelve peligroso, a la que llama la trifecta letal: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse hacia afuera. Con las tres, un atacante puede engañar al agente para que le envíe tus datos. Traducido a las cuatro piezas: el riesgo no está en una pieza, sino en la combinación de un contexto privado, un contexto externo y unas manos que escriben hacia afuera. Es el problema que planteé en RAG empresarial: el problema no es buscar, es permitir: lo que un sistema puede leer y hacer debe estar limitado por diseño, con varias barreras y una persona a la que escalar las acciones de alto riesgo.

Probar pequeño y medir el trabajo completo

Empieza por una tarea acotada y compárala con el proceso actual. Prueba la situación habitual y también las excepciones:

• Una fuente ausente o que no responde.
• Datos contradictorios entre dos fuentes.
• Una herramienta caída a mitad del trabajo.
• Una señal que llega dos veces.
• Un resultado incompleto.

Reserva algunos casos que el sistema no haya visto para comprobarlo después de ajustarlo. No necesitas cientos: Anthropic sugiere que entre 20 y 50 tareas sacadas de fallas reales son un buen comienzo, y que suele ser mejor calificar lo que el agente produjo que el camino que siguió. Mide también la consistencia: si el sistema va a trabajar sin que lo mires, importa que acierte todas las veces, no una de cada tantas.

Verifica el resultado real: si dice que guardó un archivo, comprueba que exista; si devuelve el control por falta de evidencia, no lo cuentes como resolución automática.

Y cuenta el trabajo completo: tiempo de revisión, correcciones, infraestructura y mantenimiento. Una medida que uso es el costo por resultado aceptado: el costo total dividido entre las entregas que cumplen el estándar, no entre todas las que produjo el sistema. Mira cómo cambia con la tasa de aceptación:

La comparación justa no es contra un ideal de diez de diez, sino contra el costo por resultado aceptado de tu proceso actual: las personas también rehacen trabajo. Es la misma lógica del costo por decisión exitosa que propuse en inteligencia proporcional y de lo que planteé sobre el retorno de la IA: el costo de revisar es el que casi nadie pone en el denominador.

Una ficha para tu próxima delegación

Antes de delegar una tarea, pásala por estas siete preguntas. Marca solo lo que hoy ya tienes respondido por escrito:

Hacer explícitas estas respuestas te obliga a entender mejor tu propio trabajo. A veces necesitarás un modelo; otras, un programa con reglas. Una habilidad puede conservar el procedimiento, pero alguien tiene que mantenerla y revisar si sigue siendo adecuada.

Dónde la evidencia es floja

Conviene separar qué parte de este artículo es evidencia y qué parte es criterio:

• Las cuatro piezas son una síntesis didáctica mía, no un estándar técnico. Se parecen a marcos clásicos —percibir, decidir, actuar—; su aporte está en el énfasis en el disparador y la salida, donde más fallan los proyectos en la empresa.
• Las cifras de Gartner son pronósticos de analistas, no mediciones; el de 2025 se apoya en parte en una encuesta a asistentes de un seminario web, una muestra que se selecciona sola. Son señal de tendencia, no tasa de fracaso.
• Que la mayoría de quienes piden un agente necesiten una automatización es una observación de mi consultoría, no una muestra representativa.
• El entrenador y Synco son experiencias que describo yo, sin evaluación independiente ni cifras de mejora medidas con rigor.
• El código público de la tubería permite revisar su diseño; no demuestra que cada ejecución sea correcta.
• El caso de Replit se conoce por el relato de su protagonista y la respuesta de la empresa, sin un informe técnico independiente.
• El boletín semanal es hipotético, y las equivalencias por producto de las láminas las revisé en octubre de 2026; esos nombres cambian rápido.

¿Qué cambiaría la conclusión? Resultados sostenidos, con calidad comparable y un costo por resultado aceptado menor que el del proceso actual, fortalecerían la decisión de delegar más en modelos. Incidentes, costos ocultos o correcciones sin beneficio la debilitarían. Y si los agentes basados en modelos empiezan a mantener reglas complejas mejor que las personas que hoy las escriben, el punto de equilibrio se moverá: la pregunta seguirá siendo la misma, pero la respuesta cambiará más a menudo.

Conclusión: delegar es escribir tu criterio

Volvamos a la casa. Quien la cuida bien no es quien tiene más llaves, sino quien sabe qué hacer con las que le diste, cuándo pasar y cuándo llamarte. Y las plantas de los martes, mejor dejárselas al temporizador.

Con los sistemas pasa lo mismo. La presión por tener agentes no va a bajar, y no hace falta resistirla ni ceder a ella. Hace falta convertir cada “necesitamos un agente” en un encargo escrito: la información que vale, el criterio que decide, los permisos que concedes, la señal que lo inicia y el momento en que te devuelve el control. Cuando eso está claro, a veces descubres que necesitas un agente. Otras veces descubres que necesitabas una regla. Las dos son buenas noticias.

Piensa en una tarea de esta semana: ¿qué tendrías que aclarar para delegarla sin perder la capacidad de verificarla?

Preguntas frecuentes

¿Qué es un agente de IA?

En la definición clásica de la disciplina, un agente es cualquier cosa que percibe su entorno y actúa sobre él. Hoy, cuando se habla de un agente de IA, casi siempre se trata de un sistema en el que un modelo de lenguaje participa en elegir los pasos y las herramientas para cumplir un encargo: consulta, decide, actúa y comprueba el resultado.

¿Un agente necesita un modelo de lenguaje?

No. Un agente puede decidir con reglas de condición y acción, como los sistemas de la IA clásica. Un agente basado en un modelo de lenguaje es una modalidad particular, útil cuando hay que leer texto libre, decidir ante excepciones o mantener reglas que ya no caben en una tabla.

¿Qué diferencia hay entre un agente y una automatización?

Una automatización por reglas sigue una secuencia y unas condiciones escritas de antemano. Un agente elige acciones según lo que observa, con reglas o con un modelo. Entre ambos están los flujos con IA: etapas fijas con un modelo en algunas de ellas.

¿Qué es el agent washing?

Es presentar como agentes productos que ya existían —asistentes de IA, chatbots o robots de software (RPA)— sin que ganen autonomía real. Gartner estimó en 2025 que, de los miles de proveedores que se presentan como agénticos, solo unos 130 lo son de verdad.

¿Puedo crear con IA una automatización que funcione sin ella?

Sí. La IA puede ayudarte a diseñar y programar una solución cuya ejecución posterior dependa de código convencional, infraestructura y accesos, sin llamar a un modelo. La revisión se hace una vez, sobre el código, y después se vigila.

¿Un agente puede empezar con mi solicitud?

Sí. El inicio manual determina cuándo comienza; la autonomía describe qué trabajo y qué decisiones quedan delegados después.

¿Una skill ejecuta tareas cada semana?

Por sí sola, no. Guarda un procedimiento reutilizable; la ejecución periódica requiere un programador de tareas o un mecanismo equivalente configurado en la plataforma.

¿MCP y conector significan lo mismo?

No. Un conector es una integración; MCP (Model Context Protocol) es un estándar abierto que puede usarse para construirla. Cada conexión concede la autoridad de las herramientas que expone, así que conviene empezar con permisos mínimos.

¿Guardar información significa que el agente aprende?

No debe suponerse. Conservar antecedentes, aplicar reglas y actualizar los parámetros de un modelo son mecanismos distintos, y cada uno hay que diseñarlo.

Fuentes y lecturas