--- term: 'Agente de IA' seoTitle: 'Agente de IA: Loop ReAct, Tools, Confiabilidad, Seguridad' headline: '¿Qué es un agente de IA?' slug: agente-de-ia category: ai-modern-stack shortDefinition: 'Un agente de IA es un sistema guiado por LLM que persigue un objetivo en loop: razona, llama a una tool, observa el resultado y repite.' relatedTerms: - llm-api - model-context-protocol-mcp - cloud-code-serverless-functions - access-control-lists-acl contrastsWith: - llm-api aboutTerms: - 'El Loop del Agente (ReAct)' - 'Tools & Function Calling' - 'Memoria del Agente' faq: - question: '¿Qué es un agente de IA en términos simples?' answer: 'Un sistema de software que usa un modelo de lenguaje para descubrir y ejecutar por sí solo un objetivo de múltiples pasos — planificando, usando tools y tomando acciones en vez de solo conversar. La diferencia con un chatbot es la autonomía: decide su propia secuencia de pasos y actúa sobre el mundo a través de tools.' - question: '¿Cuál es la diferencia entre un agente de IA y un chatbot?' answer: 'Un chatbot responde — contesta un mensaje y se detiene. Un agente actúa — razona sobre el objetivo, decide qué tools usar, las llama, observa los resultados y continúa hasta terminar la tarea. Un chatbot habla de reembolsar tu pedido; un agente lo reembolsa.' - question: '¿Cómo funciona el loop del agente?' answer: 'Recibe un objetivo, razona sobre el siguiente paso, llama a una tool, observa el resultado, razona de nuevo — repite hasta terminar o hasta chocar con un límite de pasos o de costo. Ese ciclo razonar-actuar-observar es el patrón ReAct, y es lo que hace a un agente agéntico en vez de conversacional.' - question: '¿Qué son las tools y el function calling?' answer: 'Las tools son funciones externas — llamadas a APIs, consultas a la base de datos, ejecución de código — que el agente puede invocar. El function calling es el mecanismo: el modelo emite una llamada JSON estructurada nombrando una tool y sus argumentos, tu código la ejecuta y el resultado vuelve al modelo. El modelo nunca ejecuta la tool; solo la solicita.' - question: '¿Qué es la memoria de un agente?' answer: 'Dos tipos. La memoria de corto plazo es lo que cabe en el context window (ventana de contexto) — los pasos recientes y el estado de trabajo. La memoria de largo plazo es conocimiento persistido en una base de datos o un vector store y recuperado entre sesiones. El loop necesita ambas: la ventana para razonar ahora, el store para recordar después.' - question: '¿Los agentes de IA son confiables y están listos para producción?' answer: 'Los pasos individuales suelen ser confiables; las cadenas largas, no. Si cada paso tiene un 95% de éxito, diez pasos rondan el 60% y veinte, el 36% — los errores se componen. Los agentes de producción mantienen cadenas cortas, verifican resultados, ponen las acciones irreversibles detrás de aprobación humana y restringen lo que las tools pueden hacer.' - question: '¿Cuándo no deberías usar un agente de IA?' answer: 'Cuando la tarea es determinística y está bien definida, un workflow simple o código común es más barato, más rápido y más confiable. Los agentes solo justifican su complejidad cuando el camino no puede guionarse de antemano — agrega autonomía cuando demostrablemente mejora el resultado, no por defecto.' - question: '¿Cómo se relaciona MCP con los agentes de IA?' answer: 'El Model Context Protocol es un estándar abierto para cómo un agente descubre y llama tools y datos, reemplazando integraciones artesanales por una interfaz común. MCP es la tubería entre el agente y sus tools; las tools en sí siguen siendo las funciones de tu backend, haciendo el trabajo de verdad.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)' url: 'https://arxiv.org/abs/2210.03629' - name: 'Building Effective Agents — Anthropic' url: 'https://www.anthropic.com/engineering/building-effective-agents' - name: 'LLM-Powered Autonomous Agents — Lilian Weng' url: 'https://lilianweng.github.io/posts/2023-06-23-agent/' - name: 'Confused Deputy Attacks on Autonomous AI Agents — Cloud Security Alliance' url: 'https://cloudsecurityalliance.org/' - name: 'AI agent — Wikipedia' url: 'https://en.wikipedia.org/wiki/AI_agent' cta: title: 'Tu backend es el guardrail del agente' text: 'En Back4app, las tools de un agente son funciones Cloud Code que corren bajo la sesión del usuario — las ACLs deciden qué puede tocar el agente, así que un agente secuestrado no puede exceder los permisos del propio usuario.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-03' translationKey: ai-agent --- **Un agente de IA es un sistema guiado por LLM que persigue un objetivo en loop: razona, llama a una tool, observa el resultado y repite.** Una [llamada simple a un LLM](/glossary/es/api-de-llm/) responde y se detiene; un agente envuelve esa llamada en un loop de control con **tools** (funciones que puede invocar), **memoria** (estado entre pasos) y suficiente **autonomía** para elegir su propia secuencia de acciones. El giro clave para quien desarrolla backend es el hecho más simple y menos dicho sobre agentes: **las "tools" de un agente son tus endpoints de backend** — cuando un agente "usa una tool", está llamando a una API que tú escribiste, lo que hace de tu backend, y no del prompt, el lugar donde la seguridad realmente vive. ## Puntos clave | Pregunta | Respuesta | | --- | --- | | El loop | Razona → actúa (llama a una tool) → observa → repite hasta terminar (ReAct) | | Las cuatro partes | Modelo (razonamiento) · tools (acciones) · memoria (estado) · orquestación (el loop) | | vs. un chatbot | Un chatbot *habla* de la tarea; un agente la *hace* | | La verdad dura | La confiabilidad se compone *a la baja* — 95%/paso es ~60% en 10 pasos | | La frontera de seguridad | El backend impone lo que las tools pueden hacer — no el buen comportamiento del modelo | ## Cómo funciona el loop de razonamiento de un agente de IA (ReAct) ```text OBJETIVO: "Reembolsa mi último pedido y envíame la confirmación" ┌────────────────────────────────────────────────────┐ │ 1 REASON modelo: "¿cuál es el último pedido?" │ │ 2 ACT llama tool: find_orders(user, last=1) │ │ 3 OBSERVE resultado: pedido #1187, $42, entregado │ │ 4 REASON "elegible — reembolsar" │ │ 5 ACT llama tool: refund_order(1187) │◄─ cada ACT llega a │ 6 OBSERVE resultado: reembolsado │ TU backend │ 7 REASON "ahora enviar el email" │ │ 8 ACT llama tool: send_email(...) │ │ 9 REASON "listo" → respuesta final │ └────────────────────────────────────────────────────┘ El modelo nunca ejecuta una tool. La SOLICITA (nombre + argumentos); tu código la ejecuta y devuelve el resultado al siguiente paso de razonamiento. ``` Las tools de ese loop, en el backend — con alcance acotado, con permisos, corriendo como el usuario: **JavaScript:** ```javascript // JavaScript — Cloud Code (cloud/main.js) // An agent's "tool" is a backend function — scoped, permissioned, auditable Parse.Cloud.define('refundOrder', async (req) => { // Runs under the CALLING USER's session — ACLs gate everything. // A hijacked agent can't exceed what this user may already do. const order = await new Parse.Query('Order').get(req.params.orderId); // beforeSave/ACL checks apply: not your order → this throws, agent or not if (order.get('amount') > 100) throw 'Refunds over $100 need human approval'; order.set('status', 'refunded'); await order.save(); return { refunded: order.id }; // the tool result the model reasons over next }); // The backend, not the prompt, is the security boundary. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The agent loop runs server-side; the tools it may call are YOUR functions final result = await ParseCloudFunction('runAgent') .execute(parameters: {'goal': 'Refund my last order and email me'}); print(result.result); // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The agent loop runs server-side; the tools it may call are YOUR functions let result: [String: Any] = try await Cloud.run( name: "runAgent", parameters: ["goal": "Refund my last order and email me"]) print(result) // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The agent loop runs server-side; the tools it may call are YOUR functions val params = mapOf("goal" to "Refund my last order and email me") val result = ParseCloud.callFunction>("runAgent", params) println(result) // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` ## Los cuatro componentes centrales de un agente de IA ```mermaid flowchart LR accTitle: Los cuatro componentes de un agente de IA accDescr: Un agente de IA combina un modelo de lenguaje para razonar, tools que puede invocar para actuar, memoria de corto y largo plazo para el estado y un loop de orquestación que recorre razonamiento, acción y observación hasta alcanzar el objetivo. Las tools son funciones y APIs del backend. M["Modelo
(núcleo de razonamiento)"] --> O["Loop de orquestación
razona → actúa → observa"] T["Tools
(tu API / funciones)"] --> O MEM["Memoria
corto plazo (ventana)
largo plazo (base de datos)"] --> O O -->|"llamadas a tools"| BE[("Tu backend
+ datos")] BE -->|"resultados"| O ``` La [descomposición canónica](https://lilianweng.github.io/posts/2023-06-23-agent/) es modelo + planificación + memoria + uso de tools, pero la versión operativa es más simple: un **modelo** razona, las **tools** actúan (y son funciones del backend), la **memoria** guarda el estado — corto plazo en el [context window](/glossary/es/api-de-llm/), largo plazo en una [base de datos o un vector store](/glossary/es/base-de-datos-vectorial/) — y el **loop de orquestación** lo amarra todo, basado en el [patrón ReAct](https://arxiv.org/abs/2210.03629) de intercalar razonamiento y acción. ## Agente vs. chatbot vs. llamada a LLM vs. workflow | | Llamada simple a LLM | Chatbot | Workflow | Agente de IA | | --- | --- | --- | --- | --- | | Hace | Responde una vez | Conversa | Ejecuta pasos fijos | Elige sus propios pasos | | Flujo de control | Ninguno | Por turnos | **Rutas de código predefinidas** | **Dirigido por el modelo** | | Toma acciones | No | No | Sí, guionadas | Sí, decididas en runtime | | Predecible | Por llamada | Más o menos | **Determinístico** | **Probabilístico** | | Ideal para | Q&A, extracción | Chat de soporte | Procesos conocidos | Objetivos abiertos | La distinción que más importa, y que casi ningún glosario traza: **un workflow es [orquestación](/glossary/api-orchestration/) por rutas de código predefinidas; un agente deja que el modelo dirija su propio camino.** La [guía de Anthropic](https://www.anthropic.com/engineering/building-effective-agents) es directa sobre la consecuencia — la mayoría de las tareas que *parecen* necesitar un agente se resuelve mejor con un workflow determinístico, y solo agregas agencia cuando el camino genuinamente no puede guionarse. ## Confiabilidad: los errores se componen a la baja La sección honesta que las páginas de vendors evitan. Los agentes son impresionantes por paso y frágiles por cadena, porque **el éxito se multiplica**: si cada paso tiene una probabilidad de éxito *p*, una tarea de *n* pasos tiene un éxito de aproximadamente *pⁿ*. ```text éxito por paso 10 pasos 20 pasos 95% ~60% ~36% 90% ~35% ~12% 85% ~20% ~4% Una demo que clava un paso impresionante no es un sistema que clava veinte. En el mundo real, el éxito de agentes multipaso entre sistemas suele quedar en 20–40%. ``` Esa matemática dicta el manual de producción: **mantén las cadenas cortas**, **verifica los resultados** entre pasos en vez de confiar en ellos, **pon las acciones irreversibles** (enviar, borrar, cobrar, publicar) detrás de aprobación humana y **acota el loop** con topes de pasos y de costo, para que un agente confundido falle barato en vez de caro. La confiabilidad no es una propiedad del modelo que esperas que mejore; es una arquitectura que tú impones. ## La superficie de seguridad Un agente que puede *actuar* puede ser *engañado para actuar*, lo que lo convierte en una superficie de ataque genuinamente nueva. El **prompt injection** convierte instrucciones en la entrada del modelo en acciones reales — y la variante peligrosa es la *indirecta*: una página web envenenada, un email o un ticket de soporte que el agente lee puede cargar instrucciones que luego ejecuta con tus credenciales. El **confused deputy** es la forma del daño: un agente con permisos amplios, manipulado para usarlos mal en nombre de un atacante. Las mitigaciones son disciplina de seguridad antigua apuntada a un actor nuevo — **credenciales de mínimo privilegio, con alcance del usuario** (nunca le des al agente más de lo que el usuario de la tarea ya tiene), **tools denegadas por defecto y de alcance estrecho**, sandboxing y aprobación humana en todo lo irreversible. El encuadre más importante de todos: **el backend, no el prompt, es la frontera de seguridad.** Un prompt puede ser inyectado; un [chequeo de permisos](/glossary/es/listas-de-control-de-acceso-acl/) en el servidor no puede ser convencido de dejar de aplicarse. ## Cómo diseñar tools que un agente no pueda usar mal Como las tools *son* tu backend, el diseño de tools es seguridad de backend con el volumen al máximo. Haz cada tool **idempotente** donde sea posible (un reembolso reintentado no debe reembolsar doble), **de alcance estrecho** (una acción clara, no acceso crudo a la base de datos), **con permisos** (corre bajo la identidad del usuario y sus [ACLs](/glossary/es/listas-de-control-de-acceso-acl/) aplican) y **con schema claro** — las descripciones que el modelo lee para decidir *si* y *cómo* llamar a una tool merecen tanto cuidado como tus prompts, porque una descripción vaga de una tool es un bug que el modelo va a encontrar. Expón *acciones*, no tablas: `refund_order(id)` con sus propios chequeos, nunca `run_sql(query)`. ## Casos de uso comunes - **Operaciones de atención al cliente** — un agente resolviendo un objetivo de soporte de punta a punta vía tools con permisos, con aprobación humana en reembolsos y cancelaciones. - **Asistentes de código** — leyendo un repositorio, corriendo tools, iterando hacia un cambio bajo revisión. - **Investigación y síntesis** — recuperación y resumen en múltiples pasos, cuando el camino no se conoce de antemano. - **Workflows de datos con criterio** — pasos que necesitan razonamiento entre ellos, no solo un [pipeline](/glossary/api-orchestration/) fijo. - **Agendamiento y coordinación** — objetivos que atraviesan varios sistemas, cada uno alcanzado a través de una tool con alcance acotado. ## ¿Deberías construir un agente? Matriz de decisión | Situación | Elige | | --- | --- | | Los pasos se conocen de antemano | Un [workflow](/glossary/api-orchestration/) — determinístico, testeable | | Una pregunta o extracción puntual | Una [llamada simple a un LLM](/glossary/es/api-de-llm/) | | Objetivo abierto, camino decidido en runtime | Un agente — su casa | | Acciones irreversibles en el loop | Un agente *con aprobación humana* | | Muchas tools reutilizables entre agentes/modelos | Estandarízalas vía [MCP](/glossary/es/mcp/) | | La confiabilidad es crítica para la seguridad | Cadenas cortas, verificación — o no lo automatices | ## Limitaciones y trade-offs - **La autonomía cambia confiabilidad por capacidad.** La libertad que le permite al agente manejar objetivos abiertos es la misma que compone errores — acótala deliberadamente. - **Los loops cuestan dinero y tiempo.** Cada iteración son más llamadas al modelo; los agentes son más lentos y más caros que una llamada única por diseño — pon topes y monitorea ambos. - **El no determinismo resiste los tests.** Un workflow se prueba con unit tests; un agente se *evalúa* estadísticamente, a lo largo de muchas ejecuciones, porque la misma entrada puede tomar caminos distintos. - **El radio de daño son tus credenciales.** Un agente es tan seguro como el permiso más estrecho que le diste a sus tools; el acceso demasiado amplio es el incidente esperando a ocurrir. - **Impresionante ≠ confiable.** Una demo convincente es una cadena con suerte; producción es el trabajo aburrido de guardrails, aprobaciones y caminos cortos. ## Agentes de IA en Back4app Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La tesis de que "las tools son funciones de backend" es la integración entera: las tools de un agente son [funciones Cloud Code](/glossary/es/cloud-code-funciones-serverless/) y, como corren bajo la sesión del usuario que llama, las [ACLs y permisos de clase](/glossary/es/listas-de-control-de-acceso-acl/) de la plataforma filtran cada lectura y escritura que el agente intenta — como muestran las pestañas de código, un agente secuestrado o víctima de prompt injection *no puede exceder los permisos del propio usuario*, porque el radio de daño del confused deputy queda acotado por el control de acceso, no por el buen comportamiento del modelo. El resto se sigue de ahí: expón acciones con alcance acotado (`refundOrder`), no datos crudos; mantén la [clave del modelo del lado del servidor](/glossary/es/seguridad-de-claves-de-api/); estandariza la superficie de tools con [MCP](/glossary/es/mcp/) cuando varios agentes la comparten; y deja que el backend diga que no. El agente propone; el backend dispone — que es exactamente donde debería vivir la seguridad de un sistema autónomo.