Agentes IA: la guía completa para construirlos, venderlos y no quemar el presupuesto

Por Daniele Forciniti

Índice

Los agentes IA son sistemas que juntan cuatro piezas: un modelo de lenguaje, la capacidad de llamar herramientas externas, un ciclo de ejecución que se repite y una memoria que guarda el estado. Si falta una de las cuatro, no tienes un agente: tienes un chatbot con un prompt largo. Esta guía explica cómo están hechos de verdad, cómo se construyen empezando por el caso más simple, cuánto y cómo se cobran, y qué errores técnicos te queman un mes de trabajo y el presupuesto del cliente. Es larga y técnica a propósito: guárdala, vas a volver.

Qué es un agente y qué no lo es

La distinción más útil no se la inventó el marketing, la escribió Anthropic en su guía técnica sobre cómo construir agentes eficaces, y merece la pena aprendérsela porque te ahorra meses de trabajo equivocado:

Qué	Cómo funciona	Cuándo hace falta
Chatbot	Una llamada al modelo, con documentos en el contexto como mucho. Ninguna herramienta, ningún ciclo	Respuestas a preguntas, textos, resúmenes
Workflow	Modelo y herramientas orquestados por caminos de código que escribiste tú: sabes de antemano qué pasos se van a ejecutar	Procesos repetibles con pasos previsibles
Agente	El modelo decide solo su propio camino y qué herramientas usar, paso a paso	Problemas abiertos donde no sabes cuántos pasos harán falta

Anthropic es tajante en un punto que casi nadie repite porque no luce: los agentes cuestan más y pueden acumular errores en cadena. Su recomendación es añadir complejidad solo cuando mejora demostrablemente el resultado. Traducido a dinero: en el 90% de los encargos que te van a llegar, un workflow bien hecho gana a un agente autónomo, cuesta menos de mantener y no te llama el cliente el sábado.

El ciclo agéntico, explicado simple

Esquema del ciclo agéntico: percepción, razonamiento, acción, observación, que se repite hasta el objetivo — El ciclo que se repite en cada paso del agente

Un agente no responde y ya está: da vueltas hasta que el trabajo termina. Recibe la petición, decide qué herramienta hace falta, la llama, lee el resultado y vuelve a empezar con la información nueva. La vuelta se cierra cuando se cumple el objetivo o cuando se toca el límite de pasos que pusiste tú.

Ese límite de pasos no es un detalle: es la diferencia entre un sistema que funciona y una factura sorpresa. Sin un tope de iteraciones, un agente que se equivoca puede repetir el mismo intento decenas de veces, y te enteras a fin de mes.

Tool calling: cómo el modelo ejecuta acciones reales

El tool calling (o function calling) es la pieza que convierte un modelo que habla en un sistema que hace. Funciona así, y la mecánica es la misma en los principales proveedores, tal como recoge la documentación oficial sobre tool use:

Declaras la herramienta con tres cosas: un nombre, una descripción en palabras humanas y un esquema de los parámetros que acepta.
El modelo decide si la usa y cuándo, basándose sobre todo en la descripción que escribiste.
Te devuelve una llamada estructurada con los parámetros rellenados, y se detiene.
Tu código ejecuta la operación real: consulta la base de datos, manda el correo, escribe en el ERP.
Le devuelves el resultado al modelo, que lo lee y decide el siguiente paso.

Dos cosas que nadie te cuenta y que descubrirás por las malas. La primera: la descripción de la herramienta es el verdadero prompt. Si escribes «buscar cliente», el modelo se equivocará al decidir cuándo llamarla; si escribes qué hace, qué devuelve y cuándo no debe usarse, funciona. La segunda: las herramientas declaradas consumen tokens en cada llamada, porque nombres, descripciones y esquemas viajan en el contexto. Veinte herramientas conectadas a un agente son veinte descripciones pagadas cada vez.

MCP: el estándar que ya ha ganado

