¿Puede un agente de IA usar tu producto, o solo leer sobre él?

Resumen

Ser legible para un agente y ser usable por uno son proyectos distintos, y la mayoría de los equipos solo ha hecho el primero. Legible significa que un asistente puede descargar, interpretar, citar y atribuirte. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y ser rechazado cuando corresponde. Lo segundo es sobre todo un problema de autorización, identidad y semántica de errores más que de modelo, y su ritmo lo marca la precisión con la que puedes decir no, porque un error de legibilidad cuesta una cita mientras que uno de autorización cuesta un incidente. Una superficie de herramientas usable necesita cinco cosas: identidad delegada que exprese qué agente actúa por qué usuario y en qué alcance, autorización aplicada en la capa de datos y no en el prompt, claves de idempotencia porque los agentes reintentan ante timeouts que malinterpretan, mensajes de error que nombren el campo que falló para que el modelo se corrija en lugar de entrar en bucle, y descubrimiento mediante MCP y agent skills publicadas. MCP es el transporte y no el modelo de autorización; tratarlo como tal es el error habitual. Una secuencia defendible es herramientas de solo lectura, después un mapa publicado, después una escritura de bajo riesgo detrás de aprobación humana, y después ampliar solo donde el registro de auditoría muestre un comportamiento consistentemente correcto. Hoy nadie puede cuantificar los ingresos que llegan por agentes, así que el argumento para los primeros pasos se apoya en que son baratos y útiles para las integraciones humanas de todos modos.

Ser legible para un agente y ser usable por uno son proyectos distintos, y casi todos los equipos han hecho solo el primero. Legible significa que un asistente puede resumirte y citarte. Usable significa que puede completar una tarea en tu producto en nombre de una persona concreta, y que puede ser detenido cuando corresponde.

Lo segundo no es, en su mayor parte, un problema de modelo. Es un problema de autorización, identidad y semántica de errores, y por eso aterriza en ingeniería y no en marketing.

¿Quieres que un agente complete una tarea real contra tu producto, con límites que aguanten?

Hablar de la superficie

Dos preguntas distintas

	Legible	Usable
Qué hace el agente	Descarga, interpreta, cita, atribuye	Se autentica, llama, cambia estado, informa de vuelta
Superficie	HTML, espejo en Markdown, llms.txt, JSON-LD	Herramientas con esquemas, identidad, permisos, auditoría
Fallo	Estás ausente de la respuesta	Pasa algo que no debería haber pasado
Coste de equivocarse	Atención perdida	Datos, dinero o confianza perdidos

Esa última fila es la razón de que la segunda columna lleve más tiempo. Un error de legibilidad te cuesta una cita. Un error de autorización te cuesta un incidente, así que el ritmo del trabajo lo marca la seguridad con la que puedes decir no.

Si la primera columna aún no está hecha, empieza ahí. Nuestra guía de webs legibles por agentes lo cubre, y es una fracción del esfuerzo.

Qué exige de verdad "usable"

Una superficie de herramientas que un agente pueda operar necesita cinco cosas, y las interesantes no son la API.

Identidad que no sea la del agente. El agente actúa por un usuario o un inquilino. Si tus tokens no pueden expresar "este agente, en nombre de esta persona, para este alcance, hasta este momento", en la práctica cada llamada es una llamada de administrador.
Autorización en la capa de datos. Filtrar en el prompt no es control de acceso. El límite va donde se ejecuta la consulta, para que una instrucción persuasiva no pueda ensancharlo.
Idempotencia. Los agentes reintentan. Reintentan ante timeouts que malinterpretan y respuestas parciales que no entendieron. Toda llamada que cambie estado necesita una clave que convierta el segundo intento en una operación nula.
Semántica de errores sobre la que un modelo pueda actuar. Un 400 que dice "petición inválida" produce un bucle de reintentos. Uno que dice qué campo falló y qué forma esperaba produce una llamada corregida. Esto es documentación como superficie de control.
Descubrimiento. Algo tiene que decirle al agente que las herramientas existen, cuánto cuestan y para qué son. Eso es lo que hacen MCP y las agent skills publicadas.

Dónde encaja MCP y dónde no

MCP te da una forma estándar de exponer herramientas y recursos a un modelo, y es el transporte correcto. No es un modelo de autorización, y tratarlo como si lo fuera es el error más común en este terreno. El protocolo transporta tus decisiones; no las toma.

Las preguntas de diseño que hay debajo son las de siempre. Para qué inquilino es esta llamada. Cuáles de sus registros puede ver este alcance. Quién aprueba una escritura. Qué se registra para poder reconstruir un incidente. Hemos escrito ambas mitades en detalle: arquitectura de autorización MCP para empresas para el diseño de referencia multiinquilino, y los límites de seguridad de MCP para explicar por qué solo la aplicación a nivel de datos aguanta.

