Cómo controlar agentes de IA desde la CLI: una guía práctica

Por qué controlar un agente desde la línea de comandos, para empezar

Me dedico a construir integraciones, así que admito mi sesgo: prefiero ejecutar algo desde una terminal a hacer clic a través de una página de configuración que tengo que reaprender cada trimestre. Pero el argumento aquí es más grande que el gusto personal.

Un panel de control es un buen lugar para entender un agente. Es un mal lugar para operar uno a cualquier escala. En el momento en que quieres aplicar el mismo cambio a tres agentes, o una configuración que vive en un repositorio Git junto al resto de tu infraestructura, o un despliegue que un job de CI pueda ejecutar sin un humano, el navegador se convierte en el cuello de botella. Todo lo que haces a mano es un paso que no puedes repetir, revisar ni revertir de forma limpia.

La línea de comandos soluciona esto convirtiendo las operaciones del agente en texto. Un comando que puedes pegar en un runbook. Una configuración que puedes comparar con un diff. Una ejecución que puedes disparar desde un cron job o un webhook. Y, cada vez más, una superficie que otro agente de IA puede manejar, que es exactamente por lo que la documentación de eesel les dice a los agentes de programación que usen la CLI en lugar de intentar hacer clic por el panel en un navegador.

El resto de esta guía recorre ese bucle paso a paso. Usaré la CLI de eesel para los comandos concretos porque es la que sé que es real y sobre la que puedo señalarte la documentación, pero el esquema aplica a cualquier plataforma de agentes que se tome en serio la terminal.

Lo que necesitas antes de empezar

Tres cosas, y ninguna te llevará mucho tiempo.

• Un Node.js reciente. La CLI de eesel necesita Node 18.17 o más reciente. La mayoría de las máquinas fabricadas en los últimos años ya lo tienen.
• Una plataforma de agentes con una CLI real. Este es el punto a revisar con cuidado. Muchas herramientas se anuncian como "amigables para desarrolladores" y luego te entregan una página de configuración. Busca documentación de CLI publicada con una lista de comandos real antes de comprometerte.
• Una fuente de datos para conectar. Para un agente de soporte eso significa un helpdesk, una base de conocimiento o tickets pasados. El agente es tan bueno como lo que puede leer.

No necesitas necesariamente una cuenta para empezar. La CLI de eesel puede levantar un espacio de trabajo anónimo para que pruebes una burbuja en un sitio web sin ningún registro, lo cual es una buena forma de ver todo el flujo antes de decidir nada.

Paso 1: instalar la CLI e iniciar sesión

Hay tres formas de conseguir la CLI de eesel, y corresponden a tres situaciones distintas.

Si solo quieres probarla en un sitio web con cero compromiso:

npx @eesel/cli init chat-bubble --site https://your-site.com

Eso se ejecuta sin una cuenta y levanta un espacio de trabajo anónimo. Si quieres instalarla de verdad, tómala globalmente de npm:

npm i -g @eesel/cli

o usa el script de instalación:

curl -fsSL https://dashboard.eesel.ai/eesel-cli/install | sh

Una vez instalada, autentícate:

eesel login
eesel whoami

eesel login abre el navegador una vez para vincular la terminal a tu espacio de trabajo, y whoami confirma con qué cuenta y agente estás conectado. Desde aquí puedes quedarte en la terminal.

Un detalle que vale la pena señalar para cualquiera que esté scripteando esto: cada comando imprime JSON, y las listas imprimen un objeto por línea. Eso significa que puedes canalizar la salida directamente a jq o a un script sin tener que raspar texto legible para humanos. También puedes acotar la salida con --fields (por ejemplo --fields id,status) para que un script solo vea las claves que necesita.

Paso 2: conectar un helpdesk o fuente de datos

Un agente sin nada que leer es un truco de fiesta. Lo primero que haces de verdad es darle una fuente.

eesel integrations connect zendesk