Hasta hace poco, conectar un agente a una herramienta significaba reescribir la integración para cada modelo. MCP, Model Context Protocol, es el estándar abierto que resolvió el problema. La documentación oficial lo compara con un puerto USB-C para aplicaciones de IA: escribes la integración una vez y la conectas donde quieras.

Aquí está el dato que cambia el panorama y que pocos artículos recogen. El 9 de diciembre de 2025 Anthropic donó MCP a la Agentic AI Foundation, creada dentro de la Linux Foundation junto a otros dos proyectos fundacionales: goose de Block y AGENTS.md de OpenAI. Entre los miembros de primer nivel están Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft y OpenAI.

Por qué te interesa comercialmente: cuando competidores directos meten el mismo protocolo en una fundación neutral, no estás aprendiendo la tecnología de un proveedor, estás aprendiendo la infraestructura del sector. Hoy MCP está soportado por Claude, ChatGPT, Gemini, Microsoft Copilot, Visual Studio Code y Cursor, y Google Cloud lo ha hecho oficial en sus servicios. Si construyes tus integraciones como servidores MCP, el día que el cliente cambie de modelo no reescribes nada.

Memoria, estado y RAG: donde se juega la calidad

Un agente sin memoria es el que te vuelve a pedir el número de pedido en cada mensaje, y es la queja número uno de los usuarios finales. Hay que separar dos cosas distintas:

Memoria corta: el contexto de la conversación en curso. Desaparece cuando termina la sesión.
Memoria larga: lo que el agente recuerda de ese usuario concreto entre sesiones. Hay que guardarla en algún sitio, normalmente en un almacén dedicado.

Después está el RAG, es decir, indexar los documentos del cliente y recuperar los fragmentos correctos para meterlos en el contexto antes de que el modelo responda. Es la parte que decide si el agente es útil o se lo inventa. Y el punto crítico no es el modelo que elijas, es cómo cortas los documentos: partir un contrato cada tantos caracteres, sin respetar artículos y cláusulas, produce respuestas que citan media regla de un sitio y media de otro. En textos legales, médicos o técnicos el corte se hace siguiendo la estructura del documento, no un conteo mecánico.

Regla práctica que aplico siempre: mantén separada la memoria del usuario de la base de conocimiento. Son dos almacenes con ciclos de vida distintos, y mezclarlos es la vía rápida para un agente que confunde lo que sabe con lo que le dijiste ayer.

Los seis niveles, del primer cobro al sistema que corre solo

Los seis niveles para construir y vender agentes IA, de la arquitectura mínima al sistema replicable — La progresión: se sube de nivel solo cuando el anterior ya está cobrado

Nivel 0: entender antes de vender

Antes de proponer nada, elige el sector donde ya tienes ventaja de conocimiento. Si sabes cómo trabaja una clínica dental o una inmobiliaria, ahí diseñarás el mejor agente, porque sabes cuáles son las preguntas de verdad y dónde se atasca el proceso. El potencial de mercado importa menos que el hecho de que sepas qué preguntar en la reunión.

Y define el resultado medible antes que la arquitectura. «Te integro la inteligencia artificial» no se vende. «Bajamos el tiempo de primera respuesta de cuatro horas a dos minutos, y cuando el modelo no está seguro pasa a una persona» sí se vende, porque lleva dentro un número comprobable.

Nivel 1: automatización más una sola llamada IA

El primer cobro no necesita un agente autónomo. Necesita un flujo normal y previsible con un único punto donde decide el modelo. Menos superficie de error, más fácil de explicar, más fácil de cobrar. Cuatro ejemplos que funcionan de verdad, con lo que hace falta para montarlos:

Atención de primer nivel con clasificación de intención. Un webhook recibe el mensaje de WhatsApp o del chat de la web, el modelo clasifica la intención (petición de presupuesto, estado del pedido, reclamación) devolviendo un valor estructurado, y a partir de ahí el flujo normal ejecuta la acción correspondiente o pasa la conversación a una persona. Hace falta el orquestador (n8n o similares), una llamada al modelo y la conexión al sistema de gestión para las respuestas dinámicas. Se vende por cuota, con un compromiso sobre el tiempo de respuesta.

