Agents as a Service
Construir agentes en la nube:
Podemos crear un agente listo para producción definiendo la tarea, el modelo, las herramientas y el entorno.
Podemos crear un agente listo para producción definiendo la tarea, el modelo, las herramientas y el entorno.
Una empresa rara vez necesita inteligencia artificial en abstracto.
Necesita que alguien revise documentación, investigue oportunidades, controle pagos, siga expedientes, compare información entre distintos sistemas, detecte anomalías, prepare informes o supervise un proceso y actúe cuando determinadas condiciones se cumplen.
Durante décadas resolvimos esos problemas de dos maneras: asignando personas al trabajo o desarrollando software específicamente diseñado para automatizarlo.
Los agentes introducen una tercera posibilidad.
Construir un sistema capaz de recibir un objetivo, utilizar las herramientas de una organización, interpretar lo que ocurre durante el proceso y ejecutar las acciones necesarias para llegar a un resultado.
No un agente genérico.
Un agente diseñado alrededor de un trabajo concreto.
A eso nos referimos cuando hablamos de Agents as a Service.
De una respuesta a un proceso
Un modelo de lenguaje puede recibir información, interpretarla y generar una respuesta.
Un agente puede hacer algo diferente: utilizar ese modelo como parte de un proceso que continúa después de la primera respuesta.
Puede consultar un sistema y descubrir que falta información. Buscarla en otro. Leer un documento. Compararlo con antecedentes. Elegir una herramienta. Ejecutar una acción. Verificar qué ocurrió y decidir qué hacer después.
Su funcionamiento básico puede imaginarse como un ciclo:
OBJETIVO
↓
Interpretar la situación
↓
Decidir una acción
↓
Utilizar una herramienta
↓
Observar el resultado
↓
Actualizar el contexto
↓
Decidir nuevamenteOpenAI denomina precisamente agent loop a esta lógica que coordina la interacción entre el usuario, el modelo y las herramientas utilizadas durante una tarea.
Esto permite trabajar sobre problemas que no siempre pueden expresarse como una secuencia rígida de instrucciones.
Un proceso puede contener excepciones, documentos diferentes, información incompleta, decisiones contextuales o situaciones que exigen investigar antes de continuar.
Ahí empiezan a resultar particularmente interesantes los agentes.
El trabajo define al agente
Dos agentes pueden utilizar exactamente el mismo modelo y ser sistemas completamente diferentes.
Uno podría recibir como función revisar diariamente nuevas licitaciones, leer los pliegos, compararlos con las capacidades de una empresa y seleccionar aquellas que merecen ser analizadas.
Otro podría controlar cuentas corrientes, identificar obligaciones vencidas, buscar antecedentes y preparar las acciones correspondientes.
Un tercero podría analizar expedientes administrativos, detectar documentación faltante, consultar normativa y preparar el paso siguiente.
Lo que define a esos agentes no es que utilicen GPT, Claude, Grok u otro modelo.
Los define el trabajo para el cual fueron diseñados.
Esto cambia también la forma de pensar una implementación empresarial. La primera pregunta deja de ser qué modelo utilizar.
La pregunta pasa a ser:
¿Qué trabajo queremos que el agente pueda realizar?
Recién después tiene sentido discutir qué modelo, herramientas e infraestructura son apropiados.
El modelo no es el agente
GPT, Claude, Grok y otros modelos aportan una parte fundamental del sistema: la capacidad de interpretar información, razonar y decidir qué hacer a continuación.
Pero eso no alcanza para trabajar dentro de una organización.
Si una tarea dura una hora, utiliza veinte herramientas, consulta varios sistemas y necesita detenerse en algún momento para solicitar autorización, alguien tiene que mantener ese proceso funcionando.
Alguien tiene que recordar qué ocurrió.
Controlar qué herramientas están disponibles.
Mantener el estado de la tarea.
Administrar un error.
Conservar resultados intermedios.
Registrar las acciones realizadas.
Y determinar cuándo el agente puede continuar por sí mismo y cuándo necesita intervención humana.
Esa infraestructura es el Agent Harness.
Qué es un Agent Harness
Un harness no es otro modelo.
Tampoco es necesariamente una aplicación específica.
Es la infraestructura que rodea al modelo y organiza su trabajo.
OpenAI utiliza el término para describir la lógica que coordina el modelo, las herramientas y el contexto dentro de Codex. En su documentación reciente sobre Agents API, describe al harness como la capa encargada, entre otras cosas, de mantener agentes trabajando durante sesiones largas, utilizar herramientas de manera eficiente y coordinar subagentes.
Podemos pensarlo de una manera sencilla:
El modelo aporta capacidad de razonamiento. El harness organiza el trabajo.
Supongamos que a un agente se le asigna:
Revisar los nuevos reclamos recibidos durante el día, investigar cada caso y señalar aquellos que requieren atención prioritaria.
El modelo puede comprender perfectamente el pedido.
Pero alguien tiene que indicarle dónde están los reclamos, permitirle acceder a ellos, recordar cuáles ya revisó, darle acceso a los antecedentes del cliente y ofrecerle las herramientas necesarias para consultar documentación o crear una tarea.
Si durante el proceso aparece un caso particularmente sensible, además tiene que existir una regla que indique que el agente debe detenerse y escalarlo a una persona.
Todas esas piezas forman parte del sistema que rodea al modelo.
Del harness.
Mantener una tarea en el tiempo
Un agente puede ejecutar decenas o cientos de acciones antes de alcanzar un objetivo.
Durante ese recorrido necesita conservar el contexto suficiente para entender dónde se encuentra.
Quizás ya descartó determinados proveedores.
Quizás una documentación estaba incompleta.
Quizás una operación quedó esperando aprobación.
Quizás ya consultó una fuente y no tiene sentido volver a hacerlo.
El harness mantiene ese estado y permite que el trabajo continúe de manera coherente.
Esta capacidad se vuelve especialmente importante cuando las tareas duran minutos u horas, o cuando necesitan pausarse y retomarse posteriormente.
Anthropic, por ejemplo, describe sus Claude Managed Agents como un harness preconstruido para tareas de larga duración y trabajo asíncrono. Las sesiones conservan historial, estado y resultados, y pueden reanudarse después de una pausa.
Darle capacidades
Un agente también necesita herramientas.
Puede necesitar buscar un expediente, consultar una cuenta corriente, obtener el stock de un producto, analizar un archivo, ejecutar una consulta, utilizar un navegador o actualizar un registro.
Esas acciones pueden exponerse mediante APIs, funciones internas, conectores o protocolos como MCP —Model Context Protocol—.
El agente no necesita conocer cómo está construido cada sistema.
Necesita saber qué capacidades están disponibles y en qué condiciones puede utilizarlas.
El harness administra cómo esas herramientas forman parte del proceso.
Esta distinción es útil:
el modelo decide; el harness coordina; las herramientas actúan.
El agente también necesita un entorno
Algunas tareas pueden resolverse únicamente llamando APIs.
Otras requieren algo más parecido a un espacio de trabajo.
Un agente puede necesitar descargar archivos, procesar una planilla, generar documentos, ejecutar código, utilizar una terminal o navegar por una aplicación.
Por eso las plataformas modernas de agentes están incorporando entornos de ejecución persistentes o aislados.
OpenAI presentó el 10 de septiembre de 2026 la Agents API, actualmente en beta pública, que permite utilizar el harness desarrollado alrededor de Codex mediante API. OpenAI mantiene el harness, mientras que el desarrollador puede elegir si el entorno donde el agente trabaja está alojado por OpenAI, en infraestructura propia o en proveedores externos.
Anthropic adopta una separación similar. En Claude Managed Agents, el agente puede trabajar en un sandbox administrado por Anthropic o en un entorno alojado por el propio cliente. El servicio incluye herramientas para trabajar con archivos, ejecutar comandos, utilizar la web y conectarse con servidores MCP.
Grok Bot lleva la metáfora todavía más cerca de un puesto de trabajo digital: xAI describe cada Bot como un agente persistente con una máquina virtual propia en la nube, navegador, filesystem y terminal, capaz de utilizar aplicaciones y colaborar con otros bots.
No significa que todos los agentes empresariales necesiten una computadora completa.
Significa que la industria está empezando a separar claramente la inteligencia que decide qué hacer del entorno que le permite hacerlo.
La autonomía se diseña
Que un agente pueda realizar una acción no significa que deba estar autorizado a hacerlo.
Esta distinción es particularmente importante dentro de una empresa.
Un agente puede consultar una cuenta corriente pero no modificarla. Puede preparar una transferencia pero no ejecutarla. Puede redactar un escrito pero necesitar aprobación antes de presentarlo. Puede procesar automáticamente operaciones de bajo riesgo y derivar las excepciones.
Por eso la autonomía no debería pensarse como una característica binaria.
No existen solamente agentes “autónomos” y “no autónomos”.
Existe un conjunto de permisos y responsabilidades que puede diseñarse alrededor de cada proceso.
La pregunta relevante no es:
¿Puede el agente hacerlo?
Sino:
¿Bajo qué condiciones queremos permitir que lo haga?
Eso convierte identidad, permisos, aprobaciones, trazabilidad y auditoría en componentes centrales de cualquier implementación empresarial.
Agents as a Service
A medida que estas piezas empiezan a estar disponibles como infraestructura, aparece una nueva forma de construir soluciones.
Una empresa ya no necesita necesariamente desarrollar desde cero todo el sistema necesario para ejecutar un agente.
OpenAI puede proporcionar el harness en un proyecto.
Anthropic puede hacerlo en otro.
Determinados clientes pueden necesitar una infraestructura propia.
El proveedor puede cambiar.
El modelo puede cambiar.
Lo que permanece es el problema de la organización.
Y ahí aparece Agents as a Service.
No como una forma de revender acceso a un modelo.
Tampoco como una interfaz diferente para ChatGPT o Claude.
Agents as a Service consiste en diseñar, implementar y operar un agente alrededor de una función concreta de una organización.
El punto de partida es el trabajo.
Un agente a medida
No tiene por qué existir un catálogo cerrado.
Una organización puede necesitar un agente completamente diferente al de cualquier otra.
Una constructora podría querer un agente que reúna información de distintas obras, compare certificaciones con presupuestos y detecte desvíos que requieren atención.
Un estudio jurídico podría necesitar uno que siga determinados expedientes, investigue novedades, busque antecedentes y prepare material para su revisión.
Una industria podría utilizar un agente que analice producción, mantenimiento y stock e investigue automáticamente determinadas anomalías.
Un organismo público podría implementar uno que revise expedientes, verifique documentación y prepare actuaciones administrativas.
Una empresa comercial podría querer un agente que investigue prospectos antes de cada reunión y mantenga actualizado el CRM.
El patrón es el mismo.
El agente recibe una función.
La implementación se diseña alrededor de ella.
El agente empieza en la organización
Construir un agente de este tipo no comienza escribiendo un prompt.
Comienza entendiendo cómo se realiza realmente el trabajo.
Qué dispara el proceso.
Qué información se consulta.
Qué sistemas intervienen.
Qué decisiones se toman.
Qué excepciones existen.
Qué personas participan.
Qué operaciones tienen consecuencias.
Qué resultado se considera correcto.
Muchas veces esa investigación revela algo más interesante que la tecnología.
Una organización puede descubrir que un proceso aparentemente simple depende de tres sistemas, dos planillas, una carpeta compartida y conocimiento que únicamente posee la persona que lleva quince años realizando la tarea.
El agente obliga a hacer explícito ese conocimiento.
Y eso conecta esta arquitectura con problemas más antiguos y fundamentales: interoperabilidad, gobierno de datos, integración, identidad y ontología.
Para que una inteligencia pueda operar dentro de una organización, primero tiene que existir una representación suficientemente clara de cómo funciona esa organización.
La infraestructura puede cambiar
Esta separación también evita quedar atados a un proveedor.
Hoy un agente puede funcionar mejor utilizando OpenAI.
Otro puede beneficiarse de Claude.
Otro puede requerir un modelo diferente.
Y determinadas organizaciones pueden necesitar modelos ejecutados dentro de su propia infraestructura.
Si el agente está correctamente diseñado, esos componentes pueden evolucionar sin obligar a reconstruir todo el proceso.
Eso es especialmente importante en un mercado donde los modelos cambian mucho más rápido que las empresas.
Los procesos pueden existir durante décadas.
Los sistemas empresariales también.
El modelo utilizado debajo probablemente cambie varias veces.
Por eso el verdadero activo no debería estar exclusivamente en el modelo.
Está en la capa que representa el conocimiento, las capacidades, los permisos y los procesos de la organización.
Operar el agente es parte del producto
Construir un agente no termina cuando entra en producción.
Los procesos cambian.
Las aplicaciones cambian.
Las políticas cambian.
Las herramientas pueden fallar.
Los modelos evolucionan.
Por eso Agents as a Service implica también mantener y operar el sistema.
Observar qué hace.
Medir sus resultados.
Detectar errores.
Actualizar sus capacidades.
Revisar sus permisos.
Modificar reglas.
Incorporar nuevas fuentes.
Y decidir cuándo puede asumir mayor autonomía.
El agente no es una configuración que se realiza una vez.
Es un sistema operativo que debe evolucionar junto con el proceso que representa.
Una nueva forma de desarrollar software a medida
Anteriormente, cuando una organización necesitaba resolver un problema específico, podía recurrir al desarrollo de software a medida.
Describía el problema.
Se analizaba el proceso.
Y el resultado terminaba siendo una aplicación.
Los agentes introducen otra posibilidad.
Una organización puede llegar diciendo:
Necesitamos que alguien haga esto.
Y la respuesta no necesariamente tiene que ser una nueva aplicación con veinte pantallas.
Puede ser un agente que utilice las aplicaciones que ya existen.
Ese cambio parece sutil, pero modifica profundamente la forma de pensar el software empresarial.
La aplicación deja de ser necesariamente la unidad central.
La unidad puede empezar a ser el trabajo.
Agents as a Service en Atlas Analytica
En Atlas Analytica entendemos Agents as a Service desde esa perspectiva.
No como un catálogo cerrado de asistentes.
Ni como la reventa de modelos de inteligencia artificial.
El punto de partida es una función concreta de la organización.
Entender qué trabajo necesita realizarse, qué información requiere, qué herramientas intervienen, qué reglas deben respetarse y qué grado de autonomía tiene sentido.
A partir de ahí puede diseñarse un agente a medida y seleccionar la infraestructura apropiada para ejecutarlo.
En algunos casos podrá apoyarse sobre OpenAI.
El cliente no necesita comprar un modelo.
Necesita resolver un trabajo.