¿Cuántas herramientas puede ver un agente de IA antes de empezar a equivocarse?

Hay una demostración que sale siempre bien y una implantación que sale mal por la misma razón. En la demostración, el agente de IA tiene delante seis herramientas y responde perfecto. En la implantación, el mismo modelo tiene delante el ERP completo de un grupo funerario —contratos de previsión, servicios, parque cementerio, contabilidad, nómina, recaudo, conversaciones de WhatsApp— y empieza a llamar a la herramienta equivocada, a inventar parámetros y a detenerse antes de terminar. No cambió el modelo. Cambió cuánto le mostraste.

Esto ya no es una intuición de ingeniería: está medido. Y lo interesante para un comité de dirección no es la caída, que era previsible, sino cuánto se recupera y cuánto no. Lo que no se recupera es exactamente lo que hay que convertir en regla de escalamiento a un humano. Este artículo es el caso de uso de esa capa —la curación del catálogo por intención— con las cifras reales del conector MCP de SFUN y la evidencia publicada en 2026.

1. El problema de negocio: el agente que lo sabe todo acierta menos

El argumento comercial de la IA sobre el ERP es que el agente ve todo el negocio. El argumento es cierto y es justamente el que crea el problema: cada herramienta que expones consume contexto —su nombre, su descripción, el esquema de sus parámetros—, y ese consumo compite con la pregunta del usuario. Cuando el catálogo crece, el modelo no falla porque le falte información: falla porque le sobra.

En una funeraria grande esto se ve en concreto. La jefa de cartera pregunta «¿qué contratos de previsión de la sede norte caen en mora este mes?». En un catálogo sin curar, esa frase toca contratos, recibos de caja, facturas de venta, referencias de pago, planes, débitos automáticos y órdenes de cobro, y cada uno de esos objetos tiene métodos parecidos con nombres parecidos. El agente elige uno. Si elige mal, devuelve una cifra que existe, que se parece a la correcta y que nadie va a auditar. Ese es el modo de falla caro: no el error visible, sino el número plausible.

Lo que cuesta hoy es doble. Primero, el retrabajo: cada respuesta del agente que no se puede confiar obliga a rehacerla a mano, con lo que el proyecto de IA agrega un paso en vez de quitarlo. Segundo, y más caro, la pérdida de adopción: basta con que el comité vea dos números malos para que el agente deje de usarse, y a partir de ahí la inversión ya no se recupera aunque la capa técnica se arregle después.

2. Lo que dice la evidencia de 2026 (y por qué es inusualmente aplicable)

El trabajo más directamente utilizable es Scaling Enterprise Agent Routing, de Kellen Gillespie y Robyn Perry. No es un experimento de laboratorio: se hizo sobre un asistente empresarial desplegado, con un catálogo de producción de 110 agentes y 584 herramientas, y con tres modelos de frontera. Los resultados que importan a quien decide una compra son tres.

El cuarto punto es el que casi nunca aparece en una propuesta comercial y es el más importante: parte de la degradación no se arregla con mejor recuperación. Cuando dos herramientas son genuinamente confundibles —«registrar pago» y «registrar recibo de caja», por ejemplo—, ni un buscador perfecto resuelve la ambigüedad, porque la ambigüedad está en la pregunta, no en el catálogo. Eso no es un defecto a corregir: es una condición de diseño que obliga a decidir, por adelantado, qué hace el agente cuando no está seguro.

Sobre el umbral concreto hay una referencia práctica que conviene citar con su origen: la nota de ingeniería de Kong sobre gobierno de herramientas MCP recoge la guía de Anthropic según la cual el acierto de selección se degrada de forma notable más allá de 30 a 50 herramientas, y describe el fenómeno con un nombre útil, context rot: a medida que la entrada se alarga, el modelo alucina parámetros, llama a la herramienta equivocada y se salta instrucciones. Su dato de escala es doméstico y por eso es convincente: un solo servidor MCP de uso común expone más de 40 herramientas, y conectar unos pocos deja al agente con más de cien encima antes de que empiece a trabajar.

3. Qué datos del ERP intervienen: la superficie real, contada