Cambia zendesk por la plataforma que uses. eesel se conecta con Zendesk, Freshdesk, Gorgias, Front, Help Scout, HubSpot, Salesforce y Jira Service Management, entre otros. El comando gestiona el intercambio OAuth y avisa cuando la fuente está activa.

Comprueba el estado en cualquier momento:

eesel status

status te dice qué está conectado, qué conoce el agente y si algo sigue sincronizándose. Es el comando que más ejecuto, porque responde a la única pregunta que importa a mitad de la configuración: ¿está esto realmente listo?

Paso 3: definir las instrucciones del agente

Aquí es donde el "control" se vuelve real. Las instrucciones son las reglas permanentes que sigue el agente: tono, qué puede responder, cuándo debe escalar, qué acciones puede tomar por su cuenta.

eesel instructions

Eso lee las instrucciones actuales para que veas exactamente bajo qué reglas opera el agente, y te permite editarlas. Como es texto, puedes mantener tus instrucciones en un archivo bajo control de versiones y tratar un cambio en el comportamiento del agente como cualquier otro cambio revisado, con un diff y un historial, en lugar de una edición misteriosa que alguien hizo en un panel de configuración hace tres semanas.

Si te llevas un solo hábito de esta guía, que sea ese. Que el comportamiento de un agente vaya a la deriva porque nadie puede ver quién cambió qué es la forma más común en que estos despliegues fallan silenciosamente.

Paso 4: simular antes de soltarlo

Aquí está la parte que la mayoría de la gente se salta, y la parte por la que yo lucharía.

Hemos pasado años poniendo agentes de IA en colas de soporte en vivo, y la lección que se quedó grabada es que un bot que suena seguro de sí mismo no es lo mismo que uno correcto. Un modelo dará con gusto una respuesta equivocada con voz tranquilizadora. La única forma de detectar eso antes de que lo haga un cliente es probarlo contra la realidad primero.

eesel hace esto como una simulación que reproduce tus tickets pasados y puntúa las respuestas del agente frente a lo que tu equipo realmente envió. La invocas pidiendo, por ejemplo, ejecutar una simulación sobre tus tickets recientes. Te devuelve dónde el agente habría coincidido con tu equipo, dónde habría fallado y qué cambiar en las instrucciones. Una cosa que deliberadamente no hace es inventar una tasa de resolución o una previsión de costos, y yo desconfiaría de cualquier herramienta que afirme hacerlo, porque ese número es una suposición disfrazada de medición.

Ejecuta la simulación, lee las brechas, corrige las instrucciones del Paso 3 y vuelve a ejecutarla. Ese bucle es todo el sentido de hacer esto desde la terminal: cada pasada es un comando que puedes repetir, no un recorrido de clics que tienes que recordar.

Paso 5: disparar ejecuciones y leer el registro de actividad

Ahora lo operas. Habla con el agente directamente:

eesel chat "Where is my order #DL-4821?"

Y lee lo que ha estado haciendo, lo más reciente primero:

eesel activity

eesel activity es la superficie de observabilidad. Lista las ejecuciones para que puedas detectar patrones, y puedes abrir una ejecución individual para ver exactamente qué leyó, decidió e hizo el agente. Cuando algo se ve raro, aquí es donde miras antes que en cualquier otro lugar. Los errores también están estructurados: un comando fallido imprime una única línea JSON en stderr con un error, una hint y si es retryable, y sale con un código distinto de cero. Eso es lo que hace que la CLI sea segura para conectar a un job de CI. Un script puede distinguir entre "escribiste mal el comando" y "el servicio tuvo un tropiezo, inténtalo de nuevo".

Paso 6: proteger las acciones con aprobaciones

No tienes que elegir entre un agente totalmente autónomo y uno inútil. El término medio es una cola de aprobaciones con humano en el bucle, y es una funcionalidad de primera clase en la línea de comandos.

