Una empresa que quiere operar con agentes suele recibir dos propuestas. Un proveedor vende una plataforma y deja la integración, las evaluaciones y el mantenimiento en manos del cliente. Una consultora construye un sistema a medida y entrega el código al terminar. Las dos opciones presuponen que el cliente puede hacerse cargo de la tecnología.
Muchas empresas no tienen un departamento de producto capaz de seguir el ritmo de los modelos, cambiar la arquitectura, mantener integraciones y evaluar agentes en producción. Tampoco necesitan crearlo. Hay un tercer contrato: el proveedor conserva el software y vende la operación que ese software ejecuta. Eso es service as software.
La cadena no evoluciona en bloque
Un mapa de Wardley sitúa cada componente de una cadena de valor en una fase: génesis, custom, producto o commodity. Cada componente avanza a su ritmo. La electricidad pasó del laboratorio a la generación propia en fábricas, después a generadores comerciales y finalmente a un suministro contratado. La fase condiciona cómo se obtiene cada componente.
«Operaciones con agentes» tampoco es un solo componente. La cadena incluye modelos, orquestación, conocimiento, reglas del negocio, integraciones y controles. Aplicar una única decisión de compra a todo el conjunto oculta quién debe hacer y mantener cada parte.
Los modelos ya son utility. Se consumen por API y pueden sustituirse si la arquitectura separa el modelo del proceso. Para la mayoría de las empresas, entrenar un modelo fundacional no aporta una ventaja operativa.
La orquestación va camino de producto. Los componentes para coordinar agentes, darles herramientas, registrar sus acciones y ejecutar evaluaciones se están estandarizando. Un operador puede comprar o sustituir esas piezas sin trasladar el cambio al cliente.
La capa operativa sigue en fase custom. El proceso, sus excepciones, los permisos, las fuentes de verdad y los criterios de escalado cambian entre empresas. Un producto no puede contener decisiones que todavía solo conocen quienes ejecutan el trabajo. Esa especificidad no desaparece al comprar una plataforma.
El mandato del FDE importa
Los fabricantes de modelos ya despliegan forward-deployed engineers para llevar sus modelos a producción dentro de las empresas. Pueden acelerar la implantación, pero su trabajo tiene un mandato concreto: desplegar el stack que su compañía vende. No es un defecto del perfil; es el incentivo que el comprador debe entender.
El lock-in no necesita una cláusula de exclusividad. Aparece cuando las reglas del proceso, las evaluaciones, las trazas y las integraciones se expresan mediante componentes específicos de un proveedor. Cambiar de modelo exige entonces reconstruir parte de la operación, aunque la llamada original fuera una API.
Arkatai separa ambas capas. Tratamos los modelos como utility y los evaluamos por tarea según calidad, coste, latencia y riesgo. Si cambia ese balance, sustituimos el modelo y repetimos las evaluaciones; el proceso, sus reglas, controles y trazas permanecen. El FDE trabaja para el resultado de la operación, no para la adopción de un catálogo.
Custom describe el despliegue, no la propiedad
De que la capa operativa sea custom no se deduce que cada cliente deba financiar una base de código y mantenerla. Se deduce que alguien tiene que trabajar con la operación concreta antes de poner agentes en producción. La pregunta es quién asume ese trabajo y quién se queda con el ciclo técnico posterior.
En Arkatai, un forward-deployed engineer trabaja con las personas que conocen el proceso, conecta los sistemas y codifica reglas, controles y excepciones. La firma conserva el software y se responsabiliza de modelos, agentes, evaluaciones, observabilidad e integraciones. El cliente necesita un responsable del proceso con autoridad para decidir; no necesita montar un departamento de IA.
El cliente contrata una capacidad operativa
En una licencia, el proveedor responde por la disponibilidad de la herramienta y el cliente por el trabajo que se hace con ella. En service as software, la unidad de valor se desplaza hacia el proceso: casos completados, tiempos, calidad, errores y excepciones. El software permanece en segundo plano porque no es lo que el cliente necesita operar.
La adaptación sigue siendo parte del servicio. El FDE incorpora nuevas reglas, integraciones y controles al sistema común mientras el equipo de Arkatai mantiene la arquitectura técnica. El cliente no compra licencias, repositorios ni una plantilla técnica: contrata una operación y conserva la autoridad sobre sus decisiones de negocio.
La salida se diseña al entrar
Mapear produce una arquitectura operativa específica: proceso, reglas, excepciones, controles, contratos de datos, especificaciones de integración y criterios de evaluación. Ese contenido pertenece al cliente. Describe qué debe hacer una implementación sin transferir la plataforma, el código ni los componentes comunes de Arkatai.
Al finalizar el contrato, el cliente recibe esa arquitectura actualizada y la exportación acordada de sus datos, resultados y trazas. Puede entregarla a otro implementador o usarla para construir software propio. La salida no hace gratuita una nueva implementación; evita pagar otra vez por descubrir y decidir cómo funciona la operación.
Cómo se evita convertirlo en consultoría por horas
Cada despliegue produce dos tipos de conocimiento. Las reglas, los datos y las decisiones del cliente permanecen aislados. Los patrones que se repiten —conectores, evaluaciones, controles, rutas de escalado— mejoran el núcleo de Arkatai. El FDE no crea una solución paralela que luego hay que mantener; lleva el caso real al sistema común.
Arkatai opera ese último eslabón. Nosotros ponemos y mantenemos el workforce; el cliente dirige su proceso y mide el resultado. El modelo está detallado en Arkatai, la práctica se desarrolla en los ensayos y una operación concreta se puede plantear en Trabajemos.