Un análisis a fondo del sistema APEXiA — un stack de compound AI (IA compuesta) de grado productivo que orquesta múltiples modelos de IA, pipelines de datos y lógica de negocio para operar una plataforma integral de analítica, pronósticos y CRM para manufactura. Sin necesidad de científicos de datos.
Los sistemas de compound AI (IA compuesta) son arquitecturas que combinan múltiples componentes de IA — modelos, herramientas, capas de orquestación y pipelines de datos — en un conjunto coordinado que logra más de lo que cualquier modelo individual podría.
El término fue popularizado por Andrew Ng y otros en 2024–2025 como la frontera de la ingeniería práctica de IA. La idea es simple pero profunda: ningún LLM individual es bueno en todo. Un sistema que encadena modelos especializados — un clasificador aquí, un generador de SQL allá, un pronosticador en otro lado — coordinados mediante lógica determinista y ciclos de autocorrección, superará a cualquier prompt monolítico en confiabilidad, precisión y costo.
Principio clave: En un sistema de compound AI, el valor no viene de los componentes individuales sino de su composición. La arquitectura — cómo interactúan los componentes, cómo se detectan y corrigen los errores, cómo fluyen los datos entre ellos — es el verdadero producto.
Características típicas de los sistemas compuestos:
Antes de las arquitecturas compuestas, el enfoque estándar para construir aplicaciones impulsadas por IA era monolítico: escribir un único system prompt elaborado y esperar que el LLM tenga suficiente contexto, suficiente capacidad de razonamiento y suficiente disciplina de formato para hacerlo todo — clasificar, recuperar datos, generar SQL, analizar resultados y explicar hallazgos — en una sola llamada.
Este enfoque tiene limitaciones fundamentales:
| Prompt monolítico | La realidad |
|---|---|
| Todo en un solo system prompt | El prompt se infla más allá de la ventana de contexto efectiva del modelo; el desempeño se degrada de forma no lineal pasados ~5k-8k tokens de instrucciones |
| Un solo modelo hace clasificación + generación + análisis | Los LLMs son mediocres tanto en clasificación estructurada (baja confianza) como en generación de SQL complejo (columnas/joins alucinados); los prompts/modelos especializados funcionan mejor |
| Sin autocorrección | Si el SQL está mal, todo el pipeline falla — no hay mecanismo de reintento incorporado en la arquitectura |
| Sin especialización de modelos | Claude es excelente en SQL pero lento/caro para clasificación; Qwen es rápido para clasificación pero menos confiable en consultas complejas. Usar un solo modelo para ambas cosas desperdicia dinero y desempeño |
| Comportamiento de caja negra | Si los resultados están mal, no puedes saber si la falla estuvo en la comprensión de la intención, la generación del SQL, la calidad de los datos o la explicación |
La alternativa compuesta: Separar las responsabilidades a nivel arquitectónico. Enrutar cada sub-tarea al modelo más adecuado para ella. Incorporar detección determinista de errores en el pipeline. Hacer de la arquitectura un artefacto de diseño de primera clase, no una ocurrencia tardía.
APEXiA no es un experimento ni un prototipo. Es un sistema de compound AI de grado productivo construido para una fábrica de materiales de construcción en República Dominicana — y diseñado desde el primer día para ser una plantilla de despliegue multi-tenant (multi-inquilino) en docenas de otras PYMEs.
El sistema maneja operaciones reales del negocio: seguimiento de inventario, analítica de ventas, cuentas por cobrar/pagar, pronóstico de demanda, predicción de churn (fuga de clientes) y captura de pedidos vía WhatsApp. Corre por completo en un solo equipo con dos GPUs AMD Radeon AI PRO R9700, sirviendo un modelo Qwen3.6-35B-A3B de forma local mediante vLLM.
Pero más importante que esos números es cómo encajan las piezas. Abajo descomponemos la arquitectura completa capa por capa, y luego hacemos zoom en los mecanismos de inteligencia y orquestación que hacen que todo funcione.
Todo sistema de compound AI es tan bueno como su capa de datos. La fundación de APEXiA es un pipeline ETL cuidadosamente construido que replica una base de datos Oracle heredada (del cliente) en una instancia moderna de PostgreSQL.
Las operaciones del negocio — pedidos, inventario, pagos — se gestionan en una base de datos Oracle del cliente. Esta es una réplica fiel y de solo lectura. El sistema APEXiA nunca modifica los datos crudos del ERP. Todas las transformaciones ocurren en la capa de vistas (Capa 1).
Regla dura incorporada en el sistema: Las tablas crudas (en esquemas como cxc.*, fat.*, inv.*, cnt.*) son réplicas fieles del ERP. Jamás se les aplica UPDATE, INSERT, DELETE ni ALTER. Todas las transformaciones viven en la capa ia.* (canónica) o bi.* (vistas materializadas). El refresco TRUNCATE+INSERT del ETL es la única mutación legítima de tablas crudas.
Todo el stack corre sobre una sola instancia de PostgreSQL (contenedor Docker de Postgres). Cada tenant recibe su propia base de datos, rol y usuario de solo lectura. Este es el patrón tenant_NNNN — una numeración con privacidad por diseño que evita que los tenants se enumeren entre sí a través de los catálogos de sistema de Postgres.
El ETL corre en un entorno Python separado (etl_env/venv) usando scripts que se conectan tanto a la fuente Oracle como al destino PostgreSQL. El orquestador canónico de migraciones es promote_to_production.py, que maneja la detección de drift (deriva) de esquema y las adiciones incrementales de columnas del ERP.
Los datos reales de un ERP nunca están perfectamente completos — algunos canales de venta viven fuera del sistema principal. La capa compuesta lo asume con honestidad: no finge completitud, y la analítica aguas abajo está consciente de cualquier brecha de cobertura. Esa conciencia es una característica, no un defecto — moldea cómo la IA matiza sus respuestas.
La Capa 1 se ubica entre las réplicas crudas del ERP y las interfaces de IA. Es la capa de abstracción canónica — el esquema ia.* — la que hace posible escalar a múltiples tenants.
En un sistema multi-tenant, el ERP de origen de cada tenant luce distinto. el ERP actual tiene sus propios nombres de columnas, estructuras de tablas y convenciones de negocio. Los tenants futuros pueden usar ERPs completamente diferentes. La Capa 1 existe para que la capa de IA nunca sepa qué ERP usa un tenant. Siempre conversa con ia.v_ventas_detalle, ia.v_inventario_diario, etc. — columnas y semántica que lucen igual sin importar lo que haya debajo.
Transacciones de venta con producto, cliente, fecha, margen
Niveles diarios de inventario por SKU en todos los almacenes
Cuentas por cobrar — balances de clientes y antigüedad
Cuentas por pagar — obligaciones con proveedores y antigüedad
Gastos operativos resumidos por categoría y período
Pronóstico de demanda de iAx Científico (XGBoost/Prophet)
Predicciones de churn con niveles de severidad y explicaciones
Estas vistas son 17+ en total, y cada una mapea conceptos de negocio (ventas, inventario, cuentas por cobrar) a una forma de columnas consistente. Los ejemplos few-shot del chatbot, los docstrings de esquema y los prompts de SQL asumen que ia.* es portable entre tenants — solo el ETL debajo absorbe las particularidades de cada fuente.
Principio de diseño multi-tenant: Al agregar una columna o la forma de una vista, pregúntate: «¿Los datos de otro tenant tendrían esta columna con el mismo nombre?» Si no, empuja la divergencia al ETL, no a la capa ia.*. Esto mantiene genérica la capa de IA sin necesitar enrutamiento específico por tenant.
Si la Capa 1 es el «idioma» que comparten el negocio y la IA, la Capa 2 es el motor de inteligencia predictiva. Este es iAx Científico — el sistema de AutoML (aprendizaje automático automatizado) que mejora continuamente los modelos de pronóstico y churn usando datos reales.
El modelo de demanda usa dos algoritmos en tándem:
Ambos están envueltos en una función PL/Python (train_demand_model) que corre dentro de Postgres. El modelo se entrena en cada corrida programada, produciendo predicciones que aterrizan en la vista v_pronostico_demanda — quedando automáticamente disponibles para el chatbot de la Capa 3.
Corrección de bug que resultó crítica: Un bug de n_jobs desbocado en XGBoost (que por defecto usa todos los núcleos del CPU) hacía que el modelo se colgara 63 minutos por corrida, saturando más de 30 núcleos. La corrección — agregar 'n_jobs': 1 — llevó el entrenamiento de 63 minutos a 17 segundos. Es un ejemplo perfecto de por qué el compound AI necesita integración profunda entre componentes: el pipeline de datos (Postgres), la librería de ML (XGBoost) y el modelo en GPU (Qwen) interactúan a través de infraestructura compartida que debe calibrarse con cuidado.
El modelo de churn pasó por una re-arquitectura fundamental. La versión original predecía churn usando un objetivo que era circular respecto a la recencia — usaba variables observadas hasta el punto de corte, pero el objetivo en sí (si un cliente se fuga) se definía con comportamiento posterior al corte, creando fuga de información (leakage).
La corrección lo replanteó como un indicador adelantado: predecir quién entra en dormancia en los próximos 90 días usando solo variables observadas antes de un corte temporal. El resultado:
El GBM adelantado es un HistGradientBoostingClassifier que ingiere ventanas de actividad/RFM, tendencias de declive, amplitud de productos/HHI, margen y estacionalidad. Se niega a publicarse si no puede superar la línea base de solo recencia, y produce explicaciones por cliente en español (español de vendedor, la audiencia objetivo). El modelo detectó desertores no obvios — clientes con 137 días de silencio sobre una cadencia de 195 días — que una regla simple de recencia habría pasado por alto.
Aquí es donde APEXiA se vuelve genuinamente compuesto. El sistema de AutoML de iAx Científico no solo entrena modelos — propone variables nuevas de forma autónoma.
El LLM Qwen (vía el mismo endpoint de vLLM) propone variables nuevas en un DSL restringido: agregados por ventana, razones y deltas sobre monto/n_prod/margen. Cada propuesta incluye una descripción en español y una justificación.
Cada variable propuesta se evalúa sobre una partición fuera-de-tiempo (out-of-time). Una compuerta de umbral (mejora de AUC ≥ +0.002) determina si pasa. Esto evita la circularidad: las variables que solo memorizan la ventana de entrenamiento se rechazan.
Ambos niveles operan de extremo a extremo. Qwen y Claude proponen 5 variables cada uno por corrida. En una corrida validada, todas fueron rechazadas (la más cercana: +0.00193, justo por debajo del listón). El registro rastrea la procedencia — quién propuso qué, cuándo, y el resultado de la evaluación.
Las variables que fallan consistentemente la evaluación se auto-deshabilitan (enabled=FALSE). El sistema limpia su propio feature registry (registro de variables), conservando solo las útiles. Es un ciclo de retroalimentación que compone mejoras con el tiempo.
Idea clave: El proponente de variables no está simplemente «generando ideas al azar». Opera dentro de un DSL restringido y a prueba de leakage. Las variables propuestas deben seguir reglas estrictas (agregados por ventana sobre ventanas previas al corte, evaluados solo sobre esa ventana). Esto es inteligencia compuesta: el LLM propone, el evaluador determinista valida, la base de datos registra.
Un diseño fascinante: el sistema de churn funciona a la vez como señal de compras para la cadena de suministro. Algunos artículos terminados se fabrican solo porque un cliente específico los pide (demanda hecha a pedido). Cuando ese cliente se ausenta, se deja de comprar la materia prima. El modelo de resurrección predice cuáles clientes ausentes se reactivan y cuándo, habilitando la planificación de compras con conciencia del tiempo de entrega.
El detector identifica los artículos hechos a pedido ordenando las predicciones de demanda por el WMAPE por producto (Weighted Mean Absolute Percentage Error, error porcentual absoluto medio ponderado). Los productos con peor pronóstico son exactamente los artículos de cliente único:
Esto es compound AI en su mejor expresión: la interacción entre el sistema de pronóstico de demanda, el sistema de predicción de churn y la señal de compras crea una capacidad de negocio que ninguno de los componentes individuales podría proveer por sí solo.
La Capa 3 es la superficie de cara al usuario. Tiene dos componentes que juntos cubren todas las necesidades analíticas y operativas del negocio.
El producto insignia. Los usuarios (vendedores, el dueño de la fábrica, contadores) hacen preguntas en español sobre el negocio. El sistema las traduce a SQL contra las vistas ia.*, lo ejecuta y devuelve un análisis en lenguaje natural en español.
«¿Cuánto vendimos en mayo vs. abril?» o «¿Qué productos tienen inventario bajo?»
Emite INTENT:DOMAIN|CONFIDENCE|ALTERNATES — p. ej. INTENT:VENTAS|HIGH (dominio único). El clasificador es en sí una solicitud a Qwen; vLLM cachea por prefijo cada system prompt distinto, haciendo muy rápida la clasificación repetida.
CONFIDENCE=HIGH + dominio único → ruta rápida (esquema acotado a un solo dominio, SQL en un solo intento). De lo contrario → ruta híbrida (esquema unión del primario + alternos, con reintento de autocorrección ante falla de SQL).
Una solicitud a Qwen con el docstring del esquema acotado y ejemplos few-shot. Temperatura fijada en 0.1 para determinismo. El SQL se limpia (se eliminan etiquetas de razonamiento y cercas de markdown, y se ancla al último SELECT).
El SQL corre contra tenant_0001 con search_path = ia, public. La validación de solo lectura usa un rol de base de datos; las escrituras usan un rol con permisos de escritura.
Los resultados vuelven a Qwen para un resumen en lenguaje natural en español. La temperatura usa el 1.0 configurado para un tono conversacional. Resultados + interpretación se devuelven al usuario.
| Característica | Estándar (Qwen) | Premium (Claude) |
|---|---|---|
| Modelo | Qwen3.6-35B-A3B MoE (local) | Claude Sonnet (API de Anthropic) |
| Arquitectura | Anchor Engine 2.0 (pipeline de 5 pasos: clasificar → enrutar → SQL → ejecutar → interpretar) | Autónomo — Claude recibe el esquema completo + la herramienta execute_sql, y lo hace todo de una vez |
| Costo | $0 (GPU local) | $0.018/mensaje (est.) |
| Velocidad | ~100 tok/s en una sola GPU | Variable, depende del API |
| Autocorrección | Sí — la ruta híbrida tiene reintento de autocorrección ante falla de SQL | Inherente — Claude puede reintentar por sí mismo |
Un sistema complementario que sirve a los vendedores. Los vendedores envían pedidos por WhatsApp. El CRM los interpreta, gestiona tarjetas de vendedor, genera PDFs de estado de cuenta y empuja los pedidos al sistema ERP. Esto es compuesto de otra manera: combina extracción de intención impulsada por LLM desde mensajes de WhatsApp con procesamiento determinista de pedidos y generación de PDF.
Qwen interpreta los mensajes de WhatsApp para extraer códigos de producto, cantidades y fechas de entrega. Sigue una validación determinista para asegurar que todos los campos requeridos estén presentes.
Cada vendedor recibe una tarjeta que muestra su pipeline, pedidos recientes y balance de cuenta. Los clientes pueden solicitar un «estado de cuenta» — un estado en PDF — que se genera bajo demanda y se entrega de vuelta por WhatsApp.
Los pedidos validados se empujan al ERP (Oracle) mediante una conexión dedicada. El empuje incluye los campos FECHAENTREGA, IMPUESTO (18% de ITBIS) y TASADECAMBIO, dejando el pedido plenamente operativo en el sistema heredado.
El Anchor Engine es el núcleo de enrutamiento del sistema iAx Analista — la pieza que hace que la arquitectura compuesta funcione en la práctica. Sin él, el sistema sería solo un constructor sofisticado de consultas SQL. Con él, el sistema tiene enrutamiento consciente de la confianza y autocorrección ante fallas.
Opera sobre tres señales del clasificador:
ia.* inyectar en el prompt de SQLLas seis intenciones (CHAT, DATA, ANALYSIS, DATA+ANALYSIS, FOLLOWUP, FOLLOWUP+DATA) determinan además si se carga contexto adicional de seguimiento desde un caché de sesión (TTL de 30 min, máximo 200 sesiones, buffer circular de 3 entradas de resultados para secuencias multi-turno).
Por qué esto es inteligencia compuesta: El clasificador no devuelve solo una etiqueta — devuelve una respuesta estructurada que dirige una bifurcación determinista en el orquestador. Ese orquestador luego arma un prompt acotado, lo envía de vuelta al mismo modelo (Qwen), y si la ejecución falla, reintenta automáticamente con un esquema corregido. Es un ciclo de retroalimentación dentro de una sola llamada al API. Ningún prompt monolítico hace esto.
Las fallas de generación de SQL se detectan al momento de la ejecución. Cuando una consulta falla (columna no encontrada, tabla no encontrada, tipos incompatibles), la ruta híbrida dispara un reintento de autocorrección:
Postgres devuelve un error (p. ej. «column porc_margen does not exist»).
El sistema tiene un registro _BLOCKED_COLUMNS (~5 patrones principales de alucinación) que mapea alucinaciones comunes del LLM: margen_pct → porc_margen, monto_neto → monto_neto_rd, etc.
La consulta corregida se ejecuta. Si tiene éxito, el flujo continúa hacia la interpretación. Si falla de nuevo, la ruta cae a la ruta híbrida con esquema ampliado.
Esta cadena de manejo de errores — interpretar, mapear, reintentar — es código determinista, no un truco de prompt. Eso es lo que hace confiable al compound AI: los modos de falla están entendidos, mapeados y manejados programáticamente.
Una de las características que definen a un verdadero sistema de compound AI es usar el modelo correcto para cada sub-tarea. APEXiA demuestra este principio con cuatro modelos de IA distintos, cada uno en su rol óptimo:
| Modelo | Rol | Por qué este modelo |
|---|---|---|
| Qwen3.6-35B-A3B (MoE, 3B activos / 35B totales) | Clasificación, generación de SQL, interpretación en lenguaje natural | Corre localmente en GPUs AMD Radeon R9700 vía vLLM. Rápido (~100 tok/s), barato ($0 de inferencia), gran ventana de contexto de 262k. La arquitectura MoE lo hace lo bastante eficiente para uso en tiempo real. |
| Claude Sonnet | Alternativa del nivel Premium — SQL + análisis autónomos | Generación de SQL superior en consultas complejas. Usa el API de Anthropic ($0.018/msj). Actúa como respaldo para usuarios que necesitan precisión de grado premium. |
| HistGradientBoosting (scikit-learn) | Predicción de churn, regresión de demanda | Especialistas en datos tabulares — muy superiores a cualquier LLM en regresión/clasificación estructurada. Entrenados sobre datos de panel de las vistas ia.*. |
| Prophet | Pronóstico de demanda estacional | Especialista en series de tiempo para tendencia + estacionalidad de feriados. Predicción de horizonte en bloque (predice toda la ventana futura en una sola llamada). Usado en tándem con XGBoost para ventaja de ensamble. |
Por qué 4 modelos en lugar de 1: Un solo LLM no puede ser a la vez el mejor clasificador, generador de SQL, pronosticador y predictor de churn. Cada sub-tarea se beneficia de un modelo especializado en ella. La orquestación — decidir qué modelo maneja qué parte del pipeline — es la inteligencia compuesta en sí misma.
La diversidad de modelos se extiende también a la capa de AutoML: el proponente de variables usa Qwen (Estándar) y Claude/Opus (Premium), evaluando las propuestas contra modelos XGBoost y Prophet entrenados con datos reales de producción. Es un ciclo de meta-aprendizaje: el LLM propone variables, los modelos de ML las evalúan, y los resultados de la evaluación informan las propuestas futuras.
Quizás el aspecto más sofisticado de la arquitectura compuesta de APEXiA es la capacidad del sistema de AutoML de mejorarse a sí mismo de forma autónoma. El ciclo de ingeniería de variables no solo entrena un modelo — mantiene un feature registry vivo (registro de variables) que crece, se poda y evoluciona a medida que llegan datos nuevos.
Cada variable propuesta se registra en cientifico.demand_feature_registry con:
Cuando una variable falla consistentemente la evaluación (por debajo del umbral de mejora de AUC), el sistema fija automáticamente enabled=FALSE. Esto significa:
El sistema también rastrea qué variables dependen de fuentes de datos exógenas (weather_BCRD) que aún no han sido conectadas. Estas quedan en cola para re-proponerse cuando esas fuentes de datos estén disponibles. Es una cola de espera de ideas que el sistema guarda y retoma cuando se cumple la precondición.
El AutoML auto-reparable es el multiplicador «compuesto»: Cada corrida de AutoML mejora el conjunto de variables, lo que mejora el modelo, lo que produce mejores pronósticos de demanda y predicciones de churn, que alimentan las vistas ia.*, que el chatbot usa para dar mejores respuestas. El sistema compone mejoras con el tiempo — este es el significado literal de «compound AI».
La observabilidad es crítica en los sistemas de compound AI porque las fallas pueden originarse en cualquier componente. APEXiA incorpora monitoreo en múltiples niveles:
| Capa de monitoreo | Mecanismo |
|---|---|
| Salud del API | Endpoint /health que devuelve versión, backends activos, alcanzabilidad del clasificador y conteo de sesiones |
| Suite de pruebas | ~130 pruebas en 11 suites (inventory, financial, mixed, multi, followup, forecast, churn, yoy, etc.). Compuerta de regresión post-publicación. |
| Benchmarks del clasificador | bench_classifier_v2.py — se exige exactitud ≥95% de formato + ≥95% de precisión en HIGH en producción |
| Benchmark de throughput | apexia_benchmark.sh — barrido de tok/s por usuario y agregado a varios niveles de concurrencia, con parámetros de tamaño de prompt |
| Salud del AutoML | Captura de NOTICE de un fallo en el paso de evaluación (reversión automática de la corrida, variable auto-deshabilitada), chequeos de auto-reparación, vigilante de grano (count(distinct entity_key) == count(*)) |
| Salud del ETL | Funciones detect_stuck_runs() y cleanup_stuck_runs() en Postgres, vigilante de ejecuciones de n8n |
Nótese que no hay dashboards tradicionales para el monitoreo del API. La salud se verifica programáticamente mediante la ejecución de scripts. Esto es consistente con la filosofía del compound AI: la observabilidad debe ser automatizada, accionable e integrada en el pipeline, no algo que un ingeniero tenga que mirar activamente.
Principio clave: automatizar el ciclo de observabilidad. Cuando una prueba falla, se actualiza el BUGFIX_QUEUE.md. Cuando una corrida de AutoML se estanca, el vigilante lo detecta. Cuando el clasificador se degrada, el benchmarking lo señala. El sistema se monitorea a sí mismo.
APEXiA fue diseñado desde el inicio para servir a múltiples tenants — empresas distintas, cada una con sus propios datos, ERP y lógica de negocio. La arquitectura compuesta hace que la multi-tenencia sea limpia:
Como el esquema ia.* es portable, incorporar un tenant nuevo es solo un problema de ETL — la arquitectura compound AI en sí no necesita cambiar. Esto es lo que hace al sistema genuinamente escalable.
Así se compara APEXiA (compuesto) con un sistema monolítico que intente hacer lo mismo en una sola llamada al LLM:
| Propiedad | Enfoque monolítico | APEXiA (compuesto) |
|---|---|---|
| Arquitectura | Un system prompt gigante (~10k+ tokens) | Modular: clasificador → enrutador → generación de SQL → ejecutar → interpretar (5 etapas explícitas) |
| Manejo de errores | Reintentar con el mismo prompt — el mismo modo de falla | Autocorrección determinista: interpretar el error → mapear la corrección → reintentar con el esquema corregido |
| Modelo utilizado | Un modelo para todo — mediocre en todas las tareas | Qwen para clasificación/SQL, Claude para premium, XGBoost para tabular, Prophet para series de tiempo |
| Pronósticos | El LLM intenta predecir números en un prompt — poco confiable | Pipeline de ML dedicado (XGBoost + Prophet), variables propuestas por AutoML, compuertas de evaluación |
| Predicción de churn | El LLM analiza interacciones pasadas — circular, con leakage | GBM adelantado con corte temporal, validación fuera-de-tiempo, explicaciones por cliente |
| Multi-tenant | Ajustes de prompt específicos por tenant o prompts gigantes separados | Esquema ia.* portable, el ETL absorbe las diferencias de fuente, cero cambios en la capa de IA |
| Auto-mejora | Hacer prompt-engineering manual de mejores ejemplos few-shot | El AutoML propone variables, las evalúa, auto-deshabilita las fallidas y mantiene el registro |
| Observabilidad | Esperar que el LLM haya formateado bien | 130+ pruebas, benchmarks del clasificador, benchmarks de throughput, vigilantes de corridas estancadas |
| Costo | Alto — un modelo caro haciéndolo todo | $0 de inferencia (Qwen local), Claude Premium opcional para casos límite (~$0.018/msj) |
| Confiabilidad en el tiempo | Deriva — los ejemplos few-shot se pudren, las capacidades del modelo cambian | AutoML componiendo variables, snapshots de vistas, compuerta de pruebas CI/CD antes de publicar |
La diferencia no es solo técnica — es filosófica. Un enfoque monolítico trata al LLM como un solucionador universal de problemas. Un enfoque compuesto trata al LLM como un componente entre muchos, optimizando la confiabilidad, el costo y la corrección del sistema completo.
Las decisiones de diseño de APEXiA reflejan una filosofía clara que da forma a su arquitectura compuesta:
El stack por defecto es completamente open source: el modelo Qwen (local), vLLM (servidor de inferencia), PostgreSQL (base de datos), n8n (orquestación), Scikit-learn/XGBoost/Prophet (librerías de ML). Los APIs de pago (Claude de Anthropic) son un borde removible — usados solo cuando el stack local genuinamente no puede con la tarea. Esto mantiene los costos cerca de cero y evita el encierro con proveedores (vendor lock-in).
Toda la inferencia corre localmente en el hardware propio del operador: dos GPUs AMD Radeon AI PRO R9700 sirviendo con ROCm/vLLM. El modelo es Qwen3.6-35B-A3B-MXFP4 (MoE cuantizado a 4 bits), corriendo TP2 entre ambas tarjetas con decodificación especulativa MTP (≈75 → ≈100 tok/s, aceleración de 2.2×). Esto significa:
Esta inversión — el modelo local como predeterminado, el API costoso como opción — es lo opuesto a la mayoría de las startups de IA. Refleja una comprensión pragmática: para una PYME de República Dominicana, la previsibilidad del costo y la privacidad de los datos importan más que exprimir el último 3% de precisión.
Chequeo de realidad de la infraestructura: Hoy ambas R9700 sirven el modelo en tensor-parallel — y el diseño llegó hasta aquí sobreviviendo turbulencia real de hardware en el camino. La arquitectura compuesta se degrada con gracia: cuando una GPU quedó temporalmente fuera de juego, el stack siguió sirviendo con una sola tarjeta, con un tope de throughput y cero impacto en producción.
APEXiA no es un proyecto de juguete ni una prueba de concepto. Es un sistema vivo, en producción, sirviendo operaciones reales de negocio con datos reales. Maneja decisiones reales — planificación de compras, riesgo de crédito, pronóstico de demanda, estrategia de ventas — generadas por personas comunes haciendo preguntas en español llano.
Pero lo que lo hace genuinamente notable como ejemplo de Compound AI no es que funcione (hay muchos sistemas de IA que funcionan). Lo notable es cómo está compuesto:
Así debería verse el Compound AI en producción. No un chatbot con un prompt sofisticado — un sistema coordinado de componentes especializados, conectados por lógica determinista, monitoreados por pruebas automatizadas y capaces de auto-mejorarse con el tiempo.
La conclusión: Si hoy estás construyendo una aplicación de IA, tu arquitectura importa más que tus prompts. Elige el modelo correcto para cada sub-tarea, maneja los errores programáticamente, incorpora autocorrección y no intentes hacerlo todo en una sola llamada al LLM. Compound AI no es una palabra de moda — es la práctica de ingeniería de construir sistemas que sobreviven al contacto con el mundo real.
APEXiA demuestra este principio en acción. Reemplaza lo que habría sido un equipo de analistas, un científico de datos y un desarrollador de BI — y lo hace corriendo en un solo equipo con dos GPUs de estación de trabajo, costando casi nada en gastos operativos, y sirviendo la lógica de negocio específica de una fábrica de materiales de construcción de República Dominicana.
Eso es compound AI. No es teoría. No es un paper de investigación. Es software publicado.
APEXiA · Miami, FL — sirviendo a América Latina
la serie v17 · 2026
— El sistema del que estás leyendo está vivo y sirviendo tráfico de producción todos los días —
A deep-dive into the APEXiA system — a production-grade compound AI stack that orchestrates multiple AI models, data pipelines, and business logic to run an end-to-end analytics, forecasting, and CRM platform for manufacturing. No data scientists required.
Compound AI Systems are architectures that combine multiple AI components — models, tools, orchestration layers, and data pipelines — into a coordinated whole that does more than any single model could.
The term was popularized by Andrew Ng and others in 2024–2025 as the frontier of practical AI engineering. The insight is simple but profound: no single LLM is good at everything. A system that chains specialized models — a classifier here, a SQL generator there, a forecaster somewhere else — coordinated through deterministic logic and self-correction loops, will outperform any monolithic prompt in reliability, accuracy, and cost.
Key principle: In a compound AI system, the value comes not from the individual components but from their composition. The architecture — how components interact, how errors are detected and corrected, how data flows between them — is the actual product.
Typical characteristics of compound systems:
Before compound architectures, the standard approach to building AI-powered applications was monolithic: write one elaborate system prompt and hope the LLM has enough context, enough reasoning ability, enough formatting discipline to do everything — classify, retrieve data, generate SQL, analyze results, and explain insights — in a single call.
This approach has fundamental limitations:
| Monolithic Prompt | The Reality |
|---|---|
| Everything in one system prompt | Prompt bloats past the model's effective context window; performance degrades non-linearly beyond ~5k-8k tokens of instructions |
| One model does classification + generation + analysis | LLMs are mediocre at both structured classification (low confidence) and complex SQL generation (hallucinated columns/joins); specialized prompts/models work better |
| No self-correction | If the SQL is wrong, the whole pipeline fails — there's no retry mechanism embedded in the architecture |
| No model specialization | Claude is great at SQL but slow/expensive for classification; Qwen is fast for classification but less reliable at complex queries. Using one model for both wastes money and performance |
| Black-box behavior | If results are wrong, you can't tell whether the failure was in intent understanding, SQL generation, data quality, or explanation |
The compound alternative: Separate concerns architecturally. Route each sub-task to the model best suited for it. Build deterministic error-detection into the pipeline. Make the architecture a first-class design artifact, not an afterthought.
APEXiA is not an experiment or a prototype. It is a production-grade compound AI system built for a Dominican Republic construction materials factory — and designed from day one to be a template for multi-tenant deployment across dozens of other SMBs.
The system handles real business operations: inventory tracking, sales analytics, accounts receivable/payable, demand forecasting, churn prediction, and WhatsApp-based order intake. It runs entirely on a single box with two AMD Radeon AI PRO R9700 GPUs, serving a Qwen3.6-35B-A3B model locally via vLLM.
But more important than those numbers is how the pieces fit together. Below we decompose the entire architecture layer by layer, then zoom into the intelligence and orchestration mechanisms that make it all work.
Every compound AI system is only as good as its data layer. APEXiA's foundation is a carefully constructed ETL pipeline that mirrors a legacy Oracle database (used by the client) into a modern PostgreSQL instance.
business operations — orders, inventory, payments — are managed in an Oracle database used by the client. This is a faithful, read-only mirror. The APEXiA system never modifies raw el ERP data. All transformations happen at the view layer (Layer 1).
Hard rule embedded in the system: Raw tables (in schemas like cxc.*, fat.*, inv.*, cnt.*) are ERP-faithful mirrors. No UPDATE, INSERT, DELETE, or ALTER is ever applied to them. All transformations live in the ia.* (canonical) or bi.* (materialized views) layer. The ETL's TRUNCATE+INSERT refresh is the only legitimate raw-table mutation.
The entire stack runs on a single PostgreSQL instance (Postgres Docker container). Each tenant gets their own database, role, and read-only user. This is the tenant_NNNN pattern — privacy-by-design numbering that prevents tenants from enumerating each other via Postgres system catalogs.
The ETL runs in a separate Python environment (etl_env/venv) using scripts that connect to both the Oracle source and the PostgreSQL destination. The canonical migration orchestrator is promote_to_production.py, which handles schema drift detection and incremental column adds from the ERP.
Real ERP data is never perfectly complete — some sales channels live outside the main system. The compound layer accounts for this honestly: it doesn't pretend completeness, and downstream analytics are aware of any coverage gap. That awareness is a feature, not a bug — it shapes how the AI qualifies its answers.
Layer 1 sits between the raw el ERP mirrors and the AI interfaces. It is the canonical abstraction layer — the ia.* schema — that makes multi-tenant scaling possible.
In a multi-tenant system, each tenant's source ERP looks different. the current ERP has its own column names, table structures, and business conventions. Future tenants may use completely different ERPs. Layer 1 exists so that the AI layer never knows what ERP a tenant uses. It always talks to ia.v_ventas_detalle, ia.v_inventario_diario, etc. — columns and semantics that look the same regardless of what's underneath.
Sales transactions with product, client, date, margin
Daily inventory levels per SKU across all warehouses
Accounts receivable — customer balances and aging
Accounts payable — vendor obligations and aging
Operating expenses summarized by category and period
Demand forecast from iAx Científico (XGBoost/Prophet)
Churn predictions with severity buckets and explanations
These views are 17+ in total, each mapping business concepts (sales, inventory, receivables) into a consistent column shape. The chatbot's few-shot examples, schema docstrings, and SQL prompts all assume ia.* is portable across tenants — only the ETL below it absorbs source-specific quirks.
Multi-tenant design principle: When adding a column or view shape, ask: "Would another tenant's data have this column under the same name?" If no, push the divergence into ETL, not the ia.* layer. This keeps the AI layer generic without needing tenant-specific routing.
If Layer 1 is the "language" that both the business and AI share, Layer 2 is the predictive intelligence engine. This is iAx Científico — the AutoML system that continuously improves forecast and churn models using real data.
The demand model uses two algorithms in tandem:
Both are wrapped in a PL/Python function (train_demand_model) running inside Postgres. The model trains on every scheduled run, producing predictions that land in the v_pronostico_demanda view — making them automatically available to Layer 3's chatbot.
Bug fix that proved critical: A runaway n_jobs bug in XGBoost (defaulting to all CPU cores) caused the model to hang for 63 minutes per run, pegging 30+ cores. The fix — adding 'n_jobs': 1 — brought training from 63 minutes to 17 seconds. This is a perfect example of why compound AI needs deep integration between components: the data pipeline (Postgres), the ML library (XGBoost), and the GPU model (Qwen) all interact through shared infrastructure that must be carefully calibrated.
The churn model went through a fundamental re-architecting. The original version predicted churn using a target that was recency-circular — it used features observed up to the cutoff point, but the target itself (whether a customer churns) was defined using post-cutoff behavior, creating leakage.
The fix reframed to a leading indicator: predict who goes dormant in the next 90 days using only features observed before a temporal cutoff. The result:
The leading GBM is a HistGradientBoostingClassifier that ingests activity/RFM windows, decline trends, product breadth/HHI, margin, and seasonality. It refuses to ship if it can't beat the recency-only baseline, and it produces per-customer explanations in Spanish (seller Spanish, the target audience). The model caught non-obvious drifters — clients 137 days silent on a 195-day cadence — that a simple recency rule would have missed.
This is where APEXiA becomes genuinely compound. iAx Científico's AutoML system doesn't just train models — it proposes new features autonomously.
The Qwen LLM (via the same vLLM endpoint) proposes new features in a constrained DSL: windowed aggregates, ratios, and deltas over monto/n_prod/margen. Each proposal includes a description in Spanish and a justification.
Each proposed feature is evaluated on an out-of-time split. A threshold gate (AUC lift ≥ +0.002) determines whether it passes. This prevents circularity: features that just memorize the training window are rejected.
Both tiers fire end-to-end. Qwen and Claude each propose 5 features per run. In one validated run, all were rejected (closest: +0.00193, just under the bar). The registry tracks provenance — who proposed what, when, and the evaluation result.
Features that consistently fail evaluation get self-disabled (enabled=FALSE). The system cleans up its own feature registry, keeping only the useful ones. This is a feedback loop that compounds improvement over time.
Key insight: The feature proposer isn't just "generating random ideas." It operates within a constrained leakage-safe DSL. The proposed features must follow strict rules (windowed aggregates over pre-cutoff windows, evaluated only over that window). This is compound intelligence: the LLM proposes, the deterministic evaluator validates, the database records.
A fascinating design: the churn system doubles as a supply-chain procurement signal. Some finished items are manufactured only because one specific customer orders them (made-to-order demand). When that customer lapses, raw materials stop being procured. The resurrection model predicts which lapsed customers reactivate and when, enabling procurement planning with lead time awareness.
The detector identifies made-to-order items by ranking demand predictions by per-product WMAPE (Weighted Mean Absolute Percentage Error). The worst-forecast products are exactly the single-customer items:
This is compound AI at its best: the interaction between the demand forecasting system, the churn prediction system, and the procurement signal creates a business capability that none of the individual components could provide alone.
Layer 3 is the user-facing surface. It has two components that together serve all analytical and operational needs.
The flagship product. Users (sales reps, the factory owner, accountants) ask questions in Spanish about the business. The system translates that into SQL against the ia.* views, executes it, and returns a natural-language analysis in Spanish.
"¿Cuánto vendimos en mayo vs. abril?" or "¿Qué productos tienen inventario bajo?"
Emits INTENT:DOMAIN|CONFIDENCE|ALTERNATES — e.g. INTENT:VENTAS|HIGH (single domain). The classifier is itself a request to Qwen; vLLM prefix-caches each distinct system prompt, making repeated classification very fast.
CONFIDENCE=HIGH + single domain → fast path (scoped single-domain schema, one-shot SQL). Otherwise → hybrid path (union schema of primary + alternates, with self-correction retry on SQL failure).
One request to Qwen with the scoped schema docstring and few-shot examples. Temperature clamped to 0.1 for determinism. The SQL is cleaned (stripped of reasoning tags, markdown fences, anchors to last SELECT).
SQL runs against tenant_0001 with search_path = ia, public. Read-only validation uses a database role; writes use a role with write permissions.
Results fed back to Qwen for natural-language summary in Spanish. Temperature uses configured 1.0 for conversational tone. Results + interpretation returned to user.
| Feature | Standard (Qwen) | Premium (Claude) |
|---|---|---|
| Model | Qwen3.6-35B-A3B MoE (local) | Claude Sonnet (Anthropic API) |
| Architecture | Anchor Engine 2.0 (5-step pipeline: classify → route → SQL → execute → interpret) | Autonomous — Claude gets full schema + execute_sql tool, does everything in one shot |
| Cost | $0 (local GPU) | $0.018/message (est.) |
| Speed | ~100 tok/s single GPU | Variable, API-dependent |
| Self-correction | Yes — hybrid path has self-correct retry on SQL failure | Inherent — Claude can retry itself |
A complementary system that serves sales reps. Sales reps send orders via WhatsApp. The CRM parses them, manages seller cards, generates estado-de-cuenta (statement) PDFs, and pushes orders into the ERP system. This is compound in a different way: it combines LLM-powered intent extraction from WhatsApp messages with deterministic order processing and PDF generation.
Qwen parses WhatsApp messages to extract product codes, quantities, delivery dates. Deterministic validation follows to ensure all required fields are present.
Each seller gets a card showing their pipeline, recent orders, and account balance. Customers can request "estado de cuenta" — a PDF statement — which is generated on demand and delivered back via WhatsApp.
Validated orders are pushed into the ERP (Oracle) via a dedicated connection. The push includes FECHAENTREGA, IMPUESTO (18% ITBIS), TASADECAMBIO fields, making the order fully operational in the legacy system.
The Anchor Engine is the routing core of the iAx Analista system — the piece that makes the compound architecture work in practice. Without it, the system would just be a fancy SQL query builder. With it, the system has confidence-aware routing and self-correction on failure.
It operates on three signals from the classifier:
ia.* view schema to inject into the SQL promptThe six intents (CHAT, DATA, ANALYSIS, DATA+ANALYSIS, FOLLOWUP, FOLLOWUP+DATA) further determine whether additional follow-up context is loaded from a session cache (TTL 30 min, max 200 sessions, 3-entry results ring buffer for multi-turn sequences).
Why this is compound intelligence: The classifier doesn't just return a label — it returns a structured response that drives deterministic branching in the orchestrator. That orchestrator then assembles a scoped prompt, sends it back to the same model (Qwen), and if execution fails, automatically retries with a corrected schema. This is a feedback loop within a single API call. No monolithic prompt does this.
SQL generation failures are caught at execution time. When a query fails (column not found, table not found, type mismatch), the hybrid path triggers a self-correction retry:
Postgres returns an error (e.g. "column porc_margen does not exist").
The system has a _BLOCKED_COLUMNS registry (~5 top hallucination patterns) that maps common LLM hallucinations: margen_pct → porc_margen, monto_neto → monto_neto_rd, etc.
The corrected query executes. If it succeeds, the workflow continues to interpretation. If it fails again, the route falls through to the hybrid path with expanded schema.
This error-handling chain — parse, map, retry — is deterministic code, not a prompt trick. That's what makes compound AI reliable: the failure modes are understood, mapped, and handled programmatically.
One of the defining characteristics of a true compound AI system is using the right model for the right sub-task. APEXiA demonstrates this principle across four distinct AI models, each in its optimal role:
| Model | Role | Why This Model |
|---|---|---|
| Qwen3.6-35B-A3B (MoE, 3B active / 35B total) | Classification, SQL generation, natural-language interpretation | Runs locally on AMD Radeon R9700 GPUs via vLLM. Fast (~100 tok/s), cheap ($0 inference), large 262k context window. MoE architecture makes it efficient enough for real-time use. |
| Claude Sonnet | Premium tier alternative — autonomous SQL + analysis | Superior SQL generation on complex queries. Uses Anthropic API ($0.018/msg). Acts as a fallback for users who need premium-grade accuracy. |
| HistGradientBoosting (scikit-learn) | Churn prediction, demand regression | Tabular data specialists — far better than any LLM at structured regression/classification. Trained on panel data from the ia.* views. |
| Prophet | Seasonal demand forecasting | Time-series specialist for trend + holiday seasonality. Bulk-horizon prediction (predicts entire future window in one call). Used in tandem with XGBoost for ensemble advantage. |
Why 4 models instead of 1: A single LLM cannot be the best classifier, SQL generator, forecaster, and churn predictor simultaneously. Each sub-task benefits from a model specialized for it. The orchestration — deciding which model handles which part of the pipeline — is the compound intelligence itself.
The model diversity extends to the AutoML layer too: the feature proposer uses Qwen (Standard) and Claude/Opus (Premium), evaluating proposals against XGBoost and Prophet models trained on actual production data. This is a meta-learning loop: the LLM proposes features, the ML models evaluate them, the evaluation results inform future proposals.
Perhaps the most sophisticated aspect of APEXiA's compound architecture is the AutoML system's ability to improve itself autonomously. The feature engineering loop doesn't just train a model — it maintains a living feature registry that grows, prunes, and evolves as new data arrives.
Each proposed feature is recorded in cientifico.demand_feature_registry with:
When a feature consistently fails evaluation (below the AUC lift threshold), the system automatically sets enabled=FALSE. This means:
The system also tracks which features are tied to exogenous data sources (weather_BCRD) that haven't been wired in yet. These are queued for re-proposal when those data sources become available. It's a waiting queue of ideas that the system holds and revisits when the precondition is met.
Self-healing AutoML is the "compound" multiplier: Each AutoML run improves the feature set, which improves the model, which produces better demand forecasts and churn predictions, which feed back into the ia.* views, which the chatbot uses to give better answers. The system compounds improvements over time — this is the literal meaning of "compound AI."
Observability is critical in compound AI systems because failures can originate in any component. APEXiA incorporates monitoring at multiple levels:
| Monitoring Layer | Mechanism |
|---|---|
| API Health | /health endpoint returning version, active backends, classifier reachability, session count |
| Test Suite | ~130 tests across 11 suites (inventory, financial, mixed, multi, followup, forecast, churn, yoy, etc.). Post-ship regression gate. |
| Classifier Benchmarks | bench_classifier_v2.py — accuracy ≥95% format + ≥95% HIGH precision required on production |
| Throughput Benchmarking | apexia_benchmark.sh — per-user and aggregate tok/s sweep at various concurrency levels, prompt size parameters |
| AutoML Health | NOTICE capture for a failure in the evaluation step (automatic run revert, feature auto-disabled), self-healing checks, grain watchdog (count(distinct entity_key) == count(*)) |
| ETL Health | detect_stuck_runs() and cleanup_stuck_runs() functions in Postgres, n8n execution watchdog |
Notice there are no traditional dashboards for API monitoring. The health is checked programmatically via script execution. This is consistent with the compound AI philosophy: observability should be automated, actionable, and integrated into the pipeline, not something an engineer has to actively look at.
Key principle: automate the observability loop. When a test fails, the BUGFIX_QUEUE.md is updated. When an AutoML run stalls, the watchdog detects it. When a classifier degrades, benchmarking flags it. The system monitors itself.
APEXiA was designed from the start to serve multiple tenants — different companies, each with their own data, ERP, and business logic. The compound architecture makes multi-tenancy clean:
Because the ia.* schema is portable, onboarding a new tenant is an ETL problem only — the compound AI architecture itself doesn't need to change. This is what makes the system genuinely scalable.
Here's how APEXiA (compound) compares to a monolithic system that tries to do the same thing in a single LLM call:
| Property | Monolithic Approach | APEXiA (Compound) |
|---|---|---|
| Architecture | One giant system prompt (~10k+ tokens) | Modular: classifier → router → SQL-gen → execute → interpret (5 explicit stages) |
| Error handling | Retry with the same prompt — same failure mode | Deterministic self-correction: parse error → map fix → retry with corrected schema |
| Model used | One model for everything — mediocre at all tasks | Qwen for classification/SQL, Claude for premium, XGBoost for tabular, Prophet for time-series |
| Forecasting | LLM tries to predict numbers in a prompt — unreliable | Dedicated ML pipeline (XGBoost + Prophet), AutoML-proposed features, evaluation gates |
| Churn prediction | LLM analyzes past interactions — circular, leaky | Leading GBM with temporal cutoff, out-of-time validation, per-customer explanations |
| Multi-tenant | Tenant-specific prompt tweaks or separate giant prompts | Portable ia.* schema, ETL absorbs source differences, zero AI-layer changes |
| Self-improvement | Manually prompt-engineer better few-shot examples | AutoML proposes features, evaluates them, auto-disables failures, maintains registry |
| Observability | Hope the LLM formatted correctly | 130+ tests, classifier benchmarks, throughput benchmarks, stuck-run watchdogs |
| Cost | High — one expensive model doing everything | $0 for inference (local Qwen), Claude Premium opt-in for edge cases (~$0.018/msg) |
| Reliability over time | Drifts — few-shot examples rot, model capabilities shift | AutoML compounding features, view snapshots, CI/CD test gate before shipping |
The difference isn't just technical — it's philosophical. A monolithic approach treats the LLM as a universal problem-solver. A compound approach treats the LLM as one component among many, optimizing the overall system's reliability, cost, and correctness.
APEXiA's design decisions reflect a clear philosophy that shapes its compound architecture:
The default stack is entirely open source: Qwen model (local), vLLM (inference server), PostgreSQL (database), n8n (orchestration), Scikit-learn/XGBoost/Prophet (ML libraries). Paid APIs (Anthropic Claude) are a removable edge — used only when the local stack genuinely can't handle the task. This keeps costs near zero and prevents vendor lock-in.
All inference runs locally on the operator's own hardware: two AMD Radeon AI PRO R9700 GPUs with ROCm/vLLM serving. The model is Qwen3.6-35B-A3B-MXFP4 (4-bit quantized MoE), running TP2 across both cards with MTP speculative decoding (≈75 → ≈100 tok/s, 2.2× speedup). This means:
This inversion — local model as default, expensive API as opt-in — is the opposite of most AI startups. It reflects a pragmatic understanding: for a Dominican Republic SMB, cost predictability and data privacy matter more than squeezing out the last 3% of accuracy.
Infrastructure reality check: Both R9700s serve the model in tensor-parallel today — and the design got here by surviving real hardware turbulence along the way. The compound architecture degrades gracefully: when one GPU was temporarily out of play, the stack kept serving on one card with a throughput cap and zero production impact.
APEXiA isn't a toy project or a proof-of-concept. It's a live, production system serving real business operations with real data. It handles real decisions — procurement planning, credit risk, demand forecasting, sales strategy — generated by ordinary people asking questions in plain Spanish.
But what makes it genuinely noteworthy as an example of Compound AI isn't that it works (there are many working AI systems). What makes it noteworthy is how it's composed:
This is what Compound AI should look like in production. Not a chatbot with a fancy prompt — a coordinated system of specialized components, connected by deterministic logic, monitored by automated tests, and capable of self-improvement over time.
The bottom line: If you're building an AI application today, your architecture matters more than your prompts. Choose the right model for each sub-task, handle errors programmatically, build in self-correction, and don't try to do everything in one LLM call. Compound AI isn't a buzzword — it's the engineering practice of building systems that survive contact with the real world.
APEXiA proves this principle in action. It replaces what would have been a team of analysts, a data scientist, and a BI developer — and it does it while running on a single box with two workstation GPUs, costing almost nothing in operational expenses, and serving the specific business logic of a Dominican Republic construction materials factory.
That's compound AI. Not theory. Not a research paper. Shipped software.
APEXiA · Miami, FL — serving Latin America
the v17 series · 2026
— The system you're reading about is currently live and serving production traffic every day —