agentes de back office
Agentes de IA que vacían sus colas, en producción en 14 días
Alguien en su empresa lee un ticket, abre tres sistemas, copia campos de uno a otro y escribe una nota. Ese es un trabajo que un agente hace bien, y lo construimos: llamadas tipadas a Salesforce, SAP, Jira, su AS/400 o su propia API, un paso de aprobación en todo lo que escribe y un registro por decisión que muestra qué leyó y por qué actuó. El primer flujo tarda catorce días, y el segundo va más rápido porque los adaptadores ya están puestos.
14 días para el primer flujo; el segundo va más rápido porque los adaptadores ya existen
El script de RPA está tachado porque se rompe el día en que un proveedor mueve un botón. Los adaptadores van por API, y donde no hay API la construimos.
Cola manual
Personas clasificando tickets, copiando entre sistemas y siguiendo un runbook que vive en un PDF.
- ticket queuehumans triage
- copy-paste between systemsmanual
- runbook.pdftribal knowledge
- RPA scriptbreaks on redesign
Agente con aprobación
Un agente, adaptadores tipados, un paso de aprobación explícito, una línea de auditoría por decisión.
- agentGo · tool calls
- system adapterstyped
- human approvalexplicit gate
- audit trailper decision
14 días para el primer flujo; el segundo va más rápido porque los adaptadores ya existen
Cómo va el trabajo
- 01días 1–2
Elegir el flujo con una cuenta
Volumen por minutos por caso, menos los casos que van a seguir necesitando a una persona. Esa multiplicación la hacemos con usted el primer día y empezamos por la cola que se paga antes.
- 02días 2–5
Escribir los adaptadores
Llamadas tipadas a sus sistemas, con los modos de fallo tratados: límites de peticiones, registros escritos a medias, el endpoint que devuelve 200 con un error dentro del cuerpo.
- 03días 5–10
Ponerlo en modo sombra
El agente propone, una persona decide y cada desacuerdo vuelve al conjunto de evaluación. Todavía no cambia el trabajo de nadie y usted obtiene una cifra real de acierto sobre sus propios casos.
- 04días 9–14
Abrir la mano una acción cada vez
Las acciones con buen historial y poco radio de daño pasan a automático primero. El resto se quedan con aprobación tanto tiempo como usted quiera, incluido para siempre.
Qué hace la plataforma y qué hace una persona
| Qué hace la plataforma y qué hace una persona | Quién hace qué | Notas |
|---|---|---|
| Leer el runbook y el histórico de tickets | Plataforma | Incluidos los casos que se resolvieron en contra del runbook, que son los interesantes. |
| Decidir qué puede hacer el agente sin preguntar | Ingeniero | Recomendamos por tipo de acción. Usted firma, por escrito, antes de que corra. |
| Construir los adaptadores | Los dos | Generados desde el contrato de la API y luego corregidos por una persona contra lo que la API hace de verdad. |
| Arbitrar los desacuerdos del modo sombra | Los dos | Automático cuando el histórico enseña el resultado, humano cuando dos de sus expertos discutirían. |
| El rastro de auditoría | Plataforma | Entradas, herramientas llamadas, decisión, quien aprueba. Una línea buscable por caso, guardada tanto si la respuesta fue correcta como si no. |
| Las vías de escalado | Ingeniero | Qué hace el agente cuando no está seguro y quién coge el caso a las seis de la tarde de un viernes. |
La gente que hay detrás de los agentes
Decenas de migraciones y más de diez años conectando sistemas que nunca se pensaron para hablar entre ellos: SAP, Salesforce, Jira, Dynamics, un AS/400, un endpoint SOAP de 2006, un CSV que cae en un FTP cada noche. Los agentes son lo más nuevo que construimos. La integración de debajo es lo más viejo, y es la parte que decide si todo esto funciona.
El modo sombra es la prueba, y viene antes del compromiso. El agente corre contra su cola real, propone, y una persona decide. Al final tiene en la mano una cifra de acierto medida sobre sus propios casos.
Preguntas que nos hacen los ingenieros
- ¿En qué se diferencia del RPA que ya compramos?
- El RPA maneja la interfaz, así que se rompe con un rediseño y no entiende nada del caso. Un agente llama a API y sabe tratar el ticket que no encaja con el guion, que es en el que su gente se pasa el día. A cambio, el RPA es determinista y un agente no lo es, y por eso existen la aprobación y el conjunto de evaluación.
- ¿Qué le impide hacer algo caro?
- No puede llamar a una herramienta que no se le ha dado, y las herramientas que escriben están bajo aprobación por defecto. El radio de daño es una decisión de diseño que se toma por tipo de acción, antes de que corra nada, y está en el documento que usted firmó.
- ¿Cómo sabemos que acierta?
- Días de modo sombra contra su cola, un conjunto de evaluación montado con los desacuerdos, y un registro por decisión que puede abrir cuando alguien se queje de un caso concreto.
- ¿Necesitan nuestros datos para entrenar?
- Sin fine-tuning por defecto. El agente lee lo que necesita en el momento del caso, y lo que leyó está en el registro. Si más adelante quiere un modelo entrenado con su histórico, esa es una decisión aparte con su propio papeleo.
- ¿Qué pasa cuando cambiamos un sistema con el que habla?
- El adaptador es tipado, así que un cambio de contrato rompe la compilación en vez de fallar en silencio en producción el día del cierre. Esa es casi toda la razón de que escribamos adaptadores en lugar de dejar que un modelo improvise llamadas HTTP.
Mándenos una cola
Describa el trabajo tal como lo hace hoy una persona, incluido el paso en el que comprueba algo. Cuántos casos al mes y cuánto se tarda en uno. Con esos dos números y un día le decimos cuánto ahorraría.
El formulario pregunta por el volumen de casos y el tiempo de resolución. Esos dos números deciden casi todo.