Búsqueda en documentos citando la fuente. Para despachos de abogados, asesorías y consultores: indexas sus documentos y el agente responde citando el punto exacto de donde sacó la información. La parte técnica que lo decide todo es el corte de los textos: un contrato hay que partirlo respetando artículos y cláusulas, no cada tantos caracteres, o la respuesta junta media regla de un sitio y media de otro. Que cite la fuente no es un adorno: es lo que permite al cliente detectar un error al instante.

Cualificación de contactos con puntuación. El agente hace tres o cuatro preguntas por chat, extrae los datos en formato estructurado (presupuesto, urgencia, tipo de petición) y calcula una puntuación que decide si el contacto pasa ya a un comercial o se queda en seguimiento automático. Es el más fácil de aprobar, porque el retorno se ve en la primera semana: menos tiempo del equipo de ventas tirado en contactos fríos.

Seguimientos y recuperaciones basados en el estado. Conectado al sistema de gestión o a la agenda, manda recordatorios, reprograma citas y hace la posventa leyendo el estado real del registro, no un calendario ciego. La diferencia técnica está justo ahí: el agente comprueba la situación actual antes de decidir, así no manda el recordatorio a quien ya ha confirmado.

Cómo se consigue el primer cliente: no proponiendo «un agente IA», que no significa nada para quien te escucha. Detecta un cuello de botella medible en un negocio concreto (cuántas horas al día pasan respondiendo las mismas preguntas, cuántos contactos se quedan sin respuesta más de dos horas) y lleva el flujo específico que lo resuelve. El presupuesto se discute sobre ese número, no sobre la tecnología.

Nivel 2: de flujo a producto empaquetado

Cuando has hecho el mismo trabajo tres veces para el mismo sector, deja de rehacerlo desde cero. El diseño ya lo vendiste una vez: de ahí en adelante lo que vendes es casi todo margen. Esto es lo que se empaqueta de verdad:

El flujo como plantilla con las variables por rellenar. Webhook, clasificación, acción y registro ya montados y exportados: el cliente solo mete sus credenciales y su base documental.
El kit de prompts y esquemas de un sector. El prompt de sistema, los ejemplos que le diste y las descripciones de las herramientas, ya ajustados a inmobiliaria, salud o despachos. Es la parte que te ha costado más intentos y que nadie ve.
La estructura de indexado por sector. Si has entendido cómo hay que cortar y catalogar los documentos de cierto tipo, esa estructura es un producto en sí: no vendes los datos, vendes la forma en que están organizados.
La formación sobre tu propio método. Cómo montaste la cadena completa, documentada paso a paso. Se vende a quien quiere llegar ahí sin repetir todos tus errores.

Dónde venderlo: al principio incluso a mano, mientras compruebas que alguien lo quiere de verdad. Montar la plataforma antes de saber si el producto interesa es la forma más elegante de perder dos meses.

Nivel 3: sistemas que corren sin ti

Aquí el objetivo cambia: el sistema tiene que producir valor incluso cuando tú no lanzas nada. Hacen falta ejecuciones programadas, disparadores por evento y una gestión de errores que no dependa de que tú estés mirando. Tres cosas que se venden por suscripción:

Vigilancia continua con avisos. Una ejecución periódica revisa fuentes que cambian (precios de la competencia, menciones de marca, cambios normativos), compara con el estado guardado la vez anterior y avisa solo si el cambio importa de verdad. El paso que marca la diferencia es la segunda verificación antes de notificar: sin ella, el cliente recibe diez falsas alarmas y en dos semanas lo desactiva todo.
Cadena de investigación para contenidos. Recogida automática de las fuentes del sector, el agente resume y ordena por relevancia, tú pones el ángulo y publicas. La parte técnica no es la redacción, es la ingesta y sobre todo la eliminación de duplicados: la misma noticia llega de seis fuentes y sin control te la encuentras seis veces.
Comparativas técnicas entre plataformas. Hacer correr los mismos casos de prueba en herramientas distintas y publicar los resultados con el método declarado. Es contenido que posiciona bien justamente porque casi nadie lo hace en serio.

