Red Hat publica un quickstart de diez agentes para leer contratos de leasing aereo
NeIO LeasingOps encadena diez agentes sobre LangGraph, vLLM y OpenShift para dar una primera pasada a contratos de leasing de aeronaves de cientos de paginas.
Red Hat ha sumado a su catalogo de AI quickstarts un caso de uso listo para desplegar: NeIO LeasingOps, un sistema de diez agentes encadenados que da una primera pasada sobre contratos de leasing de aeronaves y devuelve resultados estructurados. Lo ha construido Codvo.ai y el codigo esta publicado en el repositorio de rh-ai-quickstart. Lo interesante no es un modelo nuevo, sino la arquitectura de referencia: que agentes hacen falta, en que orden van y sobre que piezas de infraestructura se ejecutan.
Un contrato de leasing aereo son cientos de paginas con calendarios de pago variables, reservas de mantenimiento calculadas por horas de vuelo y ciclos, condiciones de devolucion con especificaciones tecnicas exactas, obligaciones repartidas entre arrendador, arrendatario y proveedores MRO, requisitos de la FAA, EASA e IATA, y enmiendas que retocan las condiciones base. Hoy eso lo lee un equipo de especialistas a mano y lo contrasta con datos operativos. Funciona, pero no escala y ata a gente cara a una tarea repetitiva.
Diez pasos, diez agentes
El pipeline va de la subida del documento a la recomendacion final. Los agentes estan hechos con LangGraph; un worker en segundo plano saca trabajos de una cola de Redis y avanza cada documento por la cadena mientras escribe resultados en PostgreSQL.
El primer agente valida y clasifica el contrato (operating lease, finance lease, wet lease, dry lease, reclamacion de reserva, enmienda) y lo enruta. El extractor saca fechas, importes, identificadores de activo como el numero de cola y el MSN, partes y clausulas especiales usando reconocimiento de entidades y prompts dirigidos. El mapeador de obligaciones las archiva por categoria con responsable y vencimiento. El reconciliador compara horas y ciclos contratados contra datos reales de MRO, y eso alimenta la calculadora de reservas, que lee las clausulas financieras con el modelo pero hace la aritmetica de forma determinista. Ese detalle importa: los numeros no dependen del LLM. Despues vienen el detector de desviaciones, el analizador de condiciones de devolucion con su lista de tareas para la redelivery, el paquete de evidencias que liga cada hallazgo a la clausula de la que sale, y el soporte a la decision con un analisis de devolver, extender o comprar. El ultimo paso es el escalado, el punto de control humano: lo que necesita una persona llega con la traza de evidencias detras.
Que hay debajo
Es una aplicacion cloud native sobre Red Hat OpenShift. Frontend en Next.js 15 para subir documentos y ver resultados, API en FastAPI para ingesta, CRUD de contratos y REST, un worker en Python, PostgreSQL y Redis. La inferencia la sirve vLLM con IBM Granite 3.3 2B, un modelo Apache 2.0 que no pide token de Hugging Face, y LlamaStack actua como pasarela compatible con la API de OpenAI por delante. El parseo de documentos lo hace Docling cuando el servicio esta disponible y cae a PyMuPDF cuando no.
Todo corre con la misma configuracion en CPU o en GPU, y se cambia por valores: CPU para ahorrar coste, GPU para rendimiento. vLLM, LlamaStack y Granite se despliegan por separado desde los charts de Red Hat AI; la aplicacion, junto con PostgreSQL y Redis, va en un unico Helm chart y un unico namespace, con la opcion de apuntar a instancias externas en lugar de a las que trae el chart.
La cifra que da Red Hat es que analisis que ocupaban dias a un analista bajan a minutos en GPU, algo mas en CPU. Es suya, no de un tercero, y no viene acompanada de ningun benchmark publico. Lo que si se puede comprobar hoy es el quickstart documentado: si alguien esta montando un pipeline de agentes sobre documentos largos, aqui tiene un patron completo, con separacion entre lo que decide el modelo y lo que calcula el codigo, que es la parte reutilizable mas alla del leasing.
