Tres agentes de IA para SQL, conocimiento y este sitio, con las decisiones clave sobre seguridad, costes y fiabilidad.

La mayor parte del contenido del “agente de IA” es una demostración: una grabación ingeniosa, un único camino feliz, sin manejo de errores, sin límite de costos, sin plan para cuando el modelo sea incorrecto. Esto no es eso. A continuación se muestran tres sistemas de agentes de IA que ejecuto en producción, todos los días, con datos reales y con barreras de seguridad reales. Cada uno reemplaza el trabajo que una persona solía hacer a mano.

El punto no es “mira, IA”. El punto es el patrón de ingeniería que convierte un modelo en un sistema en el que realmente puedes confiar: basarlo en tus datos, limitar lo que se le permite hacer, fallar elegantemente y mantenerlo barato.

Los tres sistemas

Sistema	Reemplaza	Interfaz	Pila
agente-sql	”Oye, ¿puedes sacar este informe?” solicitudes a un desarrollador	CLI + Telegrama	TypeScript, base de datos SQL, OpenRouter
agente-md	Buscando una respuesta en documentos dispersos	Telegrama	TypeScript, SQLite FTS5, OpenRouter
/api/ai (este sitio)	Correos electrónicos genéricos “pregunta sobre mi trabajo”	Web (lado del servidor)	IA de los trabajadores de Cloudflare

1. sql-agent: lenguaje natural para SQL de solo lectura

MANTENERXYZ0XYZMANTENER

El problema. Los datos comerciales se encuentran en una base de datos SQL. Las personas que necesitan respuestas (propietarios, analistas, contadores) no escriben SQL. Entonces, cada pregunta se convierte en un ticket: “¿Cuántos pedidos vinieron de clientes habituales el mes pasado?” Un desarrollador detiene lo que está haciendo, escribe un SELECT y vuelve a pegar una tabla. Es repetitivo, lento y bloquea ambos lados.

Qué hace. sql-agent toma una pregunta en inglés simple o ruso, genera un SELECT de solo lectura, lo ejecuta en la base de datos y devuelve las filas, además de un resumen opcional en lenguaje sencillo.

"How many orders from repeat customers last month?"
        ↓  (LLM: schema-aware SELECT generation)
   SELECT count(*) FROM orders WHERE ...
        ↓  (read-only execution + row cap)
   rows → "412 orders, 38% from repeat customers"

La parte difícil no es el SQL, sino la seguridad. Un agente de base de datos en lenguaje natural que pueda escribir consultas arbitrarias es un inconveniente. Las decisiones que hicieron que fuera lo suficientemente seguro para funcionar sin supervisión:

• Solo lectura por construcción. El agente solo produce SELECT. Las escrituras y los cambios de esquema se rechazan antes de la ejecución.
• Registro de consultas. Cada consulta generada se registra con la pregunta original, por lo que cualquier cosa cuestionable se puede auditar después del hecho.
• Límites de filas y tiempos de espera. Una consulta generada que analiza 40 millones de filas no puede desactivar la base de datos: los resultados se limitan y se cancelan.
• El modelo es intercambiable; la seguridad no lo es. Se ejecuta en OpenRouter (Claude Sonnet 4 por defecto, GLM como alternativa), pero la protección de solo lectura vive en mi código, no en la buena voluntad del modelo.

Análogo empresarial. Este es exactamente el sistema que necesita el propietario de una tienda Shopify o un líder de operaciones: haga una pregunta con sus propias palabras, obtenga un número y nunca más espere a un desarrollador para obtener un informe de rutina.

2. md-agent: un LLM basado en una base de conocimientos de Markdown

MANTENERXYZ1XYZMANTENER

El problema. El conocimiento se dispersa (notas de reuniones, documentos de procesos, decisiones, runbooks) en docenas de archivos de rebajas. La búsqueda de palabras clave encuentra palabras, no respuestas. Entonces la gente vuelve a hacer preguntas que ya fueron respondidas o se rinde y toma decisiones sin el contexto.

Qué hace. md-agent es un bot de Telegram que responde preguntas basadas en su base de conocimientos de Markdown: primero recupera los fragmentos relevantes (búsqueda de texto completo SQLite FTS5) y luego se los entrega al LLM para que los responda. Se trata de recuperar y luego responder, no de generación libre.

question → FTS5 retrieve top-k MD chunks → LLM answers FROM those chunks
                                              ↓
                              "no relevant chunks" → honest "I don't know"

Las decisiones que lo hicieron apto para producción:

• Conectado a tierra, no alucinado. La respuesta se limita al contexto recuperado. Si no hay nada relevante en la base de conocimientos, lo dice en lugar de inventar, la propiedad más importante de un agente de conocimiento confiable.
• Hospedaje eficiente. Se ejecuta en un VPS de 1 CPU / 2 GB de RAM. Un asistente de base de conocimientos no necesita una GPU ni un servidor grande.
• Modelos de nivel gratuito. El valor predeterminado es un punto final OpenRouter gratuito (DeepSeek V3). La arquitectura no depende de ningún modelo ni de ningún billete.
• Git safety net. La base de conocimientos está controlada por versiones, por lo que las ediciones son recuperables.

Análogo empresarial. Búsqueda de conocimiento interno y desviación del soporte: el mismo patrón que impide que un equipo de soporte responda las mismas cinco preguntas para siempre.

3. El agente en este sitio

Este sitio tiene su propio pequeño agente en /api/ai. Es el más ligero de los tres y existe para mostrar el patrón a un costo mínimo:

• Solo del lado del servidor. No hay claves API en el navegador. El navegador llama a una ruta; la ruta llama al modelo.
• Entrada limitada. Las indicaciones tienen un límite; las cargas útiles tienen un tamaño limitado.
• Velocidad limitada. Una ventana deslizante por IP evita el abuso.
• Degradación elegante. Si el enlace del modelo está ausente (por ejemplo, una implementación estática), lo dice en lugar de fallar.
• Modelo barato. Se ejecuta en un modelo pequeño de Workers AI (Llama 3.1 8B), no porque los modelos pequeños sean mejores, sino porque un asistente de cartera no necesita un modelo de frontera, y la disciplina de costos es parte del objetivo.

El patrón detrás de los tres

Si eliminamos las diferencias, las mismas cinco decisiones aparecen en cada agente de producción que envío:

1. Arraigue. Las respuestas provienen de sus datos (esquema SQL recuperado, documentos recuperados, un mensaje del sistema seleccionado), no de la imaginación del modelo.
2. Encuadernado. Sólo lectura. Filas rematadas. Fichas limitadas. Rechazo de solicitudes fuera de alcance.
3. Registro y auditoría. Cada acción es rastreable después del hecho.
4. Falla con gracia. Modelo caído, faltan enlaces, entradas abusivas: el sistema se degrada, no falla ni filtra elementos internos.
5. Mantenlo económico. Adapta el tamaño del modelo al trabajo. Un robot de conocimiento no necesita un modelo de token de 20 dólares por millón; una tarea de razonamiento difícil no debería realizarse con la más barata.

Una demostración omite los cinco. La producción requiere los cinco.

Dónde aparece esto en mi trabajo

Estos no son experimentos aislados. Los mismos patrones se aplican a todo lo que construyo: ak-payload (una plataforma de comercio Payload CMS + Next.js), ak-blog (este sitio) y los estudios de casos de clientes. Dondequiera que haya un trabajo repetitivo y vinculado a datos, un agente conectado con un alcance limitado suele ser la herramienta adecuada. Están llegando al sitio páginas dedicadas a estos proyectos.

Pros y contras de construir versus comprar un SaaS

Construya cuando el flujo de trabajo es central, los datos son confidenciales o la factura de SaaS aumenta con el uso de manera dolorosa (la clásica trampa de Zapier). Compre cuando se trate de una integración de productos básicos en la que nunca se diferenciará.

Los tres agentes anteriores son todos “construidos”: porque tocan datos comerciales reales, el modelo de seguridad es importante y el costo por solicitud de un equivalente de SaaS se acumula rápidamente.

TL;DR

Sistema	Lo que prueba	Decisión clave de seguridad
agente sql	NL → SQL en producción	Sólo lectura por construcción
agente md	Preguntas y respuestas de KB conectadas a tierra en un VPS de 2 GB	Recuperar y luego responder; honesto “No lo sé”
/api/ai	Agente del lado del servidor de costo mínimo	Entrada limitada + degradación elegante

Un agente de IA es un sistema alrededor de un modelo, no el modelo en sí. El modelo es la parte fácil. La conexión a tierra, las barandillas de seguridad, el límite de costos y la falla elegante: ese es el trabajo, y eso es lo que lo hace lo suficientemente confiable para funcionar todos los días.Si tiene un flujo de trabajo repetitivo y basado en datos que una persona maneja a mano hoy en día, ahí es exactamente donde encaja un agente de producción: cuénteme.