Cómo integrar agentes de IA en tu stack empresarial (guía 2026)

Resumen

Para integrar un agente de IA en tu stack empresarial, piensa en tres tareas, no en una gran conexión: qué lee (centro de ayuda, tickets anteriores, Confluence, Notion, Google Drive), qué lo activa (un ticket nuevo, una mención en Slack, un webhook de tus propios sistemas) y qué puede hacer (etiquetar, responder, consultar un pedido, reembolsar). Conecta en ese orden, primero solo lectura, y pon toda acción que mueva dinero detrás de una aprobación humana.

Los permisos son donde fallan la mayoría de los despliegues. Un agente solo puede ver lo que ve el usuario que lo conecta, lo que permiten los scopes y lo que compartes de forma explícita. Los tokens de API de Zendesk pueden suplantar a administradores, una clave de API de Freshdesk hereda el rol de una sola persona, el scope read_orders de Shopify solo cubre los últimos 60 días, y una conexión nueva de Notion no ve nada hasta que la añades a una página. Elige OAuth en lugar de tokens personales, da al agente su propia identidad acotada y prueba con tickets pasados antes de que un cliente vea una respuesta.

El compañero de IA para helpdesk de eesel está construido justo sobre esta división. Se une a tu helpdesk existente, lee tus herramientas de conocimiento, llama a tus propias APIs mediante una lista de permitidos, y cada acción se configura como automática, preguntar antes o desactivada. Puedes configurarlo todo desde el panel, la CLI de eesel o un cliente MCP, y un ticket cuesta un crédito sin importar cuántos sistemas toque.

Qué significa realmente integrar un agente de IA en tu stack

Trabajo en el producto de eesel, lo que sobre todo significa construir los conectores que permiten a un compañero de IA trabajar dentro de las herramientas de otras personas. Lo más útil que he aprendido es que la IA rara vez es el eslabón débil. Lo es la fontanería. En una prueba con tráfico real en una bandeja de comercio electrónico con Zendesk y Shopify (unos 1.000 tickets al mes), aproximadamente el 65 % de las ediciones que hacían los agentes a los borradores de la IA eran sobre tono y longitud, y solo un 5 % aproximadamente porque la IA se equivocara en los hechos. Cerca del 20 % de las ediciones se debían a que la respuesta necesitaba datos de un sistema al que el agente aún no estaba conectado, como el ERP o el proveedor de logística. Mejores prompts no arreglan ese 20 %. Más integración, sí.

Así que cuando una responsable de soporte me pregunta cómo "conectar IA a nuestro stack", divido la pregunta en tres partes. La documentación de eesel describe cada integración de la misma forma, como una mezcla de fuentes, disparadores y acciones, y ese modelo sirve para cualquier proveedor que evalúes:

• Leer. El conocimiento con el que responde. Artículos del centro de ayuda, tickets pasados y macros, wikis internas, documentación de producto, políticas.
• Activarse. Los eventos que inician el trabajo. Un ticket nuevo, un mensaje de un cliente, una @mención en Slack, un webhook de tu sistema de almacén, una programación.
• Actuar. Lo que puede cambiar. Etiquetar y enrutar un ticket, dejar una nota interna, enviar una respuesta, consultar un pedido, iniciar una devolución, emitir un reembolso.

Algunas herramientas hacen las tres cosas. Un helpdesk como Zendesk es una fuente (tickets, macros, centro de ayuda), un disparador (ticket nuevo) y una superficie de acción (responder, etiquetar, asignar). Otras son solo fuentes: Confluence, Notion y Google Drive se leen, nunca se escribe en ellos. Tu propia base de datos de pedidos suele ser solo de acciones. Ordenar tu stack así te dice qué conexiones son de bajo riesgo (lecturas) y cuáles necesitan barreras reales (escrituras).

Si primero quieres una visión más amplia de los agentes y las herramientas de negocio, mis compañeros escribieron una introducción sobre agentes de IA y herramientas de negocio. Este artículo es la versión práctica para responsables de soporte u operaciones.

Paso 1: Mapea tu stack antes de conectar nada

