Las herramientas que doy a cada agente que ejecuto

Claude Code, Codex, algo que he escrito yo mismo: en una semana normal uso tres o cuatro de ellos, y el modelo subyacente es más o menos el mismo. Lo que decide si una sesión llega a algún sitio es a qué tiene acceso.

Así que mantengo las mismas cinco cosas conectadas en todas partes. Búsqueda, datos, almacenamiento, despliegues y llamadas a modelos económicas. A ninguna le importa qué agente hace la llamada, que es precisamente el objetivo, y cada una es una clave en un .env más una página de notas en lugar de algo que tenga que configurar de nuevo por cada entorno.

Linkup, para que la búsqueda web no dependa del entorno

Cada agente tiene alguna capacidad web y nunca sabes exactamente cuál es. ¿Obtiene la página o una copia en caché? ¿Sigue el enlace que ha encontrado? ¿Se rinde silenciosamente ante un 403 y responde basándose en su memoria?

Linkup es una API de búsqueda diseñada para que la llamen los modelos. Una consulta, y tú eliges la forma de lo que se devuelve:

• URLs clasificadas, cuando quieres elegir las fuentes tú mismo.
• Una respuesta con fuentes, cuando ya ha leído varias páginas y quieres la conclusión con sus citas.
• JSON estructurado, basado en un esquema que tú proporcionas.

La tercera es la que más utilizo. Llega como datos, por lo que un script puede usarlos directamente en lugar de que un agente lea prosa y vuelva a escribir los campos en un archivo. También hay un endpoint de fetch que convierte una URL conocida en markdown limpio en aproximadamente un segundo, que es la versión honesta de “lee esta página”.

La razón por la que esto supera a la herramienta integrada no es la calidad, sino que es la misma en todas partes. Sea lo que sea que haya abierto esta mañana, la búsqueda web funciona y funciona de la misma manera.

Apify, para que cualquier plataforma sea accesible

Apify es un marketplace de scrapers, y hay uno para casi cualquier cosa. Mis propias publicaciones de LinkedIn con sus números reales, los vídeos de un canal de YouTube, los comentarios debajo de ellos, transcripciones, miniaturas, ofertas de empleo.

El primero aparece más de lo que esperaba. Cuando planifico contenido, poder decir “ve a buscar las cifras reales de mis veinte últimas publicaciones y dime qué ganchos funcionaron” supera a cualquier panel de control, porque la respuesta llega como una tabla con la que luego puedo hacer otra cosa.

Lo que lo hace utilizable son las reglas, que residen en un archivo de habilidades que el agente lee antes de tocar la API:

• Una tabla de scrapers aprobados, una fila por plataforma, con su precio por resultado y un payload que he verificado. Para esos, simplemente se ejecuta, sin preguntas.
• Solo precios por resultado. Muchos scrapers piden 25 $ al mes por adelantado, lo que anula el propósito de recurrir a uno dos veces al año. Es un filtro estricto: comprobar el modelo de precios y, si es una suscripción, pasar al siguiente.
• Leer el esquema de entrada, no adivinar los nombres de los campos. maxItems no existe en el scraper de LinkedIn, es maxPosts. Descubrir eso mediante una ejecución fallida cuesta una ejecución.
• Establecer siempre el límite. Una búsqueda por palabras clave sin límite puede devolver miles de filas y facturar cada una. Es el único error en toda esta configuración que cuesta dinero real.

Y para una plataforma que aún no esté en la tabla:

1. 1Buscar en la tiendaSolo precios por resultado
2. 2Leer su esquema de entradaEscribir el payload basado en los campos reales
3. 3Ejecutar tres, con cinco filasComparar lo que realmente se devuelve
4. 4Escalar al ganadorY luego añadirlo a la tabla

Softr, para que haya un lugar donde poner las cosas

Un agente que encuentra cosas necesita un lugar donde guardarlas, y tiene que ser un lugar que yo también pueda abrir. Un archivo JSON en el disco no sirve: nadie ordena un archivo, ni lo filtra, ni corrige una sola celda en él. Un Postgres con catorce tablas que yo no diseñé falla de otra manera.

