Cómo estamos diseñando los despliegues de agentes en SOVRAS

Cuando una empresa quiere que un agente prepare una cotización, la conversación suele ser la parte más sencilla. El trabajo está en consultar el stock correcto, aplicar las condiciones comerciales, comprobar los datos del cliente y saber cuándo corresponde pedir una aprobación.

Todo eso ocurre detrás de una solicitud que, para el usuario, debería ser simple.

En SOVRAS estamos construyendo la plataforma alrededor de este tipo de operaciones. Y desde ingeniería hay una pregunta que influye directamente en cómo diseñamos el producto: ¿cuánto de cada implementación podemos reutilizar cuando llega el siguiente cliente?

Primero hay que entender cómo trabaja la empresa

Una empresa puede entregarnos sus procedimientos, documentación y acceso a los sistemas. Es un buen punto de partida, pero todavía necesitamos entender cómo se toman las decisiones durante el trabajo.

Por ejemplo:

• ¿Qué ocurre cuando el stock no alcanza?
• ¿Un ejecutivo puede autorizar otro precio?
• ¿Qué sistema confirma que la orden quedó registrada?
• ¿Quién retoma la operación cuando aparece una excepción?

Son detalles que cambian bastante entre empresas, incluso cuando quieren automatizar exactamente el mismo proceso.

Por eso nuestro onboarding combina el producto con trabajo de ingeniería.

Desde Agent Studio se pueden definir agentes, incorporar conocimiento, configurar herramientas y establecer reglas. Pero cuando hay integraciones complejas o procesos que necesitan mayor precisión, nuestros ingenieros trabajan directamente con el cliente para modelarlos, conectar los sistemas y preparar las pruebas.

Parte del trabajo ocurre en la plataforma y otra parte en reuniones técnicas, revisiones de procesos y validaciones con las personas que conocen la operación.

Qué construimos una vez y qué adaptamos

Pensemos en dos distribuidoras. Una calcula los precios según el contrato de cada cliente. La otra utiliza una lista comercial y exige autorización cuando el descuento supera cierto porcentaje.

Ambas necesitan agentes capaces de preparar cotizaciones, pero sus reglas son diferentes.

No tendría sentido desarrollar dos sistemas completos para administrar esos casos, registrar las acciones, incorporar aprobaciones o supervisar los resultados.

Esa infraestructura pertenece a SOVRAS.

Agent Studio permite configurar los agentes alrededor de cada operación. VARO coordina el trabajo entre agentes, sistemas y personas, conservando el estado del caso mientras avanza.

Lo que adaptamos son las herramientas, las fuentes de información, las políticas y las condiciones bajo las cuales una operación puede continuar.

Esto también exige tomar decisiones durante cada implementación. Algunas necesidades se resuelven configurando componentes existentes. Otras requieren desarrollar una integración o ampliar una capacidad de la plataforma.

Nuestro trabajo es reconocer esa diferencia y evitar que cada particularidad termine convertida en código aislado que nadie más pueda aprovechar.

Los casos difíciles también forman parte del despliegue

Una demostración puede mostrar una cotización que comienza y termina sin problemas. En producción tenemos que considerar lo que ocurre cuando algo falla.

• Un ERP puede dejar de responder después de recibir una solicitud.
• Una aprobación puede quedar pendiente durante horas.
• Una operación puede interrumpirse después de haber actualizado uno de varios sistemas.

Esas situaciones necesitan un tratamiento definido: comprobar qué se ejecutó, conservar el estado y decidir cómo continuar sin repetir acciones que ya tuvieron efecto.

Por eso trabajamos con reglas de ejecución, supervisión y pruebas de escenarios antes de entregar mayor autonomía a los agentes. VARO Arena forma parte de esa preparación.

También importa lo que sucede después del despliegue. Los errores encontrados y los cambios de comportamiento deben poder convertirse en nuevas pruebas y mejoras para los siguientes agentes.

Hacer que cada implementación deje algo reutilizable

Cuando una integración se repite, tiene sentido convertirla en un componente que pueda aprovechar otro cliente. Lo mismo ocurre con una validación, una política de aprobación o un escenario de prueba que antes resolvíamos manualmente.

Eso es parte de cómo estamos desarrollando SOVRAS.

Queremos que los equipos de las empresas puedan configurar progresivamente más operaciones desde la plataforma, mientras nuestros ingenieros se concentran en los sistemas, las excepciones y las decisiones técnicas que necesitan un trabajo más cercano.

No significa que todos los clientes vayan a tener un onboarding idéntico. Una implementación sencilla y una operación que involucra varios sistemas internos seguirán necesitando esfuerzos diferentes.

Lo importante es que ese trabajo contribuya también a mejorar el producto.

Si tenemos que desarrollar la misma solución desde cero para tres clientes distintos, hay algo que deberíamos haber incorporado a la plataforma antes.