Antes de tocar una página de ajustes, escribe una fila por cada sistema que el agente va a necesitar. Lleva 20 minutos y te evita el fallo más común que veo: conectar el helpdesk, obtener respuestas decentes y descubrir después que las preguntas más frecuentes de los clientes ("¿dónde está mi pedido?", "¿por qué me cobraron dos veces?") necesitan datos que viven en otro sitio.

Después marca en cada fila qué se rompe si el agente se equivoca. Una mala respuesta de la wiki te cuesta una corrección. Un reembolso al pedido equivocado te cuesta dinero. Ese es el orden en que los conectarás.

Construí el planificador de abajo para que marques lo que hay en tu stack y obtengas el orden en que yo lo conectaría, con la trampa de permisos de cada sistema sacada de la documentación del propio proveedor.

Paso 2: Conecta el conocimiento que lee, y solo el conocimiento en el que confías

El conocimiento es la capa más segura para empezar porque todas las conexiones son de solo lectura. También es donde se decide la calidad. La IA repetirá lo que le des, más rápido de lo que podría cualquier persona:

"He visto a un bot dar respuestas erróneas con total seguridad porque la base de conocimiento llevaba 8 meses sin actualizarse. Los clientes no solo recibieron malas respuestas. Las recibieron al instante."

u/Agile_Plankton_543, r/salesforce, Reddit

Tres fuentes importan más que el resto:

1. Tickets pasados y macros. Así responde de verdad tu equipo, incluidos los casos límite para los que nadie escribió un artículo. Si el agente de un proveedor no puede aprender de tickets resueltos, trabaja solo con tu documentación en el mejor de los casos. Hay más sobre esto en la guía de mi colega sobre entrenamiento con la base de conocimiento.
2. El centro de ayuda. Público, estructurado y normalmente lo más actualizado. Vale como punto de partida, pero solo se queda corto.
3. Wikis y documentos internos. Confluence, Notion, Google Drive, SharePoint. Aquí viven las excepciones de reembolso y las reglas de escalado.

Cada herramienta de wiki tiene su propio modelo de permisos, y todas parten de "menos de lo que crees":

• Notion ahora llama "conexiones" a las integraciones. Una conexión solo ve las páginas que se compartieron con ella: "Si la página no está compartida, cualquier solicitud a la API responderá con un error" (documentación de autorización de Notion). Leer, actualizar e insertar son capacidades separadas, así que puedes conceder solo lectura.
• Confluence Cloud: las apps actúan en nombre de un usuario, y "los permisos del usuario en cuyo nombre actúa una app siempre limitan a la app, sin importar los scopes de la app" (documentación OAuth de Atlassian). Los espacios restringidos requieren añadir la app de forma explícita.
• Google Drive tiene un scope amplio, drive.readonly, que Google clasifica como restringido, y almacenar esos datos en un servidor activa una evaluación de seguridad (documentación de scopes de Drive). Por eso la mayoría de las herramientas te piden elegir archivos y carpetas.

Por el lado de eesel, el conector de Confluence es de solo lectura por diseño, y el conector de Notion solo lee, salvo que actives su única acción de escritura de propósito general, que está desactivada por defecto.

La segunda lección trata de la sincronización. Los conectores de conocimiento suelen ser una copia tomada en un momento dado, no un flujo en vivo, y fallan en silencio. He visto a un cliente irse por esto: su fuente de datos principal era una hoja de cálculo de estado de pedidos en Google Drive que cambiaba a diario, la sincronización falló en silencio tres veces y se fue a una herramienta más barata. Pregunta a cada proveedor cómo llegan los archivos nuevos y cómo te enterarías de que una sincronización se rompió. En el caso de eesel las respuestas varían por herramienta, y la documentación lo dice con claridad: las páginas de Confluence se reindexan cuando las editas y la app concilia aproximadamente una vez por hora (documentación de Confluence), mientras que un archivo nuevo de Google Drive hay que volver a seleccionarlo en el selector y un espacio de trabajo puede sincronizar hasta 2.500 archivos al día (documentación de Google Drive).

Revisa también los formatos que tu equipo usa de verdad. Una marca DTC de suplementos en una llamada de ventas de eesel (unos 7.000 tickets de Gorgias al mes) guardaba sus procedimientos reales en SOPs de ClickUp y vídeos de Loom, con un montón de macros desactualizadas encima. Un conector de texto no puede leer nada de eso hasta que alguien lo escribe. Si es tu caso, el trabajo de la base de conocimiento de IA va antes que el de integración.

