Saltar al contenido principal
Operaciones y monitorización

Toda organización tiene solicitudes que dos equipos creen que le pertenecen al otro

Las solicitudes internas llegan descritas por el problema de quien pide, no por tu organigrama. Alguien necesita acceso a un sistema, alguien necesita que le reemplacen un dispositivo y alguien necesita un reporte que vio una vez. Ninguno sabe qué equipo hace qué.

Un formulario de enrutamiento empuja ese trabajo hacia quien pide y aun así se equivoca, porque las categorías las escribieron los equipos, no las personas que preguntan.

La dificultad real es el solapamiento. Una solicitud de laptop durante la incorporación podría venir de TI o de RR. HH. Una solicitud de acceso podría venir de TI o de seguridad. Toda organización tiene tres o cuatro de esos casos en los que ambos equipos creen, con razón, que es del otro.

El agent decide esos casos contra las reglas que tus equipos acordaron de antemano, declara qué regla aplicó y deja visible su razonamiento, para que se discuta la regla, no el enrutamiento.

Cómo se construye el agent en Agent Studio

Las reglas de titularidad viven en los prompt skills, escritas como las acordaron tus equipos, incluidos los casos de solapamiento y qué equipo posee cada uno. Esos dueños se deciden, no se infieren.

Un segundo prompt skill sostiene las solicitudes que cada equipo de hecho atiende, en sus propias palabras, lo que enruta mejor que cualquier lista de categorías.

El system prompt exige que la regla aplicada se nombre en cada enrutamiento, para que un enrutamiento incorrecto se pueda rastrear hasta una regla y corregirse una vez, en lugar de discutirse una y otra vez.

Exige que el agent enrute, no que retenga. Una solicitud que no se puede colocar se enruta a un dueño de respaldo declarado, porque una solicitud sin enrutar es peor que una mal enrutada.

Las solicitudes llegan por un nodo Slack o Email. El nodo Agent Chat lee cada una desde un nodo HTTP Request, con el rol y la ubicación de quien pide anexos.

Un nodo Switch entrega a la cola del equipo dueño en Jira o Monday, con la solicitud, la regla aplicada y el contexto de quien pide.

El agent no cumple nada. No se otorga ningún acceso. No se hace ninguna compra. Google Sheets registra cada decisión de enrutamiento contra dónde aterrizó al final la solicitud, y expone una regla que ya no coincide con la realidad.

De qué está hecho este agent

  • Prompt skills: reglas de titularidad como las acordaron tus equipos, incluidos los solapamientos.
  • Prompt skills: lo que atiende cada equipo, en las palabras de ese equipo.
  • System prompt: la regla aplicada se nombra en cada enrutamiento.
  • System prompt: enruta en lugar de retener. Una solicitud que no se puede colocar va a un respaldo declarado.
  • Slack (Communication) con HTTP Request (Util): la solicitud, más el rol y la ubicación de quien pide.
  • Switch (Control) con Jira (Integration): entrega a la cola dueña con la regla anexa.
  • Cuando un ActionFlow basta: Si las categorías son de verdad distintas, enrutar por palabra clave a una cola de equipo es un flujo de trabajo.

Preguntas frecuentes

Empieza a crear flujos de IA

Crea una cuenta gratuita, abre una plantilla o un lienzo en blanco y ejecuta tu primer ActionFlow.

Boletín

Recibe actualizaciones del producto

Nodos nuevos, agents y notas de producto. Solo enviamos correo cuando merece la pena abrirlo.

Cancela la suscripción en cualquier momento.