Un agente es un directorio de archivos

La idea central es un contrato basado en el sistema de archivos: un agente es un directorio, y cada archivo o carpeta declara un componente. No hay un registro central que conectar: el framework descubre las piezas al compilar. La estructura se lee como la anatomía de un agente:

my-agent/
  agent.ts          # configuración del modelo  →  "anthropic/claude-opus-4.8"
  instructions.md   # prompt de sistema, se carga en cada llamada
  tools/            # capacidades ejecutables (TypeScript + esquemas Zod)
  skills/           # conocimiento que se carga según el contexto (Markdown)
  connections/      # servidores MCP seguros + integraciones OpenAPI
  channels/         # dónde se le puede contactar: Slack, Discord, Telegram, GitHub…
  schedules/        # cron: ejecuciones autónomas, sin supervisión
  subagents/        # agentes hijos especialistas a los que puede delegar

Dos archivos, agent.ts e instructions.md, bastan para tener un agente que funciona; todo lo demás es opcional. Se crea la estructura con npx eve init, se corre localmente con eve dev y se despliega con vercel deploy. La misma definición atiende HTTP, Slack, Telegram, GitHub y más al mismo tiempo: usted escribe el agente una vez y elige los canales.

El valor está en la maquinaria de producción que todo agente serio necesita y que a nadie le gusta volver a construir. Eve trae seis piezas de esa maquinaria:

• Ejecución durable: cada conversación es un flujo de trabajo con puntos de control, así que un agente sobrevive a una caída o a un despliegue a mitad de una tarea y retoma donde se quedó en lugar de empezar de nuevo.
• Cómputo aislado: el código del agente corre aislado (Docker en local, un sandbox alojado en producción), así que una llamada a una herramienta no puede alcanzar el resto de su sistema.
• Aprobaciones con una persona en el ciclo: cualquier acción puede llevar una bandera needsApproval y esperar a una persona antes de ejecutarse.
• Conexiones seguras: intermediación de autenticación con Slack, GitHub, Notion, Salesforce, Snowflake y los demás, en lugar de programar a mano cada flujo de OAuth.
• Despliegue multicanal: un solo agente responde en todos los canales a la vez.
• Observabilidad: trazas de OpenTelemetry y evaluaciones integradas, para que pueda ver qué hizo el agente y probarlo.

La recompensa es real: Vercel menciona agentes internos como un analista de datos que atiende más de 30,000 preguntas al mes, un agente de soporte que resuelve por sí solo el 92% de los tickets y un SDR autónomo que “cuesta unos $5,000 al año y devuelve 32 veces eso”. El framework es lo que le permitió a un equipo pequeño construir cada uno en semanas, no en trimestres.

Eve es, casi línea por línea, la arquitectura que ya operamos. Los agentes detrás de este sitio y del chatbot de DLR son un directorio de skills en Markdown que se cargan cuando se necesitan, un conjunto de herramientas (nuestras lentes -eye de solo lectura, una CLI de secretos, lentes de base de datos), conexiones MCP, canales (bots de Telegram), tareas programadas (los cron de la noche y de la mañana), subagentes para el trabajo delegado y una estricta compuerta de aprobación humana para todo lo destructivo. Cuando Vercel libera como código abierto la misma forma y corre cien agentes sobre ella, eso confirma que el patrón es el correcto, no es una razón para reconstruir.

Así que nuestra lectura es una validación, no una migración. Mantenemos a propósito el entorno de ejecución del agente en local: los agentes corren en nuestro propio hardware a $0, y el único costo facturado por consumo es la llamada al modelo. Un framework alojado traslada esa ejecución (y los puntos de control del flujo durable, que reenvían el prompt en cada paso) a cómputo en la nube que se factura, y pone la autenticación de sus conexiones en manos de un tercero. Para nosotros, las dos cosas cambian lo que más cuidamos, un costo predecible y un control estricto de los secretos, por una comodidad que no necesitamos. La lección que vale la pena tomar es la forma: el contrato de directorio, la bandera de aprobación, las trazas integradas. El entorno de ejecución lo mantenemos en casa. (Vea la realidad del autoalojamiento para saber cuándo correrlo uno mismo de verdad conviene).

Vuelva a ver el directorio. El modelo vive en un solo lugar: agent.ts, una sola cadena: "anthropic/claude-opus-4.8". Un framework vuelve fácil todo lo que rodea al modelo y luego deja la decisión de mayor peso como una constante fijada al compilar. Fije un modelo de frontera y cada tarea, la intención de sí o no, la consulta con plantilla, el razonamiento de verdad difícil, paga precios de frontera. Fije uno barato y las tareas difíciles fallan sin hacer ruido.

Esa constante es justo lo que este sitio existe para convertir en una medición. El framework mueve la solicitud y corre el ciclo; no sabe qué modelo es el correcto para cada cosa que hace el agente. EyesInAI evalúa a los candidatos con las tareas reales, calificadas contra la respuesta correcta, y produce lo que debería decir la línea de agent.ts: el modelo menos costoso que todavía aprueba, tarea por tarea. En el chatbot de DLR, ese único cambio midió ~31% de ahorro por turno con la misma precisión.

Así que las dos capas se acoplan sin problema: un framework como Eve es el cómo se ejecuta; una señal de enrutamiento medida es el qué modelo lo ejecuta. Adopte el patrón del framework para la plomería, y alimente su elección de modelo con una cifra que pueda defender, no con una cadena que adivinó al compilar.