Paso 3: Conéctalo al helpdesk donde ya viven los tickets

El helpdesk es la integración que más importa, porque cumple las tres tareas a la vez. Mi opinión firme: pon el agente dentro del helpdesk que tu equipo ya usa en lugar de sacar los tickets a una bandeja de IA aparte. Tus agentes conservan sus vistas, macros y SLAs, y el trabajo de la IA aparece como notas y respuestas en el mismo ticket. Así debería ser una integración de IA con el helpdesk.

Lo que cambia según el helpdesk es cómo se autentica una app externa, con qué identidad actúa y cuánto puede llamar. Esto dice la documentación para desarrolladores de cada proveedor:

Tres cosas de esa tabla cambian cómo lo configuraría:

• Usa OAuth, no el token de API de una persona. Zendesk dice que los proveedores que atienden a muchos clientes "deben usar tokens de acceso OAuth globales" (documentación de autenticación de Zendesk). Un token ligado a una persona también deja de funcionar el día que esa persona se va. Si tu helpdesk solo ofrece claves personales, crea un puesto de agente dedicado con un rol acotado para la IA y genera la clave desde ese puesto.
• Los límites de uso son compartidos. En el plan Team de Zendesk, 200 solicitudes por minuto cubren tu IA, tu sincronización con el CRM y cualquier otra app. Zendesk también limita las actualizaciones de un mismo ticket a 30 cada 10 minutos por usuario (límites de uso). Un agente que etiqueta, anota y responde en llamadas separadas lo agota más rápido de lo que esperas. El desglose de mi colega sobre los límites de la API de Zendesk profundiza más.
• Empieza con notas internas. Todos los helpdesks anteriores pueden publicar una nota privada. Es tu primera semana más segura: la IA redacta, una persona lee y envía, y nada llega a un cliente por accidente.

También tendrás que decidir entre la IA integrada del helpdesk y una capa que se conecte a él. Los agentes integrados como Zendesk AI, Freddy AI Agent o Agentforce son los que menos configuración requieren, pero su alcance fuera del helpdesk suele ser más estrecho de lo que sugiere la demo. Un revisor lo expresó así sobre Gorgias:

"El agente de IA sigue el mismo patrón: ofrece funcionalidad completa solo para Shopify y exige una configuración incómoda de un correo por tienda que no encaja en todos los negocios."

Frank A., Capterra

Es un comentario justo de un revisor de 5 estrellas, y es la pregunta correcta para cualquier proveedor: ¿las acciones funcionan en mi stack o solo en el de la demo? Yo también he estado en el lado perdedor. A principios de este año eesel perdió acuerdos de mercado medio porque no existía un conector nativo de helpdesk para Salesforce o HubSpot. Ambos existen ya (Salesforce, HubSpot), pero la lección sigue en pie. La lista de conectores es un filtro duro, así que revísala primero.

Así se ve una conexión completa con Zendesk en eesel: centro de ayuda, macros y tickets pasados como tres fuentes independientes, cada una con su propio interruptor, para que puedas dejar una fuera.

La documentación del helpdesk de eesel dice algo que ojalá dijera todo proveedor: "Conectar solo permite a tu agente leer tu helpdesk. No hace nada en los tickets hasta que creas una automatización." (documentación del helpdesk). Conectar y salir en vivo son dos pasos distintos, y conviene mantenerlos separados.

Paso 4: Conecta acciones a tu tienda, facturación y sistemas internos

Esta es la capa que convierte un bot de respuestas en algo que cierra tickets. También es donde un error cuesta dinero. La mayoría de los tickets de "dónde está mi pedido", "cambiar mi dirección" y "reembólsenme" necesitan una consulta o una escritura en un sistema que no es tu helpdesk.

Shopify y otras tiendas

Shopify es el que más veo, y sus scopes de acceso tienen dos trampas que conviene conocer antes de conectar:

• read_orders y write_orders "cubren los pedidos creados en los últimos 60 días. Para pedidos más antiguos, añade read_all_orders, para el que debes solicitar acceso" (scopes de acceso de Shopify). Un agente que no encuentra un pedido de hace tres meses le dirá al cliente que no existe.
• Cancelar requiere write_orders, y la propia documentación de Shopify dice de orderCancel: "Esta acción no se puede revertir" (orderCancel). El nombre, correo, teléfono y dirección del cliente son además datos protegidos de nivel 2, que requieren una revisión adicional para las apps (datos protegidos de clientes).

La integración con Shopify de eesel divide sus acciones en un grupo de lectura (obtener un pedido, historial de pedidos, cumplimiento y seguimiento) y un grupo de escritura (crear una devolución, actualizar una dirección de envío, reembolsar, cancelar). La documentación también señala que ahora solicita el permiso de Shopify para leer todos los pedidos, pero una tienda conectada antes de ese cambio mantiene el límite de 60 días hasta que alguien la reconecte (documentación de Shopify de eesel). Ese es justo el tipo de detalle que debes comprobar en tu propia configuración. Para una explicación más detallada, mira cómo conectar los datos de pedidos de Shopify a un agente de soporte.

Facturación y pagos

Nunca des a un agente de IA tu clave de pago secreta. La guía de Stripe es directa: "Las RAK son el tipo de clave recomendado para las claves de API que das a agentes de IA" (claves restringidas de Stripe). Una clave restringida define Lectura, Escritura o Ninguno por recurso, de modo que un agente de soporte puede leer cobros y facturas sin poder tocar los pagos. Stripe también te permite etiquetar una clave como clave de agente, y las claves etiquetadas reciben por defecto reglas de aprobación en pagos, reembolsos y cambios de cuenta (claves de API de Stripe).

Tus propios sistemas (base de datos de pedidos, almacén, ERP)

Para todo lo que no tiene un conector ya hecho, el patrón es una llamada a API en lista de permitidos. Le indicas al agente a qué dominio puede llamar y qué cabecera de autenticación enviar, y la plataforma adjunta la credencial en el servidor para que el modelo nunca la vea. En eesel esto es Network Access: las solicitudes a cualquier dominio que no hayas añadido se rechazan, admite GET, POST, PATCH y DELETE, y "las credenciales permanecen en tus ajustes y eesel las adjunta a cada solicitud, así que la IA nunca las ve."

Uses la herramienta que uses, comprueba que una acción funciona de verdad antes de dejar que el agente hable de ella. Un modelo que ha leído tu política de reembolsos ofrecerá encantado reembolsos que no tiene forma de procesar. Un revisor de Ada en G2 vio justo esto, con el agente ofreciendo cancelar pedidos que no podía cancelar:

"A veces, Ada ha dado respuestas o compromisos que no formaban parte de su entrenamiento original ... Por suerte, estos problemas han sido fáciles de corregir con coaching y actualizaciones adicionales, y su precisión ha seguido mejorando con el tiempo."

Revisor verificado, G2

La solución está tanto en las instrucciones como en la integración: dile al agente qué acciones existen y qué decir cuando un cliente pide una que no existe. La guía de mi colega sobre automatizar reembolsos con IA cubre la parte de políticas.

Paso 5: Define los permisos antes de definir los disparadores

Este es el modelo mental que uso. Un agente de IA nunca ve "tu stack". Ve la intersección de cuatro límites, y cada uno lo fija una persona distinta:

1. El usuario que conecta. Las apps de Confluence están limitadas por el usuario que autoriza, una clave de Freshdesk por el rol de ese agente, una connected app de Salesforce por su usuario Run As. Quien pulsa "Permitir" define el techo.
2. Los scopes. Lo que la app pidió al instalarse. La propia pantalla de scopes de HubSpot lo dice claro: pide el menor número de scopes posible.
3. Lo que compartiste o elegiste. Páginas de Notion añadidas a la conexión, carpetas de Drive en el selector, canales de Slack a los que se unió.
4. Lo que el agente puede hacer con ello. Los ajustes por acción dentro de la propia herramienta de IA.