Una base de datos de Softr se sitúa en medio. El agente lee y escribe a través de la API. Yo abro la misma tabla en un navegador, la ordeno, la filtro, corrijo una fila, comparto una vista con alguien que necesita verla. Esa segunda mitad es la que la gente ignora cuando elige un almacenamiento para un agente, y es la mitad que acabas usando a diario.

Trabajo en Softr, así que tened en cuenta esa recomendación. La razón por la que seguiría eligiéndolo son los límites de tasa, que son excepcionalmente generosos para este tipo de uso: 40 lecturas por segundo y 30 escrituras por segundo, por token. Un agente que recorra una lista nunca los alcanza.

Muchos proyectos tampoco necesitan interfaz alguna. Soy yo y los datos, o tres personas y los datos. La base de datos es el producto, y construir un front end para ella sería un trabajo que nadie ha pedido.

Cloudflare, para que un experimento pueda convertirse en una URL

Para todo lo que no debería quedarse en mi portátil. Un Worker tarda aproximadamente un minuto: suficiente para una página, una API pequeña o un agente que quiera probar vía HTTP usando su SDK.

Importa menos lo que hace que cuándo ocurre. Un experimento que puede estar online en un minuto se le enseña a alguien; uno que requiere una historia de despliegue muere en la carpeta donde nació.

OpenRouter, para que el modelo grande no lo haga todo

La razón obvia es el acceso a todos los modelos bajo una sola clave, y es cierto, pero no es por eso que está en esta lista.

La razón real es que algunos trabajos no deberían ocurrir en absoluto dentro de la conversación del agente. Digamos que estás limpiando 200 filas. Si el agente lo hace turno a turno, son 200 turnos en un contexto que crece todo el tiempo, donde cada turno vuelve a leer todo lo anterior, usando el modelo más caro que tienes. Si, en cambio, escribe un script que lanza 200 llamadas pequeñas a un modelo económico, cada llamada ve una fila, se ejecutan en paralelo y el resultado llega como un archivo.

Lo que envía el script

• Una fila por llamada
• 200 llamadas a la vez
• Sin contexto compartido

OpenRouter

• Una clave, una factura
• Cambiar de modelo es una cadena
• Fallbacks cuando uno cae

A lo que llega

• Un modelo pequeño y rápido
• Uno de vanguardia cuando es necesario
• Lo que haya salido la semana pasada

Así es también como pruebo un modelo que nunca he usado. Cambio una cadena, ejecuto el mismo script y lo comparo con el anterior. La cuenta y la clave siguen siendo las mismas.

Las notas importan tanto como las claves

Nada de esto vive en mi cabeza, y tampoco vive en un entorno. Cada herramienta tiene un archivo de habilidades: cómo se llama su clave, el endpoint que realmente funciona, los límites y los errores que ya cometí.

El de Apify contiene la tabla de scrapers. El de Softr registra que GET /fields devuelve un 405 y que el esquema proviene del endpoint de tablas en su lugar. Cosas pequeñas, pero un agente que tenga que redescubrir un endpoint en cada sesión acabará redescubriéndolo mal y te dirá que ha funcionado.

Escribí hace tiempo que los servidores MCP eran la última parte de mi configuración que seguía teniendo forma de herramienta en lugar de forma de archivo, porque cada entorno necesita que se configuren por separado y divergen. Una clave en un .env y un archivo Markdown al lado no tienen ese problema. Cualquier agente que pueda leer un archivo y ejecutar curl tiene toda la caja de herramientas, y pasar a uno nuevo no cuesta nada.

Lo que aún no he probado

Monid agrega Apify, Apollo y unos cientos de otros proveedores de datos bajo un único saldo, por lo que pagas por llamada en lugar de suscribirte a cada uno. Se describen como el OpenRouter de las herramientas para agentes, que es básicamente lo que dije que quería. No lo he necesitado lo suficiente como para probarlo adecuadamente, así que no puedo decirte si cumple las expectativas. Es el siguiente en la lista.

Esa es la configuración. Cinco claves y unas pocas páginas de notas, y dejo de tener que comprobar si el agente de hoy puede acceder a lo que necesito.