eesel approvals list
eesel approvals approve <id>
eesel approvals deny <id>

Cuando el agente quiere realizar una acción en la que aún no confías del todo, esta cae en la cola de aprobaciones en lugar de simplemente suceder. La revisas desde la terminal y la apruebas o la rechazas. Una vez que un tipo particular de acción se ha ganado tu confianza, promuévela a automática:

eesel approvals approve <id> --always

Así es como aumentas la autonomía de forma gradual en lugar de accionar un interruptor aterrador. Empieza con todo bajo protección, observa lo que propone el agente y usa --always para entregar las acciones que has visto que hace bien, una categoría a la vez.

Más allá de la CLI: las otras tres superficies de control

La CLI es la superficie en la que vivirás, pero no es la única forma de operar el agente. Ayuda ver el conjunto completo, porque cada una responde a una pregunta distinta.

• Servidor MCP, para cuando otra IA es la operadora. Todo espacio de trabajo de eesel es también un servidor MCP. Ejecutar npx @eesel/cli mcp token imprime una URL, un token de 30 días y un comando claude mcp add listo para pegar, para que un cliente como Claude pueda llamar a las mismas operaciones como herramientas. Así es como dejas que un agente de programación gestione tu agente de soporte.
• Webhooks, para cuando un evento externo debe activar al agente. Una URL de webhook única despierta al agente cuando algo sucede en otra parte de tu stack, para que un nuevo pedido o el envío de un formulario puedan iniciar una ejecución sin que nadie escriba un comando.
• Network Access, para cuando el agente necesita comunicarse hacia afuera. Autorizas un dominio y adjuntas un encabezado de autenticación, y el agente puede entonces llamar a esa API REST con GET, POST, PATCH o DELETE durante una ejecución. Las credenciales se almacenan como encabezados y nunca se muestran al modelo, que es el detalle que preguntará tu equipo de seguridad.

Para entornos headless, te saltas por completo el inicio de sesión interactivo: define EESEL_API_URL y EESEL_API_TOKEN (y EESEL_AGENT_ID para fijar un agente específico) como variables de entorno, y la CLI se autentica a partir de ellas. Eso es lo que hace que encaje limpiamente en un pipeline de CI.

Errores comunes que evitar

Algunas cosas que he visto tropezar a la gente, para que te ahorres la lección:

• Salir a producción sin simular. El error más costoso de esta lista. Ejecuta el Paso 4. Siempre.
• Editar las instrucciones a mano con prisa. Si el comportamiento de tu agente no está en control de versiones, eventualmente tendrás una caída que nadie podrá explicar. Trata la salida de eesel instructions como código.
• Activar la autonomía total el primer día. Empieza con todo en la cola de aprobaciones y gánate cada promoción --always. La confianza se construye una categoría de acción a la vez.
• Ignorar los códigos de salida. La CLI devuelve errores estructurados y salidas distintas de cero por una razón. Un script que no los verifique pasará alegremente por encima de un fallo.
• Asumir que existe una API REST. Si estás evaluando a un proveedor y tu plan depende de un endpoint REST documentado, confirma que existe antes de construir sobre él. Con eesel, la respuesta honesta es que la CLI, MCP, los webhooks y Network Access son la superficie, y eso es más que suficiente para controlar un agente, aunque no es lo mismo que un producto REST.

Prueba eesel

Si quieres un agente de soporte que puedas operar de verdad desde la terminal, eesel está construido para eso. La CLI se instala con un solo comando, se conecta al helpdesk que ya usas, simula contra tus tickets pasados reales antes de tocar una conversación en vivo, y mantiene cada acción detrás de una cola de aprobaciones hasta que indiques lo contrario. Los precios se basan en el uso, a 40 centavos por ticket gestionado, y la prueba gratuita incluye 50 dólares de uso sin tarjeta de crédito, para que puedas scriptear todo el despliegue y verlo funcionar antes de gastar nada.