Research Notes

Research Notes

Last updated: August 20, 2026

Working notes from the engineering behind QUOKKA products and orchestration.

These notes cover multi-agent orchestration, the product runtime, evaluation, and the runtime we are building toward. Where something is planned rather than running, the note says so.

How we run inference today — NVIDIA GPUs on AWS, measured, not a private cluster

What runs today, what has been measured on NVIDIA GPUs, and what the public demos still use. Written as facts, because that is what they are.

Start with what actually runs. Today QUOKKA AI operates a public site, an internal CMS, and an API: Nuxt 4 on the front, Vue 3 in the CMS, ThinkPHP 8 behind it, MySQL 8.4 underneath, with automated Playwright smoke suites gating every change. Public MindLog and Pulse demos still call a hosted API. There is no 24/7 inference endpoint on our own GPUs, and no private cluster. A company page that claimed otherwise would be easy to check and wrong.

NVIDIA GPU inference has been measured. On AWS g4dn.xlarge in Sydney — NVIDIA Tesla T4, 16GB — with CUDA and vLLM 0.27.1, serving Qwen2.5-7B-Instruct-AWQ. First token about 34 ms; about 35 tokens per second on a single stream. TensorRT, Triton, NVIDIA NIM, and NeMo are not in use. The instance is on-demand, not a standing inference cluster. Larger G5/G6 instances when Sydney capacity allows.

Around the model, the target product runtime is still ordinary AWS: ECS for containerised product services, S3 for traces and assets, RDS for relational state, CloudFront at the edge, CloudWatch for operational visibility. Session and content state sit on MySQL now; vector memory, caches, and versioned traces land with the runtime rather than before it.

What will not change is the shape of the company. QUOKKA AI is not a consulting shop, a cloud reseller, or a GPU-hours broker. Usage, once products ship, will be product usage — MindLog sessions, Pulse API requests — billed under a published plan. The in-house work is orchestration: how work is split, how agents hand off, how memory lasts across a run, and how scoring and guardrails decide what is allowed to reach a person. The GPUs are a means to that, not the pitch.

What multi-agent orchestration has to hold when the fleet grows

Roles, handoffs, shared memory, and scoring — the parts that stay stable as more agents join a run.

A single chat turn can look like an agent. A product cannot. MindLog has to parse fragments, infer a mental state, generate thought bubbles, and rebuild a day you can walk back through. Pulse has to take behaviour, score, novelty, and risk and return a constrained reward. Those are pipelines with roles, not one prompt with extra adjectives.

When a second agent joins a run, the failure mode is not “the model got dumber”. It is a dropped handoff, a forgotten constraint, or two roles writing over the same state. The orchestration layer has to name the role, name the contract for the handoff, keep a working memory that outlives a single tool call, and score the step before the next role is allowed to move.

That is why we treat protocols as product code. Timeouts, retries, and recovery paths are part of the same design as the language model call. If the fleet cannot finish the work after a tool fails, we do not have a multi-agent system — we have a brittle demo. Evaluation then asks a boring question: did the trace replay, and did the score stay inside budget and anti-exploit bounds?

None of this requires claiming a foundation model trained in-house from scratch. It does require owning the control plane. Models can be served on NVIDIA GPUs; the company still has to own how work is split, remembered, and allowed to ship.

What our evaluation gate actually blocks

Regression, replay, jailbreak, and latency suites — and the experiences that never reached people because of them.

An evaluation gate is only real if it can say no. Ours is being built as a release check on scoring, replay, safety, and latency. A checkpoint that fails will stay in the lab. We would rather ship nothing than ship an agent run that cannot be reconstructed, or a recap scene that looks fine in a screenshot and falls apart under a replay.

Today that gate exists in its first form: automated smoke suites that check the public site, the CMS, and the API on every change. The product suites are specified and not yet built, because the runtime they would test is not built either. Regression will ask whether yesterday’s traces still produce the same decisions. Replay will ask whether a failure path can be inspected. Jailbreak and policy tests will ask whether a prompt can push Pulse or MindLog past the constraints we published.

Latency is where the runtime choices become product constraints rather than logos. Streaming has to fit a conversation budget on the instance we actually pay for, so vLLM and the GPU instance type matter for the envelope they set, not the names they carry. A suite that only passes on a larger GPU is not a pass. If a change needs more GPU time to look good, that is a product-budget failure — not a reason to start selling GPU hours.

The public site names what has been measured and what has not. GPU inference is measured on T4; public demos still use a hosted API; product scoring, replay, and safety suites still arrive with the runtime. That is slower than a coming-soon landing page. It is the only way the architecture claims on /technology stay honest.

These notes cover multi-agent orchestration, the product runtime, evaluation, and the runtime we are building toward. Where something is planned rather than running, the note says so.

[email protected]