Antes de decidir qué esconder hay que saber qué hay. Estas son las cifras del catálogo curado del conector MCP de SFUN, contadas sobre el código el 30 de agosto de 2026. No son estimaciones: son el resultado de contar los archivos de curación módulo por módulo.

El reparto de las 1.810 entidades explica por qué la curación no puede ser uniforme. Los módulos no pesan igual: erpnext aporta 495, previsión exequial 287, frappe 262, recursos humanos 146, servicios funerarios 57, parque cementerio 36 y contabilidad de Colombia 17. La entidad que más importa a una operación funeraria —la del servicio— vive en uno de los módulos más pequeños del catálogo. Un buscador ingenuo la enterraría bajo quinientas entidades genéricas de ERP.

Los 466 métodos útiles están clasificados por categoría, y la distribución dice de qué trata realmente el sistema: servicio 201, facturación 58, pago 50, contrato 34, chat 32, correo 29, impuesto 15, más una bolsa de 44 sin familia clara. Esa etiqueta de categoría no es documentación: es la coordenada que permite acotar una búsqueda a un frente del negocio. Y hay una marca adicional por método que indica si está disponible para el agente conversacional —hoy 31 de los 466—, que es la forma explícita de decir que el agente que habla con una familia no tiene el mismo catálogo que el que asiste a la contadora.

4. Cómo se arma el caso con MCP, paso a paso

La arquitectura tiene tres capas y la clave está en que el catálogo grande nunca entra al contexto del modelo. Entra un catálogo de trece herramientas fijas, y una de ellas es la que abre la puerta al resto bajo demanda.

Capa 1 — Trece herramientas planas, y ninguna más

Lo que el agente ve al conectarse es una lista corta y estable: identificarse, buscar por intención, enumerar entidades de un módulo, pedir el esquema de una entidad, listar y leer documentos, crear y actualizar, ejecutar una transición de documento, ejecutar una acción curada, invocar un método útil y el par de herramientas que gestiona la subida de archivos. Trece. Está por debajo del umbral de 30 a 50 en el que la literatura ubica la degradación, y se mantiene ahí aunque el ERP crezca: agregar un módulo nuevo no agrega herramientas, agrega contenido buscable.

Capa 2 — La búsqueda por intención es la pieza que recupera el acierto

La herramienta de búsqueda recibe una intención en lenguaje natural —«contratos en mora de la sede norte», «programar una velación», «conciliar recaudo de la pasarela»— y devuelve un conjunto acotado de candidatos. Por omisión devuelve 25 ítems y nunca más de 50, lo que significa que el agente jamás decide entre miles de opciones: decide entre unas pocas decenas ya filtradas. Esto es exactamente el shortlisting por embeddings que en el estudio de ruteo empresarial recuperó entre 10 y 11 puntos de F1.

Dos detalles de implementación importan más de lo que parece. El primero es que la búsqueda es vectorial con fallback léxico: si el servicio de embeddings no responde, no se cae, degrada a coincidencia de texto. El segundo es que el fallback léxico no es un grep: lleva un diccionario de sinónimos del dominio funerario en español. «Fallecido» expande a difunto, occiso, deceso, óbito y fenecido; «velación» expande a velorio, sala, exequias y cortejo; «parque» expande a cementerio, camposanto y jardín. Es la traducción de un problema conocido: el vocabulario con el que una funeraria colombiana nombra las cosas no es el mismo con el que las nombra una peruana, y el catálogo está escrito en un tercer vocabulario, el del sistema.

Capa 3 — Orden fijo, y cada resultado dice cómo usarse

El resultado no llega revuelto. Llega en un orden deliberado —acciones primero, luego entidades, luego métodos— y cada ítem trae dos campos: qué tipo es y cuál es el paso siguiente para accionarlo. Las acciones van primero porque resuelven la operación completa en un paso; si existe una acción de «programar exequias», el agente no tiene por qué reconstruirla componiendo cuatro escrituras sobre tres entidades. Menos pasos es menos superficie de error, y el estudio de descripciones de herramientas advierte de lo contrario con un número: mejorar las descripciones subió la tasa de éxito 5,85 puntos de mediana, pero aumentó los pasos de ejecución un 67,46 %. Cada paso extra es una oportunidad de fallar.

