Lo que los agentes de IA necesitan de verdad de la infraestructura: 7 requisitos y dónde estorba el hosting pensado para personas

La mayor parte del hosting se diseñó para una persona frente al teclado: un formulario de registro, una tarjeta, un panel, un correo cuando algo falla. Un agente de IA que necesita cómputo no encaja en ninguno de esos pasos. No resuelve un captcha, no distingue una página de mantenimiento de una rota y no se da cuenta de que ha creado el mismo servidor cuarenta veces.

Es tentador decir «dale una API y listo». Ese es el primer requisito, no el último. Estos son los siete que creemos importantes, a partir de construir nuestro propio servidor MCP y nuestra API REST para agentes. Para cada uno: qué sale mal sin él.

1. Todo lo que necesita un agente es programable

Crear, consultar, redimensionar y eliminar recursos tiene que funcionar sin navegador. Incluidas las partes aburridas: saber el precio antes de comprar, comprobar si una ubicación tiene capacidad, leer la contraseña de una máquina nueva, cancelar.

Sin esto: el agente recorre el 80 % del camino y se queda en el único paso que requiere un clic, y una persona tiene que terminar el trabajo de todos modos. Una API a medias suele ser peor que ninguna, porque invita a una automatización que no puede completarse.

2. Errores sobre los que un programa puede actuar

Un agente lee una respuesta y decide qué hacer a continuación. Un cuerpo JSON con un código estable (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded con la hora de reinicio) es algo sobre lo que puede ramificar. Una página de error HTML, o un 500 con un mensaje vago, lo deja adivinando: a menudo reintentando algo que nunca va a funcionar.

Sin esto: bucles de reintentos. Los fallos de agentes más caros no suelen ser malas decisiones, sino la misma llamada fallida repetida miles de veces.

3. Pagar sin una persona en el circuito

Los pagos con tarjeta están llenos de pasos pensados para confirmar que hay una persona presente: códigos 3-D Secure, confirmaciones en la app del banco, verificaciones de identidad. Son buenos contra el fraude e imposibles para un programa. Un saldo prepago, recargado por adelantado (en nuestro caso, a menudo con stablecoins), permite a un agente pagar lo que usa sin que una persona apruebe cada cargo.

Sin esto: o una persona aprueba cada compra, lo que anula el sentido, o alguien le da una tarjeta a un agente, un riesgo que nadie debería correr.

4. Límites de gasto estrictos

Un saldo prepago limita el peor caso a lo que contiene. Eso puede seguir siendo mucho. Un límite diario y mensual, en dólares, aplicado por la plataforma y no por las buenas intenciones del propio agente, convierte un agente en bucle en una pérdida pequeña. El límite debe fallar de forma visible, con un error que el agente reconozca, y detener o pausar lo que esté en marcha.

Sin esto: te enteras del bucle por el saldo. Nuestra facturación de sandboxes tiene límites por este motivo, y la página de salvaguardas de MCP sugiere qué acciones deberían requerir directamente la aprobación de una persona.

5. Cómputo con la granularidad adecuada

Los agentes producen tres tipos de trabajo muy distintos:

• Segundos: ejecutar un fragmento generado, comprobar una respuesta, probar un arreglo.
• Horas: una evaluación, un scraping, una compilación larga.
• Siempre encendido: un bot, una API, un worker programado.

Una plataforma que solo ofrece servidores mensuales hace absurdamente caro el primer tipo; una que solo ofrece sandboxes efímeras hace frágil el tercero. Una tarea de 20 segundos en una máquina facturada por horas paga 59 minutos de nada. Cómo funciona la facturación por segundo muestra dónde deja de tener sentido cada modelo.

Sin esto: los agentes pagan de más por el trabajo corto o mantienen servicios duraderos en una infraestructura que no estaba pensada para seguir encendida.

6. Aislamiento por defecto

El código que escribe un agente es código que nadie ha revisado. Debe ejecutarse donde no haya nada de valor: no en el host del propio agente, no en un servidor con tus claves, no en la máquina que envía tu correo. En la práctica, eso significa una VM o microVM aparte por tarea, eliminada después. Niveles de aislamiento para código no fiable compara las opciones; las microVM de Firecracker explicadas cuenta por qué importa un kernel propio.

Sin esto: la primera inyección de prompt que llegue al código generado tiene acceso a todo lo que alcance el host del agente.

7. Visibilidad y un interruptor

La persona responsable de un agente necesita ver qué hizo y detenerlo rápido. Eso implica uso y coste por recurso, una lista de todo lo que creó el agente y una forma de eliminarlo todo. Las credenciales deben poder revocarse y durar lo bastante poco como para que una filtrada no valga para siempre, con una forma de renovarlas que no requiera a una persona.

Sin esto: limpiar se convierte en arqueología. Los recursos olvidados siguen facturando; un token filtrado sigue funcionando.

Lo que los agentes no necesitan

Igual de revelador es lo que no ayuda: paneles diseñados para vender más, correos de bienvenida, tarifas cuyos límites reales están en una nota al pie, precios que solo aparecen tras registrarse. Nada de eso es legible para un programa, y parte de ello confunde activamente a un modelo que se toma el texto al pie de la letra.

Lo que sigue sin resolverse

No todo aquí es un problema de ingeniería resuelto.

• Responsabilidad. Alguien responde de lo que un agente hace con una cuenta. Las plataformas necesitan una forma de vincular la actividad automatizada a una persona responsable sin obligarla a pasar por cada paso.
• Abuso. El registro abierto y totalmente automatizado es justo lo que también quieren los abusadores. Cada plataforma que atiende a agentes equilibra el acceso sin fricción frente a las granjas de cuentas y la minería, y ninguna tiene una respuesta perfecta.
• Flujos largos. Los agentes todavía fallan más en procesos de diez pasos que en llamadas sueltas. La infraestructura puede ayudar haciendo cada paso idempotente y su estado fácil de consultar, para que un reintento continúe en lugar de duplicar.

Dónde hemos llegado

Hemos intentado construir para estos requisitos en lugar de esquivarlos: un servidor MCP y una API REST que cubren todo el ciclo de vida, errores legibles por máquina, un saldo prepago, límites de gasto, sandboxes de código por segundo para el trabajo corto y servidores mensuales como la tarifa AI agent para el largo. Un recorrido por la parte de sandboxes está en sandbox para agentes de IA. Aun así, juzga la lista por sí misma: es una lista de comprobación útil para cualquier plataforma en la que sueltes a un agente.