Caso práctico: así construimos nuestro propio agente

De dónde salió el problema

El punto de partida no fue una ambición técnica, sino una molestia diaria. La documentación del proyecto lo cuenta así:

«Estaba usando casi veinte herramientas de IA a la vez para cubrir mi propio trabajo. Lo que una de ellas aprendía sobre mí, la siguiente no lo había oído nunca. Mi memoria estaba desperdigada, la seguridad se decidía en un sitio distinto en cada herramienta y el contexto se perdía en cada cambio.»

Eso no es falta de herramientas. Es un problema de integración — y esa diferencia decide si merece la pena empezar siquiera. Si tu problema es que no tienes una herramienta buena, compra una mejor. Si tu problema es que tienes seis herramientas buenas y ninguna sabe de las otras, la pieza que falta no es una séptima herramienta.

Lo que salió de ahí es un framework autoalojado, en beta pública desde septiembre de 2026: casi sesenta módulos, más de doscientas skills, treinta y cuatro servidores MCP y doce motores ejecutables, en seis idiomas. Esas cifras cambian cada semana, y no son ellas lo interesante. Las decisiones sí.

Qué hace un agent paso a paso, al nivel del bucle en sí, lo desarrolla qué hace realmente un agent, que es un post aparte.

La primera decisión: un framework, no un chatbot

La primera frase de la documentación es tajante: «No es un chatbot. Es un asistente de verdad.» La consecuencia práctica, sin embargo, no es la interfaz — es la cuestión del motor.

El sistema puede usar cualquier proveedor de modelos, y ahí dentro hay una decisión que rara vez se plantea: las CLI de programación por suscripción también sirven de motor, sin API key aparte. Si ya pagas por un asistente de código, el sistema lo llama como motor en vez de comprar la misma capacidad por segunda vez a través de una API.

Eso es una decisión de coste, no una función. Y tiene su contrapartida en el lado de las renuncias: en los grandes servicios gestionados el modelo va incluido en la suscripción. Aquí no. La documentación lo dice sin rodeos — el modelo sigue siendo tu clave o tu suscripción.

Si construir lo tuyo gana o pierde frente a comprar algo ya hecho es la pregunta que recorre comprar o construir , caso por caso.

El routing: el primer paso ni siquiera es IA

Esta es la decisión más transferible de todo el sistema. El camino que recorre una llamada:

1. SEÑALES BARATAS     -> cinco señales, sin llamada de pago
2. MODELO CLASIFICADOR -> solo si la ronda barata duda
3. ELECCIÓN DE NIVEL
4. CONTROL DEL GASTO
5. CADENA DE RESPALDO  -> si el proveedor no responde

Lo importante está en la primera línea: la primera ronda de clasificación no cuesta nada. Decide una cascada de señales baratas — a qué está enganchada la función, qué reglas de palabras clave se cumplen, qué dicen los metadatos del mensaje, qué había hasta ahora en la conversación y qué dice un clasificador pequeño que corre en local — y solo cuando todo eso sigue sin aclarar nada se le pregunta a un modelo de pago. La optimización más barata en un agent no es llamar a un modelo más barato: es no llamar a ningún modelo.

Los niveles en los que acaba clasificada una llamada:

El presupuesto de gasto tiene tres umbrales: avisa al 80 por ciento, baja solo a un nivel más barato al 100 por ciento y se detiene al 120 por ciento. Es interesante porque el que importa es el tercero: avisos escribe todo el mundo, paradas duras muy pocos.

La memoria: cinco capas, y un fallo que obligó a aislarla

La memoria se divide en cinco capas, y lo que las separa es cuánto viven:

La decisión clave en la recuperación es que el modelo no tiene que pedir la memoria. En cada turno entran dos bloques: un índice de una línea con todas las notas, y el trabajo anterior relacionado. El índice tiene un presupuesto fijo, ocho mil caracteres por defecto — y ese número está en el sistema porque sin él la memoria se come el context window sin que te enteres.