El error típico de este nivel es uno solo: no registrar las ejecuciones fallidas. Si el sistema corre sin vigilancia, necesitas un canal que te avise a ti cuando se rompe. Si no, se entera el cliente antes que tú, y esa es una llamada que no quieres recibir.

Nivel 4: integración profunda, donde está el ticket alto

Este nivel exige entender cómo está montado el sistema informático del cliente, no solo saber armar un agente aislado. Es el punto en el que un solo cliente puede valer lo que diez del nivel uno, y en el que desaparece la competencia de quien monta flujos sin código. Cuatro servicios que viven aquí:

Conexión con sistemas de gestión existentes. Cuando el sistema no tiene una interfaz moderna, el camino es una capa intermedia construida por ti, o automatizar la propia interfaz. No es un problema de prompts, es un problema de integración de sistemas, y se paga en consecuencia.
Arquitectura con varios agentes. Un coordinador que reparte tareas entre especialistas: uno consulta los datos, uno redacta, uno revisa el resultado contra las reglas del negocio. Lo que se paga caro no es hacer hablar a los modelos entre ellos, es diseñar qué pasa cuando una pieza falla a medias y hay que retomar el trabajo sin duplicar acciones ya hechas.
Análisis de madurez antes de automatizar. Un trabajo de diagnóstico que dice qué procesos se pueden automatizar hoy y cuáles necesitan antes datos limpios o un acceso programable a los sistemas. Se entrega un plan con la arquitectura propuesta, no una lista de ideas. Es el servicio que abre la puerta a todo lo demás, y se vende incluso por separado.
Mantenimiento con observabilidad. Paneles que muestran qué herramientas llamó el agente, con cuánta latencia y con qué tasa de error, más una batería de comprobaciones que corre cada vez que cambias un prompt para verificar que no se ha roto nada. Es recurrente, casi nadie lo ofrece, y un agente sin esta parte no es un producto: es una demostración.

Para entrar aquí no hace falta ser ingeniero experto, pero sí hacen falta tres cosas concretas: saber leer la documentación de sistemas ajenos, entender cómo funcionan las autenticaciones (claves, accesos delegados, peticiones firmadas) y saber razonar sobre qué pasa cuando una pieza de la cadena responde a medias. Si esos tres puntos te asustan, quédate en el nivel dos y gana dinero, que no es ningún suspenso.

Nivel 5: convertirlo en sistema propio

Cuando ya tienes varios clientes o un producto que corre solo, el trabajo cambia de naturaleza: ya no construyes agentes, construyes la forma en que se replican sin depender de ti. Cuatro hábitos que separan a quien crece de quien se queda haciendo soporte:

Versiona prompts, esquemas y flujos como código desde el primer cliente. Un prompt modificado sin histórico es la causa número uno del clásico «la semana pasada funcionaba y ahora no sé qué ha pasado».
Construye un repositorio interno de plantillas por sector. Lo que la primera vez te costó una semana tiene que costarte un día a la quinta. Si eso no pasa, no estás creciendo, solo estás trabajando más.
Sube los precios antes de sentirte saturado, no después. Si te das cuenta de que aplazas los mantenimientos porque no tienes tiempo, el precio anterior ya era demasiado bajo.
Mide el coste real por cliente juntando tokens consumidos, horas de mantenimiento e incidencias, y compáralo con lo que facturas. Un cliente que consume mucho y se rompe a menudo puede rendir menos que tres clientes simples del nivel uno, y eso es lo que siempre se descubre demasiado tarde.

Cuánto cobrar por los agentes IA

La pregunta que más me llega. No hay tarifa fija, pero hay tres estructuras que aguantan, y una que no:

