Four products on one runtime.

When customers see GOGOGO LLC's four products — Goddo, GoPeople, GoVista, GoTrack — most assume they're four separate codebases. They aren't. Underneath they're one multi-agent runtime, four product surfaces. This is the architecture decision that made it possible for a small founding team to ship four production AI products inside three years. It's also the decision that nearly broke us twice.

Why one runtime

When Okan and I sat down to plan the company in 2023, we already had the four product ideas. The naive path was to build four separate stacks: image-generation engine for Goddo, WhatsApp router for GoPeople, signage CMS for GoVista, computer-vision pipeline for GoTrack. Four codebases. Four runtimes. Four sets of evals. Four on-call rotations.

That wasn't realistic for a two-person founding engineering team. So I made a bet: the four products would share a multi-agent runtime, and the product-specific differences would be expressed as configuration on top of it. The orchestrator would be the same. The agent abstractions would be the same. The telemetry, the eval harnesses, the replay tooling — all shared. Only the agents themselves and the external integrations would differ per product.

The architecture, briefly

Every product is a thin client over the same runtime. The runtime has four primary concerns:

1. Agent registry — the set of specialist agents that exist. Some are product-specific (Goddo has a prompt_enhancer, GoTrack has a pickup_detector). Some are shared across all four (validator, critic, tracer).
2. Orchestrator — the small rule-shaped controller that decides which agent runs next, with what payload, and how outputs hand off. The orchestrator is the same code for all four products. The differences live in the per-product config that tells it which agents are available.
3. Event log — every agent invocation, every tool call, every payload, every result, written to a single append-only log keyed by trace_id. The replay tool reads this. The eval harness reads this. Customer support reads this when a customer reports a problem.
4. Tool broker — the layer that proxies agent calls into the outside world. WhatsApp for GoPeople. Cloudflare R2 for Goddo. Camera feeds for GoTrack. Signage SDKs for GoVista. The agents don't know about the outside world directly; they ask the broker.

Each product is a YAML-shaped manifest that says which agents this product uses, in what shape, and with which tool-broker integrations attached. Adding a fifth product would mostly be a new manifest plus 2-3 new specialist agents — the runtime itself wouldn't need to change.

What this gives us

1. One eval harness across all four products

The hardest engineering work in multi-agent AI is evaluating the system. Building four separate eval harnesses would have killed us. Instead the harness is part of the runtime — every agent call gets graded automatically against a small library of evaluators (output schema validity, factual grounding for retrieval agents, hallucination check for generators). When we ship a Goddo improvement, it runs against the same harness as a GoPeople improvement. The evals compound.

2. One observability surface

Trace replay, agent latency distributions, cost-per-run dashboards — built once, used four times. When Goddo had a vendor outage in 2025, we noticed inside two minutes because the dashboard was already wired up. Without the shared runtime, that visibility wouldn't have existed for at least eighteen months.

3. One model-routing layer

We swap models often. New Claude release, new GPT release, new Gemini release, new diffusion model. Each swap is a config change in the runtime, not a code change in the product. Goddo gets the latest image model the day it's available. GoTrack gets the latest cross-encoder reranker. GoPeople gets the latest small classifier. The runtime absorbs the change.

What nearly broke us

Near-miss 1 — Product-specific abstraction leak

Six months in, we were tempted to special-case Goddo. The image-generation product had latency characteristics so different from the others — render times are seconds, not milliseconds — that we almost added a Goddo-only orchestrator path. That would have forked the codebase invisibly. We caught it in code review and rebuilt the orchestrator to handle long-running async runs as a first-class case across all four products. Worth a month of refactor to keep the runtime singular.

Near-miss 2 — The 2025 rewrite

By late 2024, the v1 runtime was straining. Agent contracts were under-typed. The eval harness was a pile of one-off scripts. Hot reload was broken. I spent two months in early 2025 rewriting the runtime from scratch — every agent contract, every orchestrator state machine, every eval. Twelve weeks of focused work, no new product features shipped, Okan running customer ops solo. The v2 runtime is what every product runs on now. If we hadn't bitten that bullet, the four-products-on-one-runtime bet would have collapsed by mid-2025.

What's coming next

The next layer is cross-product memory — letting an agent in GoPeople know what a customer's preferences are in Goddo, with explicit consent and a tight scope. The runtime is the only reason that's feasible without a six-month integration project. The agents already share the event log; we're now building the consent layer that lets them share context too. Same runtime, new capability.

“Multi-product runtimes are not magic. They're a tax you pay early, a discount you collect later, and a bet you have to be willing to rewrite once mid-flight when the v1 architecture stops scaling. We paid it, collected it, and rewrote it. Three years in, it's the single best engineering decision we made.”

What this means for our customers

When a GoPeople customer asks for a Goddo image to drop into a WhatsApp announcement, it works because both products are agents on the same runtime. When a GoTrack signal triggers a GoVista screen swap, it works for the same reason. The four products aren't a marketing bundle — they're a real architectural family. Customers don't always see it. Engineers and customer-success folks see it every day.

If you want to dig into the orchestration patterns, the eval harness, or how we structured the agent registry, I'm easy to find. atakanozalan.com or [email protected].