La captura tiene sus propias puertas: un mensaje de menos de cuarenta caracteres no da lugar a ninguna nota, una conversación tiene un tope de veinte llamadas de extracción, y un turno produce entre cero y dos notas. No hay lista de palabras clave, en ningún idioma. Y la captura corre después de que la respuesta haya salido: si se cae, lo que cuesta es una nota que falta, no una respuesta que falta.

Y aquí llega el fallo que justificó un subsistema entero. Uno de los motores lleva su propia memoria en la máquina anfitriona. Sin aislamiento, el extractor leyó una vez esa memoria del anfitrión, informó de que el dato «ya estaba registrado» — y el almacén propio de EYAS se quedó vacío. Un fallo silencioso: no se cayó nada, simplemente no se escribió nada.

El arreglo tiene dos partes: un contexto de modelo aislado, y una puerta que no es un modelo y que le prohíbe a toda herramienta de escritura las rutas de memoria ajenas. El límite honesto, eso sí, se quedó donde estaba: el protocolo de dos motores no conoce ningún parámetrode aislamiento, así que ahí no se puede hacer — y la interfaz lo dice en vez de fingir que sí.

Qué conviene que un agent recuerde en general y qué olvide lo detalla el post sobre la agent memory, con las renuncias por su nombre.

La seguridad: tres puertas, y la primera no es un modelo

No todas las llamadas pasan por las tres, y ahí está el alma del sistema:

• una acción verde (leer, buscar) → solo la primera puerta
• amarilla (escribir, cambiar un ajuste) → la primera y la segunda
• roja (borrar, operación financiera, despliegue en producción) → las tres, más aprobación humana

Parte de la puerta determinista es una regla sencilla: de «entrada no fiable», «datos sensibles» y «acción externa», como mucho dos pueden cumplirse a la vez. Si hacen falta las tres, la aprobación humana es obligatoria. Esa única frase compra más protección que la mayoría de las políticas en tres páginas.

Antes de cada cambio se toma una instantánea — fichero, base de datos, ajuste, git — con un estado restaurable. La formulación por la que lo construimos: «"la IA se equivocó" no es un argumento, es un solo comando».

Y la frase sin la cual esta sección no tendría ninguna credibilidad: el prompt injection no está resuelto. La documentación dice exactamente eso, y añade que a quien afirme lo contrario conviene mirarlo dos veces. Las capas reducen el riesgo; no lo eliminan.

Dónde poner la aprobación dentro de un proceso lo desmenuza el humano en el bucle, que señala tres sitios que vale la pena vigilar.

Recortar los permisos — darle al agent lo mínimo con lo que puede trabajar — lo cubre el agent con los permisos mínimos como principio de diseño.

Y qué consecuencias tiene el prompt injection para un negocio lo mira otro post.

El callejón sin salida que se pudo medir

En este proyecto hay exactamente una decisión que se paró por un número y no por un argumento — y es justo la más instructiva de todas.

La búsqueda trabaja con varias fuentes: búsqueda de texto completo, búsqueda vectorial y un grafo. Los resultados hay que fusionarlos, y para eso existe un método de manual: la fusión recíproca de rangos aplicada tal cual. Obvio, y lo que hace todo el mundo.

Medido: la fusión sin filtrar bajó el recall de los cinco primeros resultados del 85 por ciento al 65. Es decir, de cada cinco buenos resultados desapareció uno — por un paso que la mayoría de los sistemas ni siquiera pone en el banco de pruebas. Desde entonces está prohibido en el código.

Lo que conviene llevarse de aquí no es la cifra en sí. Es que esto solo lo notas si mides el recall y no tu impresión de él. Después de un fallo así el sistema no va más lento ni devuelve ningún error. Simplemente encuentra menos, y por eso alucina más — y luego se lo cargas a la cuenta del modelo.

Hay que añadirlo con honestidad: esta es la única medición de este tipo publicada en el proyecto. Las demás decisiones se justifican con razonamiento, no con un test A/B. Es normal en un proyecto de una sola persona, pero hay que conocer la diferencia.

Lo que deliberadamente no construimos

Esta sección importa más que la lista de funciones. La documentación nombra doce renuncias en voz alta; aquí van seis de ellas:

• Una base de datos embebida en lugar de una mayor. La mayor habría traído unos quince megabytes de dependencias nativas; la opción más simple cubre aproximadamente el 95 por ciento de la necesidad.
• No hay aplicación nativa de escritorio ni móvil. La documentación llama a esto «una carencia de verdad», con esas palabras, en vez de explicarlo. La superficie es un navegador y un mensajero.
• El control completo del ordenador funciona en un solo sistema operativo. En los otros dos no está terminado.
• No hay restauración de un clic sobre una máquina vacía. La copia de seguridad es completa; la vuelta atrás son seis pasos manuales.
• Un sistema de un solo propietario, no empresarial. No hay identidad centralizada ni certificaciones. El registro de auditoría es completo, pero es de una sola máquina y no está certificado.
• El catálogo de extensiones es pequeño, a propósito. Treinta y cuatro servidores MCP y nueve extensiones: una decisión tomada tras los incidentes de registros de skills de 2026, porque un mercado abierto de extensiones es una superficie de ataque demostrada.

Una lista así ya es información por sí misma. Si la documentación de un producto no tiene sección de «lo que no sabemos hacer», eso no significa que lo sepa hacer todo.

Los riesgos del autoalojamiento, por cierto, los reúne el artículo sobre agentes personales autoalojados , uno por uno.

Qué llevarte si fueras a construir uno

1. NOMBRA PRIMERO EL PROBLEMA, NO LA HERRAMIENTA
   "No tengo una herramienta buena" y "tengo seis y
   ninguna sabe de las otras" son dos proyectos.

2. LA LLAMADA MÁS BARATA ES LA QUE NI SE LANZA
   Que la primera ronda de clasificación sea determinista.
   Pregúntale a un modelo solo si dudas de verdad.

3. EL PRESUPUESTO NECESITA UNA PARADA DURA
   Un aviso no es un límite. Bajar de nivel tampoco.
   Hace falta un punto donde de verdad se detenga.

4. LA PRIMERA PUERTA DE SEGURIDAD NO PUEDE SER UN MODELO
   Lo que se puede engañar con un prompt no es una puerta.
   La coincidencia de patrones es aburrida, y fiable por eso.

5. MIDE EL RECALL, NO TU IMPRESIÓN
   La búsqueda se degrada en silencio. Una mala
   fusión se puede llevar un quinto de los resultados.

6. ESCRIBE LO QUE NO SABES HACER
   La lista de renuncias es para ti mismo más adelante,
   y para quien vaya a usar la cosa.

Malentendidos típicos

• «Con un agent propio sale más barato.» La factura del modelo se queda. Solo la orquestación pasa a ser tuya — y el mantenimiento también.
• «Si corre en mi propia máquina, es seguro.» El riesgo no desaparece, se desplaza: del modelo a los permisos.
• «Ya decidirá el agent qué modelo hace falta.» En un buen sistema la primera ronda de esa decisión es determinista, antes de cualquier llamada a un modelo.
• «La memoria es la base de datos vectorial.» Guardar es la mitad fácil. La difícil es cuándo y cuánto entra en el contexto sin comérselo.
• «Con tres capas de seguridad el prompt injection está resuelto.» No lo está. Las capas reducen el riesgo.

Lo que conviene llevarse

Un framework de agent hecho en casa no es bueno por cuántos módulos sabe manejar. Lo es porque las decisiones caras le salen baratas: la clasificación sin llamar a un modelo, el bloqueo por coincidencia de patrones, la vuelta atrás desde una instantánea.

Las tres cifras que conviene recordar de este proyecto: cinco milisegundos para la puerta determinista, 120 por ciento para la parada dura del gasto, y el recall cayendo del 85 al 65 por ciento por una única fusión mal elegida.

Y lo más útil que vas a encontrar en la documentación de un sistema así no es la lista de funciones, sino la de renuncias. Si construyes, escribe la tuya mientras todavía te acuerdas de por qué decidiste como decidiste.

El estándar con el que se conectan las herramientas, que es también la columna vertebral de este sistema, lo explica el post sobre MCP y su funcionamiento.