Estructura	Cómo funciona	Cuándo tiene sentido
Alta más cuota	Un importe por construirlo y luego una mensualidad por mantenerlo en marcha	Es el modelo estándar, el que recomiendo por defecto
Cuota con compromiso de servicio	La mensualidad va ligada a parámetros medibles: tiempo de respuesta, porcentaje de consultas resueltas	Cuando el cliente ya tiene números propios que mejorar
Licencia del producto empaquetado	Vendes el kit ya listo para el sector, con la configuración a tu cargo	Del tercer cliente del mismo tipo en adelante
Solo pago único	Construyes, entregas, desapareces	Casi nunca: los modelos cambian, las integraciones se rompen y la culpa será tuya igual

Dos cosas que hay que meter en el precio y que los presupuestos improvisados olvidan siempre: el consumo de tokens es un coste variable tuyo, así que hay que estimarlo antes y revisarlo tras los primeros meses reales; y el mantenimiento no es un favor, es la partida que hace sostenible el trabajo en el tiempo. Si no lo cobras, el cliente número cinco te impedirá trabajar para el número seis.

Las cuatro palancas para no quemar el presupuesto

El coste de un agente no se dispara por el precio del modelo, se dispara por cómo lo has construido. Estas cuatro palancas valen más que cualquier comparativa de tarifas:

Límite de pasos por ejecución. Un tope de iteraciones impide que el agente repita hasta el infinito un intento que no funciona.
Tope de gasto mensual con aviso. No esperes a la factura: pon un umbral que te avise cuando el consumo supera lo previsto.
Menos herramientas declaradas. Cada herramienta conectada viaja en el contexto en cada llamada. Veinte herramientas cuando hacen falta cinco son quince descripciones pagadas cada vez.
No releer todo en cada paso. Donde el proveedor ofrece caché de contexto, usarla cambia la cuenta de forma clara en los flujos agénticos, que releen las mismas instrucciones decenas de veces.

Los errores técnicos que cuestan un mes

Confundir un prompt largo con un agente. Sin herramientas y sin ciclo no hay autonomía, hay un texto elaborado.
No poner límites de pasos ni de gasto. Es el error que se paga literalmente, y te enteras con la factura.
Dejar la observabilidad para después. Sin registros, cuando algo se rompe en producción estás adivinando.
Cortar los documentos a lo bruto en sectores donde la estructura del texto es el contenido.
Tratar los prompts como configuración desechable en vez de como código versionado. Es la causa número uno del clásico «la semana pasada funcionaba».
Diseñar varios agentes para un problema que no necesitaba ninguno. La autonomía se añade cuando hace falta, no porque queda bien.

El stack, categoría por categoría

Categoría	Herramientas	Para qué sirve
Modelos	Claude, GPT, Gemini vía API	El motor de razonamiento, con tool calling nativo
Orquestación	LangGraph, CrewAI, SDK de los proveedores	Flujos con varios pasos y varios agentes coordinados
Automatización	n8n, Make, Zapier	La parte previsible del flujo, donde el modelo no hace falta
Protocolo de herramientas	MCP	Exponer datos y herramientas una sola vez, para todos los modelos
Bases vectoriales	Pinecone, Weaviate, pgvector	La recuperación de documentos para el RAG
Observabilidad	LangSmith y similares	Trazar ejecuciones, latencia, errores y regresiones
Versionado	Git	Prompts, esquemas y flujos tratados como código

Un consejo para elegir: si el cliente ya tiene una base de datos Postgres, pgvector te evita añadir un servicio más que mantener y que facturar. La solución más elegante casi siempre es la que añade menos piezas.

Mi opinión, de alguien que vende webs y no modelos

Llevo más de diez años trabajando con webs, contenidos y posicionamiento, y en los últimos dos años estas herramientas han entrado en el trabajo diario. Te digo lo que más he visto: los clientes no compran «un agente». Compran una hora al día que dejan de pasar respondiendo las mismas tres preguntas. Quien vende la tecnología sufre; quien vende el tiempo liberado cierra.

La segunda cosa es menos cómoda de decir: casi todo lo que se pide hoy se resuelve con una automatización bien hecha y un único punto inteligente. Construir el agente autónomo porque es más interesante de diseñar es un error que pagas tú, no el cliente. Y si la web sobre la que tiene que funcionar es lenta o está mal montada, el agente no salva nada: para eso hace falta antes una web bien hecha, y después lo demás.