El cuarto límite es el que controlas a diario, y donde yo pondría más cuidado. En eesel, cada acción se configura como Automática, Requiere aprobación o Desactivada, por agente, y una acción que no has activado "no está disponible para el modelo en absoluto, se le pida lo que se le pida" (documentación de seguridad de eesel). La orientación de la documentación de acciones y aprobaciones es la configuración que copiaría en cualquier sitio: mantén las respuestas y todo lo irreversible bajo aprobación al principio, y deja "los reembolsos, cancelaciones y todo lo que cueste dinero detrás de una aprobación."

El fallo de integración más temible no es una respuesta equivocada. Es una respuesta de apariencia correcta construida con los datos del cliente equivocado:

"el mayor fallo que he visto fue un agente que seguía sacando datos de la cuenta de otro usuario porque el token de sesión no se pasaba bien a la llamada a la API; las respuestas de texto se veían perfectas, así que nadie se dio cuenta hasta que un cliente se quejó de ver el saldo de otra persona"

u/properwomanhood_292, r/AI_Agents, Reddit

Salesforce señala el mismo riesgo en su guía de seguridad de Agentforce: cuando un agente de servicio invoca una acción, "se usa la identidad del agente", así que tu propio código debe comprobar a qué cliente pertenecen los datos (documentación de Salesforce). Sea cual sea tu plataforma, consulta los datos de pedidos y cuentas por la identidad del ticket y prueba con dos clientes de nombres parecidos. Si manejas datos regulados, infórmate también sobre SOC 2 y RGPD para la IA de soporte.

Paso 6: Decide qué activa al agente

Una vez que puede leer y actuar, el agente necesita un motivo para empezar. Hay tres tipos de disparador, y la mayoría de los stacks usan los tres.

Eventos del helpdesk. Un ticket nuevo, una respuesta del cliente, una @mención en una nota interna. Vienen de la integración con el helpdesk. Vigila las reglas de entrega: las integraciones HTTP de Gorgias agotan el tiempo a los 5 segundos, no reintentan un 429 o 500 y se desactivan tras 500 fallos seguidos (integraciones HTTP de Gorgias). Hay más en la guía de webhooks de Gorgias. Los webhooks de HubSpot también agotan el tiempo a los 5 segundos, y las acciones personalizadas de Zendesk a los 10. Un backend de IA lento tiene que confirmar primero y hacer el trabajo después, o se pierden eventos. Hay una guía completa de webhooks de Zendesk si construyes el tuyo.

Menciones en el chat. Slack es donde suelen llegar las aprobaciones y las preguntas internas, y la integración con Slack de eesel pregunta antes de unirse a cualquier canal. Un límite que debes conocer si construyes tu propio bot: desde el 29 de mayo de 2025, las apps nuevas de distribución comercial que no están en el Marketplace de Slack reciben "1 solicitud por minuto" y "un máximo de 15 objetos por solicitud" en conversations.history y conversations.replies (registro de cambios de Slack). Las apps personalizadas internas mantienen más de 50 solicitudes por minuto. El motivo declarado por Slack era evitar la exfiltración masiva de datos, así que no planees una arquitectura que copie todo tu historial de Slack a una IA.

Webhooks de tus propios sistemas. Este es el disparador que la gente olvida. Un retraso en el almacén, un pago fallido o un registro nuevo pueden activar al agente con datos adjuntos. En eesel, una automatización por webhook te da una URL privada a la que cualquier sistema (Zapier, Make, tu backend) puede enviar JSON por POST. Envía una cabecera X-Eesel-Event-Id y los reintentos se procesan exactamente una vez. Un espacio de trabajo admite 60 entregas por minuto, y una entrega que tus instrucciones filtren no se factura.

En el ejemplo de la documentación, llega un payload de retraso de envío, el agente busca el pedido de Shopify correspondiente, no lo encuentra y abre un ticket etiquetado en Gorgias para el equipo. Son tres sistemas en una sola ejecución, sin que nadie copie datos entre pestañas.

Paso 7: Prueba con tus propios tickets pasados antes de salir en vivo

Probar la integración de un agente de IA no es "¿la API devuelve 200?". Es "¿da el agente la respuesta que habría dado mi equipo, con los datos a los que ahora llega?". Tus mejores datos de prueba son los tickets resueltos del mes pasado. No repetiré aquí el método completo, porque hay un artículo entero sobre cómo elegir un agente de IA de soporte que lo cubre, pero tres comprobaciones son específicas de la integración:

