Cuatro productos sobre un runtime.

Cuando los clientes ven los cuatro productos de GOGOGO LLC — Goddo, GoPeople, GoVista, GoTrack — la mayoría asume que son cuatro codebases separados. No lo son. Debajo son un runtime multi-agente, cuatro superficies de producto. Esta es la decisión de arquitectura que le hizo posible a un equipo fundador chico enviar cuatro productos de IA en producción en tres años. También es la decisión que casi nos rompió dos veces.

Por qué un solo runtime

Cuando Okan y yo nos sentamos a planear la empresa en 2023, ya teníamos las cuatro ideas de producto. El camino naïf era armar cuatro stacks separados: motor de generación de imágenes para Goddo, router de WhatsApp para GoPeople, CMS de señalización para GoVista, pipeline de visión por computadora para GoTrack. Cuatro codebases. Cuatro runtimes. Cuatro sets de evals. Cuatro rotaciones de on-call.

No era realista para un equipo fundador de ingeniería de dos personas. Así que hice una apuesta: los cuatro productos iban a compartir un runtime multi-agente, y las diferencias específicas de producto se expresarían como configuración encima. El orchestrator sería el mismo. Las abstracciones de agente serían las mismas. La telemetría, las harnesses de evaluación, las herramientas de replay — todas compartidas. Sólo los agentes en sí y las integraciones externas iban a diferir por producto.

La arquitectura, en breve

Cada producto es un cliente fino encima del mismo runtime. El runtime tiene cuatro preocupaciones primarias:

1. Registro de agentes — el conjunto de agentes especialistas que existen. Algunos son específicos del producto (Goddo tiene un prompt_enhancer, GoTrack tiene un pickup_detector). Otros son compartidos por los cuatro (validator, critic, tracer).
2. Orchestrator — el controlador pequeño con forma de regla que decide qué agente corre próximo, con qué payload y cómo se entregan los outputs. El orchestrator es el mismo código para los cuatro productos. Las diferencias viven en la config por-producto que le dice qué agentes están disponibles.
3. Log de eventos — cada invocación de agente, cada llamada de tool, cada payload, cada resultado, escrito en un log append-only único indexado por trace_id. La herramienta de replay lee esto. El harness de eval lee esto. El equipo de soporte lo lee cuando un cliente reporta un problema.
4. Tool broker — la capa que proxea llamadas de agente al mundo externo. WhatsApp para GoPeople. Cloudflare R2 para Goddo. Feeds de cámara para GoTrack. SDKs de signage para GoVista. Los agentes no conocen el mundo externo directamente; le preguntan al broker.

Cada producto es un manifest con forma de YAML que dice qué agentes usa este producto, en qué forma, y con qué integraciones de tool-broker adjuntas. Agregar un quinto producto sería mayormente un manifest nuevo más 2-3 agentes especialistas nuevos — el runtime en sí no necesitaría cambiar.

Lo que nos da

1. Un solo harness de eval para los cuatro productos

El trabajo de ingeniería más duro en IA multi-agente es evaluar el sistema. Armar cuatro harnesses de eval separados nos habría matado. En vez de eso, el harness es parte del runtime — cada llamada de agente se evalúa automáticamente contra una librería chica de evaluadores (validez de schema de output, grounding factual para agentes de retrieval, chequeo de alucinación para generators). Cuando enviamos una mejora a Goddo corre contra el mismo harness que una mejora a GoPeople. Las evals se acumulan.

2. Una sola superficie de observabilidad

Replay de traces, distribuciones de latencia de agentes, dashboards de costo-por-run — construidos una vez, usados cuatro veces. Cuando Goddo tuvo una caída de proveedor en 2025, nos enteramos en dos minutos porque el dashboard ya estaba cableado. Sin el runtime compartido, esa visibilidad no habría existido durante al menos dieciocho meses.

3. Una sola capa de ruteo de modelos

Cambiamos modelos seguido. Nuevo release de Claude, nuevo release de GPT, nuevo release de Gemini, nuevo modelo de difusión. Cada cambio es un cambio de config en el runtime, no un cambio de código en el producto. Goddo recibe el último modelo de imágenes el día que sale. GoTrack recibe el último cross-encoder reranker. GoPeople recibe el último clasificador chico. El runtime absorbe el cambio.

Lo que casi nos rompió

Casi accidente 1 — Filtración de abstracción específica de producto

A los seis meses estuvimos tentados a hacer un special-case para Goddo. El producto de generación de imágenes tenía características de latencia tan distintas a los otros — los tiempos de render son segundos, no milisegundos — que casi agregamos un path del orchestrator solo para Goddo. Eso habría forkeado el codebase invisiblemente. Lo agarramos en code review y rearmamos el orchestrator para manejar runs largos asíncronos como caso first-class para los cuatro productos. Valió un mes de refactor mantener el runtime singular.

Casi accidente 2 — La reescritura de 2025

A fines de 2024 el runtime v1 estaba forzado. Los contratos de agentes estaban poco tipados. El harness de eval era una pila de scripts one-off. El hot reload estaba roto. A principios de 2025 pasé dos meses reescribiendo el runtime desde cero — cada contrato de agente, cada state machine del orchestrator, cada eval. Doce semanas de trabajo enfocado, ninguna feature de producto enviada, Okan llevando customer ops solo. El runtime v2 es sobre lo que cada producto corre hoy. Si no hubiéramos tragado esa bala, la apuesta de cuatro-productos-sobre-un-runtime habría colapsado para mediados de 2025.

Qué viene después

La próxima capa es memoria cross-producto — dejar que un agente de GoPeople sepa cuáles son las preferencias de un cliente en Goddo, con consentimiento explícito y scope ajustado. El runtime es la única razón por la que eso es factible sin un proyecto de integración de seis meses. Los agentes ya comparten el log de eventos; ahora estamos armando la capa de consentimiento que les deja compartir contexto también. Mismo runtime, capacidad nueva.

“Los runtimes multi-producto no son magia. Son un impuesto que pagás temprano, un descuento que cobrás después, y una apuesta que tenés que estar dispuesto a reescribir una vez en pleno vuelo cuando la arquitectura v1 deja de escalar. Lo pagamos, lo cobramos y lo reescribimos. Tres años adentro, es la mejor decisión de ingeniería que tomamos.”

Lo que significa para nuestros clientes

Cuando un cliente de GoPeople pide una imagen Goddo para meter en un aviso de WhatsApp, funciona porque ambos productos son agentes en el mismo runtime. Cuando una señal de GoTrack dispara un cambio de pantalla GoVista, funciona por la misma razón. Los cuatro productos no son un bundle de marketing — son una familia arquitectónica real. Los clientes no siempre lo ven. Los ingenieros y la gente de customer success lo ven todos los días.

Si querés meterte en los patrones de orquestación, el harness de eval o cómo estructuramos el registro de agentes, soy fácil de encontrar. atakanozalan.com o [email protected].