Las agent skills se sitúan sobre las herramientas como capa de instrucciones: cuándo usar cuál, cuáles son las reglas de la casa, qué no hacer nunca. Herramientas sin skills se usan mal; skills sin herramientas son consejos. Publicamos las nuestras como archivos estáticos con sumas de verificación, para que cualquiera pueda leer qué se les dice a nuestros agentes.

Un plan por etapas que no exige fe

No necesitas creer que el tráfico de agentes será grande para justificar los dos primeros pasos, porque son baratos y también rinden para las personas.

Primero herramientas de solo lectura. Búsqueda, consulta, estado. Sin escrituras, sin aprobaciones que diseñar, y ejercita identidad y límites de tasa en condiciones reales.
Publica el mapa. Un endpoint MCP más skills que describan las herramientas con honestidad, incluido lo que van a rechazar.
Una escritura, detrás de aprobación. Elige el cambio de estado menos peligroso, añade claves de idempotencia y pon una confirmación humana delante. Registra todo.
Amplía con evidencia. Quita la aprobación solo en operaciones donde el registro muestre que el agente ha acertado de forma consistente, y mantenla en todo lo demás.

Los pasos uno y dos son unos días de trabajo sobre una API bien factorizada y son útiles de inmediato, porque los mismos esquemas y mensajes de error facilitan tus propias integraciones. El paso tres es donde está el verdadero trabajo de diseño.

La parte honesta

Nadie puede decirte hoy cuántos ingresos llegan a través de agentes. Quien te dé una cifra está adivinando, y nosotros no vamos a adivinar por ti.

Lo defendible es la forma de la apuesta. La superficie de solo lectura es barata, los estándares están convergiendo, y el trabajo no se pierde si el tráfico de agentes sigue siendo pequeño, porque herramientas tipadas, límites de autorización reales y errores legibles por máquinas son cosas que una API madura debería tener de todos modos. Lo que no haríamos es rediseñar un producto en torno a un canal que aún no se ha demostrado. Empieza por la parte que sirve en cualquier caso.

Preguntas frecuentes

¿Cuál es la diferencia entre un producto legible por agentes y uno usable por agentes?

Legible significa que un asistente puede descargar, interpretar, citar y atribuir tu contenido. Usable significa que puede autenticarse como un usuario concreto, llamar a una herramienta, cambiar estado y recibir un rechazo cuando corresponde. Lo primero es un problema de publicación, lo segundo de autorización e identidad.

¿Basta un servidor MCP para que un producto sea usable por agentes?

No. MCP es el transporte para exponer herramientas y recursos; transporta tus decisiones de autorización en lugar de tomarlas. El alcance por inquilino, los permisos a nivel de datos, la aprobación de escrituras y el registro de auditoría tienen que existir detrás.

¿Por qué los agentes necesitan claves de idempotencia?

Porque los agentes reintentan, incluso ante timeouts que malinterpretan y respuestas parciales que no entendieron. Sin una clave que convierta el segundo intento en una operación nula, un reintento se vuelve un pedido, un mensaje o un cargo duplicado.

¿Podemos exponer simplemente nuestra API REST actual?

A menudo sí, con dos cambios. Los errores tienen que decir qué campo falló y qué se esperaba, para que un modelo pueda corregirse en lugar de entrar en bucle. Y los alcances tienen que expresar que un agente actúa en nombre de un usuario, en lugar de una única clave con todo habilitado.

¿Deberían los agentes poder escribir en producción?

Con el tiempo, y de forma limitada. Empieza en solo lectura, pon después una escritura de bajo riesgo detrás de aprobación humana con idempotencia y registro completo, y quita la aprobación solo donde el registro muestre un historial consistente de comportamiento correcto.

¿Es demasiado pronto para invertir en esto?

Para una reconstrucción completa, sí. Para herramientas de solo lectura y skills publicadas, no, porque las herramientas tipadas, los límites de autorización reales y los errores legibles por máquinas mejoran tus propias integraciones crezca o no el tráfico de agentes.

Reflexiones finales

Legible es un problema de publicación y está casi resuelto generando copias limpias y dejando entrar a los fetchers correctos. Usable es un problema de ingeniería, y lo limita la precisión con la que puedes decir no.

Haz la superficie de solo lectura porque rinde de todos modos. Después diseña el camino de escritura alrededor de identidad, autorización a nivel de datos, idempotencia y auditoría, y amplíalo con evidencia en lugar de con optimismo.