Si quieres meterle mano gratis antes de invertir, hay caminos serios, empezando por los cursos gratuitos sobre IA. Y hay algo mejor: AWS ha abierto ocho certificaciones prácticas gratuitas, y una es justo de Agentic AI, con prueba en un entorno real. Sobre los modelos conviene saber qué se mueve: el último salto lo tienes en el artículo sobre Claude Fable 5.1, donde el recorte en el coste de la caché afecta justo al trabajo agéntico.

En conclusión

No hace falta ser ingeniero para construir y vender estos sistemas. Hace falta entender la arquitectura lo suficiente como para hacer el diagnóstico correcto, elegir un sector donde ya eres mejor que la media, y vender un número en vez de unas siglas. Empieza por el nivel uno esta semana: un flujo previsible, un único punto decidido por el modelo, un resultado medible y un precio desde el primer día. Lo demás llega después, y llega antes de lo que crees.

Preguntas frecuentes

¿Cuál es la diferencia entre un chatbot y un agente?

El chatbot responde con una sola llamada al modelo. El agente tiene herramientas que puede ejecutar, un ciclo que se repite y un estado que conserva. Sin esas tres cosas, por largo que sea el prompt, sigue siendo un chatbot.

¿Qué es MCP y por qué se habla tanto de él?

Es el estándar abierto para conectar los modelos a herramientas y datos externos sin reescribir la integración para cada uno. Nació en Anthropic y desde diciembre de 2025 lo gestiona la Agentic AI Foundation de la Linux Foundation, con Google, Microsoft, OpenAI, AWS y otros entre sus miembros principales.

¿Hace falta saber programar?

Para los dos primeros niveles no: bastan las herramientas de automatización y saber leer una documentación. Del nivel cuatro en adelante sí, porque entras en autenticaciones, sistemas de empresa y gestión de fallos parciales.

¿Mejor un agente autónomo o un flujo automático?

En la mayoría de los casos, el flujo automático con un punto de decisión inteligente. La propia Anthropic recomienda añadir autonomía solo cuando mejora demostrablemente el resultado, porque cuesta más y acumula errores.

¿Cuánto cuesta mantenerlo cada mes?

Depende de cuántos tokens consuma y de cuántas integraciones tenga. El consumo hay que estimarlo antes y comprobarlo en los primeros meses reales, porque es un coste variable que recae en ti: un agente que relee contextos grandes en cada paso puede costar mucho más de lo que parece en pruebas.

¿Qué hace falta para que no se equivoque con los documentos?

Un buen trabajo de indexado: cortar los documentos respetando su estructura, mantener separada la memoria del usuario de la base de conocimiento, y hacer que el agente cite la fuente exacta, para que el error se vea enseguida en vez de pasar desapercibido.

¿Por dónde conviene empezar para el primer cliente?

Por un cuello de botella medible en un negocio que ya conoces: tiempo de primera respuesta, contactos perdidos, horas dedicadas a consultas repetitivas. Se propone ese flujo concreto, no «la inteligencia artificial» en general.

Fuentes

Anthropic: construir agentes eficaces, la diferencia entre workflow y agentes y los patrones de arquitectura.
Documentación oficial sobre tool use: cómo se define una herramienta y cómo funciona el ciclo de llamada.
Model Context Protocol: la especificación y la documentación oficial del estándar.
Linux Foundation: la creación de la Agentic AI Foundation y los proyectos donados.
Google Cloud: el soporte oficial de MCP en los servicios de Google.

Daniele Forciniti

Soy Daniele Forciniti, un experto en diseño web y SEO con más de 10 años de experiencia y diversas certificaciones profesionales. Estoy especializado en HTML y CSS, y utilizo CMS como WordPress. Soy el mayor experto en España en WIX y WIX Studio, y también me encargo del posicionamiento web SEO en buscadores y de marketing digital. Me apasiona mi trabajo y me actualizo constantemente para ofrecer soluciones innovadoras y de alta calidad a mis clientes.