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 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)
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 — 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 — 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.// 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.// 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<Map<String, Any>>("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
La descomposición canónica 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, largo plazo en una base de datos o un vector store — y el loop de orquestación lo amarra todo, basado en el patrón ReAct 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 por rutas de código predefinidas; un agente deja que el modelo dirija su propio camino. La guía de Anthropic 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ⁿ.
é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 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 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 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 — determinístico, testeable |
| Una pregunta o extracción puntual | Una llamada simple a un 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 |
| 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 y, como corren bajo la sesión del usuario que llama, las ACLs y permisos de clase 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; estandariza la superficie de tools con 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.
Preguntas frecuentes
¿Qué es un agente de IA en términos simples?
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.
¿Cuál es la diferencia entre un agente de IA y un chatbot?
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.
¿Cómo funciona el loop del agente?
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.
¿Qué son las tools y el function calling?
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.
¿Qué es la memoria de un agente?
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.
¿Los agentes de IA son confiables y están listos para producción?
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.
¿Cuándo no deberías usar un agente de IA?
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.
¿Cómo se relaciona MCP con los agentes de IA?
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.