• Muestrea tickets que necesiten cada sistema. Si el 30 % de tus tickets son de estado de pedido, el 30 % de tu conjunto de prueba también debería serlo. Si no, solo estás probando el centro de ayuda.
• Verifica las acciones, no solo las palabras. Revisa qué consultas y escrituras intentó el agente, y sobre qué registro. Una respuesta perfecta construida sobre el pedido equivocado es un fallo.
• Puntúa la brecha por tema. En eesel, la habilidad de Simulación reproduce tickets resueltos y compara cada respuesta con lo que tu equipo envió realmente. La ejecución de ejemplo de la documentación tomó 20 tickets, 17 coincidieron, con una lista ordenada de correcciones para el resto (documentación del helpdesk). Los fallos suelen apuntar directamente a una integración que falta.

Paso 8: Despliega una capa cada vez

Activa las cosas en el mismo orden en que las conectaste, y amplía el acceso solo cuando la capa anterior haya funcionado bien durante un tiempo.

1. Conocimiento, solo lectura. Hazle preguntas internamente. Ningún cliente ve nada.
2. Helpdesk, borradores como notas internas. Los agentes leen, editan y envían.
3. Consultas de pedidos y cuentas. Los borradores ya incluyen estado y seguimiento reales del pedido.
4. Reembolsos y cambios con aprobación. El agente prepara la acción, una persona pulsa aprobar. En eesel esa aprobación puede hacerse en el panel, en un hilo de Slack o desde el terminal con eesel approvals.
5. Automático en temas probados. Solo para tipos de ticket cuyos borradores se llevan semanas enviándose tal cual.

Esto coincide con lo que recomiendan los operadores con experiencia:

"El despliegue más seguro que he visto es: que el agente redacte, etiquete la confianza más el motivo, exija aprobación para reembolsos o cambios de cuenta y revise cada conversación reabierta durante el primer mes. Ese registro de revisión suele ser donde aparece el verdadero límite de la automatización."

u/Calm-Dimension3422, r/CustomerSuccess, Reddit

Planifica el traspaso al mismo tiempo. Cuando el agente pasa un ticket a una persona, esta debería recibir un resumen de lo que ya consultó, no una transcripción en bruto. La guía de traspaso de agentes de IA tiene patrones para ello, y la guía de automatización explica qué tipos de ticket automatizar primero.

Dónde encajan MCP, las APIs y las CLIs

Oirás mucho "usa simplemente MCP" ahora mismo, así que aquí va la versión sencilla. MCP, el Model Context Protocol, es "un estándar de código abierto para conectar aplicaciones de IA con sistemas externos" (modelcontextprotocol.io). Un servidor MCP expone herramientas (acciones que una IA puede invocar) y recursos (datos que puede leer) con una forma estándar, de modo que cualquier cliente compatible con MCP puede usarlos. Es una forma más limpia de conectar las capas de "leer" y "actuar", no un sustituto de lo pensado sobre permisos más arriba. La especificación más reciente llega a decir "La autorización es OPCIONAL para las implementaciones de MCP" (especificación de autorización de MCP), así que comprueba cómo la maneja cada servidor que conectes.

Los proveedores avanzan rápido en esto. El servidor MCP Rovo de Atlassian cubre Jira, Confluence y más, usa OAuth 2.1 y respeta los permisos existentes de los usuarios (documentación de Atlassian). Shopify ya ha movido sus herramientas MCP de carrito y catálogo de la tienda a un nuevo endpoint del Universal Commerce Protocol (Shopify Storefront MCP). Espera que los endpoints sigan cambiando, y prefiere una plataforma que los mantenga por ti antes que conectar cada uno a mano. Hay una explicación más extensa sobre MCP para atención al cliente.

MCP también funciona en sentido contrario: tu agente de soporte puede ser un servidor MCP con el que hablen otras herramientas de IA. Así funciona eesel, y por eso existe la CLI de eesel.

Configurar toda la integración desde un terminal

La CLI de eesel pone al mismo compañero de IA en tu terminal. No es un producto aparte ni una copia: "Todo lo que configures en la CLI aparece en el panel, y al revés." Eso importa en el trabajo de integración, porque la configuración de este artículo se convierte en un script que puedes revisar, volver a ejecutar y entregar a un agente de programación. Una configuración de helpdesk más tienda se ve así:

npx @eesel/cli login                       # or: npm install -g @eesel/cli
eesel integrations connect zendesk         # prints an approval link for a Zendesk admin
eesel integrations connect shopify         # a store owner approves the app install
eesel integrations download start          # copy past tickets, macros and pages into knowledge
eesel integrations zendesk actions         # every action, with its auto / ask / off setting
eesel integrations api check               # custom API access for your own systems
eesel automations                          # what wakes the agent, and the instructions it follows
eesel approvals                            # held actions waiting on a human
eesel activity                             # what the agent actually did, newest first

Unos cuantos detalles la hacen muy útil para automatizar. Cada comando imprime JSON. Los errores llegan como una línea JSON con un hint que indica qué ejecutar en su lugar, y eso es lo que permite que Claude Code, Cursor o Codex ejecuten la configuración sin que una persona lea la documentación. Las escrituras hechas desde la CLI siguen los mismos ajustes de aprobación que el panel, --dry-run imprime la llamada exacta que haría una escritura sin enviarla, y EESEL_API_TOKEN junto con EESEL_AGENT_ID te permiten ejecutarla en CI. El único paso que no puede saltarse es la aprobación humana dentro de cada herramienta, que es como debe ser: un administrador de Zendesk sigue teniendo que pulsar Permitir.

Para clientes MCP, eesel mcp token imprime una línea claude mcp add lista para pegar. El token dura 30 días y lleva tu rol en el espacio de trabajo, así que un lector puede chatear y leer la actividad mientras que solo los editores pueden cambiar instrucciones o automatizaciones (documentación de clientes MCP). Mis compañeros tienen más sobre controlar agentes desde una CLI y sobre los servidores MCP de agentes de IA en general.

Errores que evitaría

• Conectar con tu propio login de administrador. El agente hereda todo lo que tú ves. Usa OAuth con una identidad dedicada y acotada.
• Conectar toda la wiki. Elige los espacios y carpetas que defenderías ante un cliente. Los borradores antiguos se convierten en respuestas erróneas dichas con seguridad.
• Activar escrituras el primer día. Primero consultas, escrituras con aprobación y automático al final.
• Suponer que la sincronización es en vivo. Averigua cómo se actualiza cada fuente y cómo notarías un fallo.
• Olvidar los límites de uso compartidos. Tu IA, tu sincronización con el CRM y tu herramienta de informes sacan del mismo presupuesto de la API del helpdesk.
• Dejar que el agente describa acciones que no puede realizar. Si no puede cancelar pedidos, sus instrucciones deben decirlo.
• Precios que penalizan la integración. Pregunta si una consulta de pedido, una comprobación en el CRM o una llamada a una herramienta cuentan como uso adicional. Algunos contadores cuentan cada mensaje o acción.

Conecta eesel al stack que ya tienes

Si estás repasando esta lista y no quieres construir a mano cada conector, el compañero de IA para helpdesk de eesel está diseñado para eso. Se une a tu helpdesk existente (Zendesk, Freshdesk, Gorgias, HubSpot, Salesforce y más), aprende de tus tickets pasados, lee Confluence, Notion y Google Drive, consulta pedidos reales en Shopify y llega a tus propias APIs mediante una lista de permitidos. Cada acción se configura como automática, preguntar antes o desactivada, y las aprobaciones pueden venir de Slack, del panel o de la CLI. Si tu helpdesk es Zendesk, la página de integración con Zendesk muestra la lista completa de lo que puede leer y hacer.

Los precios también encajan con un trabajo muy integrado. En la página de precios de eesel, un ticket es un crédito "sin importar cuántas respuestas vayan y vengan, ni lo que haga el agente dentro de él: consultar un pedido, comprobar una política, actualizar otra herramienta." Los planes empiezan en 299 $ al mes por 500 créditos, todas las integraciones están incluidas y el plan gratuito te da 100 créditos para conectar tu helpdesk y ver borradores reales antes de pagar.

Prueba eesel en tu propio stack, o reserva una demo si quieres que yo o un compañero revisemos tu configuración contigo.