A esto se suma una decisión pequeña con efecto grande: los resultados se recortan antes de entregarse. Las descripciones se cortan a 280 caracteres y las listas de valores a cinco elementos. Sin ese recorte, veinticinco resultados con sus esquemas completos vuelven a llenar el contexto que la preselección acababa de liberar, y el problema regresa por la puerta de atrás.

Quién lo usa y con qué frecuencia

• El agente conversacional que atiende a las familias, en cada conversación. Su catálogo es el más recortado: 31 métodos marcados como disponibles para él, de 466. No es una limitación técnica, es una decisión editorial sobre qué tiene sentido que haga un agente que habla con un doliente.
• La dirección y las jefaturas, varias veces al día, para consultas de indicadores en lenguaje natural. Aquí el catálogo relevante es el de lectura, y el criterio de curación es distinto: importa más la cobertura que la brevedad.
• El equipo de operación, de forma continua, sobre servicios, salas, traslados y agenda. Es el frente con más métodos útiles —201 de 466— y por eso el que más se beneficia de acotar por módulo en la búsqueda.
• Contabilidad y cartera, en los picos de cierre y de gestión de mora. Es el frente donde un ruteo equivocado produce el número plausible y equivocado, así que es el primero donde conviene exigir que la respuesta cite el documento del que salió.

5. El residuo irreducible: cuándo el agente debe rendirse

Aquí está la parte que separa una implantación seria de una demostración. Si la preselección recupera diez u once puntos de los dieciséis a veintitrés que se perdieron, queda un resto. Y el estudio añade que el propio techo del oráculo —lo máximo alcanzable incluso con recuperación perfecta— baja unos diez puntos al crecer el catálogo. Ese resto no es un defecto pendiente de arreglo: es la parte del problema que no se resuelve mostrando mejor las herramientas.

La consecuencia de diseño es directa: el sistema tiene que tener una salida para cuando no está seguro, y esa salida tiene que ser barata. En la práctica significa tres reglas. Que ante candidatos empatados el agente pregunte en vez de elegir. Que toda respuesta numérica venga con el documento o el informe del que salió, para que verificarla cueste un clic. Y que exista una lista corta de intenciones —las que tocan dinero, cobertura o el cuerpo— donde el agente nunca decide, solo prepara.

Hay un segundo dato que refuerza esto desde otro ángulo. El benchmark MCP-Atlas evaluó 20 modelos sobre 1.000 tareas verificadas por expertos, contra 36 servidores MCP reales y 220 herramientas, y encontró que el 63,3 % de los fallos diagnosticados son cognitivos, no de llamada a herramienta: el agente llama bien y falla después, por parada prematura o por sintetizar mal lo que recibió. Traducido a un proyecto: aunque resuelvas el ruteo por completo, casi dos tercios de tus fallos van a estar en el tramo que sigue. Curar el catálogo es necesario y no es suficiente.

6. El bucle de mejora continua

La curación no es una instalación, es una rutina. Y a diferencia de otros casos de esta serie, esta rutina es barata: la hace una persona técnica en un par de horas por semana, y su insumo son las preguntas que la gente ya está haciendo.

7. Gobierno y límites

La curación por exactitud y el control por seguridad se apoyan en la misma pieza, y por eso conviene decir dónde se tocan. En SFUN el filtro no es solo temático: los resultados se filtran por los permisos de la persona que está preguntando. Las entidades se acotan a lo que ese usuario puede leer y las operaciones ofrecidas salen de sus permisos de rol. El efecto colateral es feliz: un catálogo filtrado por permisos es, además, un catálogo más corto — es decir, la medida de seguridad también mejora el acierto.

Es el mismo principio que aplica la industria de infraestructura desde fuera del sistema: en el patrón de gateway descrito por Kong, la identidad del solicitante determina qué herramientas se le listan, con negación por omisión, de modo que un agente de seguridad ve 2 de más de 40 y uno de integración continua ve 7. La diferencia de enfoque es instructiva. El gateway filtra en la red y no sabe nada del negocio; el filtro por permisos de un ERP ya sabe quién es el usuario y qué puede ver, así que hace la misma reducción con criterio de negocio y sin duplicar la política de acceso en dos lugares. Para una funeraria, que tiene datos de salud y de causa de muerte, mantener una sola fuente de verdad de permisos no es una elegancia: es la diferencia entre poder responderle a un regulador y no poder.

• Lo que nunca se automatiza, aunque el ruteo sea perfecto: negar una cobertura, condonar una deuda, ejecutar un cobro sobre un medio de pago, modificar un asiento contable cerrado y cualquier operación sobre el cuerpo del fallecido. En SFUN esto no depende de una instrucción: las funciones que ejecutan cobros están entre las 694 bloqueadas, así que la capacidad no existe en el catálogo del agente.
• Datos sensibles del doliente: el agente conversacional trabaja con 31 métodos de 466 justamente porque su superficie tiene que ser mínima. Ampliarla es una decisión editorial que se toma método por método, no un ajuste de configuración.
• Revisión humana: toda respuesta que alimente una decisión de dirección debe traer el documento o el informe de origen. No por desconfianza en el modelo, sino porque el residuo irreducible existe y su costo de verificación tiene que ser bajo.
• Brecha declarada: hoy no existe una bitácora de invocaciones por herramienta que permita medir con precisión qué se llamó, qué se eligió mal y con qué frecuencia. Sin ella, el bucle de la sección anterior se apoya en revisión manual de casos. Es hoja de ruta, no una función disponible, y es la pieza que convertiría los KPIs siguientes en automáticos.

8. KPIs, con línea base y meta

Ninguno de estos indicadores requiere un proyecto de analítica: se miden sobre una muestra de cien preguntas reales, etiquetadas a mano por quien conoce el negocio. La línea base se mide, no se supone — y conviene medirla antes de tocar nada, porque después ya no se puede.

9. Hoja de ruta de adopción

Semana 1 — Contar y etiquetar

1. Cuenta tu catálogo real. Cuántas entidades, cuántos métodos publicados, cuántos habilitados. Si nadie de tu organización sabe ese número, esa es la primera conclusión del proyecto.
2. Junta 100 preguntas reales de las áreas que van a usar el agente. Reales significa transcritas de lo que la gente ya pregunta, no redactadas por el equipo de tecnología.
3. Etiqueta a mano la herramienta correcta de cada una. Este es el activo del proyecto: sin él no hay línea base ni forma de saber si algo mejoró.

Mes 1 — Curar por intención

1. Clasifica los métodos útiles por categoría de negocio y deja explícita la bolsa de los que no encajan en ninguna. Esa bolsa es la deuda técnica del catálogo.
2. Escribe el diccionario de sinónimos de tu operación, país por país si operas en varios. Es el trabajo más barato y el que más sube la cobertura de la preselección.
3. Sube a acción curada las tres operaciones más frecuentes que hoy exigen componer varias escrituras. Menos pasos, menos fallos.
4. Activa la preselección y vuelve a medir contra las mismas 100 preguntas. Si la mejora es menor de 10 puntos, el problema está en las descripciones, no en la búsqueda.

Trimestre 1 — Cerrar el bucle

1. Instala la rutina semanal de revisión de intenciones sin resultado y de elecciones equivocadas, con dueño y con hora en el calendario.
2. Poda. Todo método útil sin invocaciones en 90 días sale del catálogo del agente, sin ceremonia y de forma reversible.
3. Define y publica la lista de intenciones que nunca se resuelven solas, y verifica que las capacidades correspondientes estén bloqueadas de verdad, no solo desaconsejadas en un prompt.
4. Pide la bitácora de invocaciones a tu proveedor. Mientras no exista, acepta que estás midiendo por muestreo y dilo en el comité.

10. Cinco errores que hacen fracasar este caso

1. Evaluar al proveedor con una demostración de seis herramientas. Es el error caro. La degradación aparece con el catálogo completo, y con datos reales el nivel absoluto queda entre 10 y 15 puntos por debajo del entorno controlado. Pide la prueba con tu catálogo, con tus preguntas y con tus permisos.
2. Creer que un modelo mejor resuelve el problema. La caída de 16 a 23 puntos se midió en los tres modelos de frontera evaluados. Es una propiedad del tamaño del catálogo, no de la marca del modelo.
3. Exponerlo todo «para que el agente tenga contexto». Cada herramienta expuesta se paga en contexto y compite con la pregunta. El catálogo del agente conversacional de una funeraria debe ser mínimo por diseño, no máximo por generosidad.
4. Reescribir todas las descripciones de golpe. Mejora la mediana y empeora uno de cada seis casos, además de alargar la ejecución. Se hace por lotes, midiendo, y se revierte lo que empeore.
5. No dejar salida cuando el agente duda. Si no hay escalamiento, el residuo irreducible no desaparece: se convierte en respuestas seguras y equivocadas. Una tasa de escalamiento de cero no es una buena noticia.

11. Cinco preguntas para el comité antes de firmar

Si estás evaluando IA sobre tu ERP funerario, estas cinco preguntas separan a un proveedor que resolvió el problema de uno que no lo ha visto todavía. Ninguna requiere conocimiento técnico para hacerla; todas lo requieren para responderla.

1. ¿Cuántas herramientas ve el agente al conectarse? Si la respuesta es «todas las que necesite», no hay capa de curación. Si es un número menor de cincuenta, hay conversación.
2. ¿Cómo encuentra el agente lo que no ve? Debe existir una búsqueda por intención con un límite explícito de resultados, y debe funcionar aunque el servicio de embeddings esté caído.
3. ¿El catálogo se filtra por los permisos de quien pregunta? Si el agente ve lo mismo para la jefa de cartera que para el auxiliar de sala, la política de acceso está duplicada o no existe.
4. ¿Qué hace el agente cuando dos herramientas empatan? La respuesta correcta es «pregunta». Cualquier otra implica que alguien decidió que el sistema adivine sobre datos de un doliente.
5. ¿Cómo mido si el ruteo mejora o empeora? Pide el mecanismo, no la promesa. Si no hay bitácora de invocaciones, que se diga, y que se acuerde medir por muestreo mientras tanto.

Preguntas frecuentes

¿Cuántas herramientas son demasiadas para un agente de IA?

La referencia práctica más citada ubica la degradación notable del acierto de selección más allá de 30 a 50 herramientas. Pero el número exacto importa menos que la forma de la curva: el estudio sobre un asistente empresarial desplegado midió una caída de 16 a 23 puntos de F1 al pasar de 10 a 110 agentes con 584 herramientas. La conclusión operativa es la misma en cualquier umbral: un ERP funerario tiene miles de entidades y métodos, así que mostrarlos directamente no es una opción y la única pregunta real es cómo se acotan.

¿No se arregla esto simplemente con un modelo más nuevo?

No. La degradación se midió en los tres modelos de frontera evaluados, y el techo alcanzable incluso con recuperación perfecta también baja unos diez puntos al crecer el catálogo. Es decir: hay una parte del problema que es estructural del tamaño del catálogo y no de la capacidad del modelo. Un modelo mejor sube el punto de partida; no cambia la pendiente.

¿Qué gana una funeraria con esto, en términos de negocio?

Gana que las respuestas del agente se puedan usar sin rehacerlas. El costo de un ruteo malo en una operación funeraria no es un error visible: es una cifra de cartera plausible y equivocada que llega a un comité. Curar el catálogo es lo que convierte al agente de una curiosidad en una herramienta de la que se puede depender, y es la diferencia entre un piloto que se abandona a los tres meses y uno que se extiende a otras áreas.

¿Esto es lo mismo que restringir los permisos del agente?

Se apoyan en la misma pieza y resuelven cosas distintas. Restringir permisos responde a «qué no debe poder hacer», y está tratado en el artículo de gobierno de agentes. Curar el catálogo responde a «qué debe ver para acertar». La buena noticia es que el filtro por permisos también acorta el catálogo, así que la medida de seguridad mejora el acierto de paso. La mala es que lo contrario no se cumple: un catálogo bien curado no es, por sí solo, un catálogo seguro.

¿Cómo funciona si operamos en varios países con vocabularios distintos?

Es precisamente el caso que atiende el diccionario de sinónimos del dominio. El sistema nombra las cosas de una manera, la operación colombiana de otra y la peruana de una tercera, y la búsqueda tiene que reconciliarlas: «fallecido» y «occiso» y «óbito» apuntan al mismo objeto. En un grupo multipaís, escribir ese diccionario por operación es la tarea de mayor retorno del primer mes, y no requiere tocar ni una línea del ERP.

Si curo el catálogo, ¿ya no falla el agente?

Falla menos, y falla en otro sitio. El benchmark sobre 36 servidores MCP reales y 220 herramientas encontró que el 63,3 % de los fallos diagnosticados son cognitivos —el agente llama bien a la herramienta y después se detiene antes de tiempo o sintetiza mal—, no de llamada a herramienta. Curar el catálogo es la condición necesaria; el tramo siguiente se cubre con verificación humana barata y con la obligación de citar la fuente de cada dato.

¿Qué de todo esto funciona hoy en SFUN y qué es hoja de ruta?

Funcionan hoy las tres capas descritas: las 13 herramientas planas, la búsqueda por intención con búsqueda vectorial, fallback léxico, diccionario de sinónimos y límite de 25 resultados, el catálogo curado de 1.810 entidades y 466 métodos útiles con 694 bloqueados, las 20 acciones multi-paso, los recortes anti-saturación y el filtro por permisos del usuario. Es hoja de ruta la bitácora de invocaciones por herramienta, que es lo que permitiría medir el acierto de ruteo de forma automática en vez de por muestreo manual. Puedes ver la capa completa en la página del módulo SFUN MCP.

Referencias

• K. Gillespie y R. Perry — Scaling Enterprise Agent Routing: Degradation, Diagnosis, and Recovery, arXiv:2606.17519. Fuente de la caída de 16 a 23 puntos porcentuales de F1 de ruteo al pasar de 10 a 110 agentes sobre un asistente empresarial desplegado con 584 herramientas, de la recuperación de +10 a +11 pp con shortlisting por embeddings (+10 a +17 pp en datos de producción, con nivel absoluto 10 a 15 pp por debajo) y de la caída de ~10 pp del techo del oráculo: arxiv.org/abs/2606.17519.
• C. Bandi, R.-G. Dumitru, B. Hertzberg y otros — MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers, arXiv:2602.00933. Fuente de las 1.000 tareas verificadas por expertos sobre 36 servidores MCP reales y 220 herramientas con 20 modelos de seis proveedores, del pass rate máximo de 82,2 % con umbral de cobertura de 0,75 y del 63,3 % de fallos cognitivos frente a fallos de llamada a herramienta, con taxonomía diagnóstica de 11 categorías: arxiv.org/abs/2602.00933.
• M. M. Hasan, H. Li, G. K. Rajbahadur, B. Adams y A. E. Hassan — Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Improving AI Agent Efficiency with Augmented MCP Tool Descriptions, arXiv:2602.14878. Fuente del 97,1 % de herramientas con al menos un defecto de descripción y del 56 % que no declara su propósito con claridad sobre 856 herramientas en 103 servidores, y del efecto de aumentar las descripciones: +5,85 pp de mediana en tasa de éxito, +15,12 % de cumplimiento parcial, +67,46 % de pasos de ejecución y regresión en el 16,67 % de los casos: arxiv.org/abs/2602.14878.
• Kong Inc. — MCP Tool Governance: Security Meets Context Efficiency, nota de ingeniería. Fuente del concepto de context rot, de la guía citada de Anthropic sobre degradación del acierto de selección más allá de 30 a 50 herramientas, y del patrón de filtrado por identidad del solicitante con negación por omisión en el que un agente de seguridad ve 2 herramientas de más de 40 y uno de integración continua ve 7: konghq.com.
• Los tres identificadores de arXiv citados arriba se verificaron uno por uno contra la interfaz de consulta de arXiv el 30 de agosto de 2026, comprobando título, autores y cifras citadas.
• Las cifras del catálogo de SFUN —1.810 entidades curadas en 34 módulos, 2.974 métodos inventariados en 29 módulos, 466 curados como útiles con su reparto por categoría, 694 bloqueados por la auditoría de seguridad, 20 acciones multi-paso, 13 herramientas planas, límite de 25 resultados por búsqueda (máximo 50), recorte de descripciones a 280 caracteres y de listas a 5 elementos, búsqueda vectorial con fallback léxico y diccionario de sinónimos del dominio— se verificaron el 30 de agosto de 2026 contando directamente sobre el código del conector MCP. La bitácora de invocaciones por herramienta se presenta explícitamente como hoja de ruta y no como función disponible.