Gallery
1 / 5
What it does
A company posts a technical challenge. The hard part is not finding a candidate researcher. It is refusing the ones that only look right. Four Mozaik agents work the challenge at once. A research profiler and an industry analyst run independently and genuinely concurrently against one local Qwen3-4B model. A writer consumes both results from shared Mozaik state. An independent critic, running in a fresh agent and model context with its own source audit path, then decides whether the proposal survives. It survives only if every factual claim quotes a source field, carrying the record hash, the file, the locator and an immutable URL into your dataset, and only if the candidate has two independently linked research documents. Otherwise the system abstains out loud, with a reason. In the verified block, 2 of 6 cases were accepted, 1 was refused on the evidence, and 3 ran out of time. Those three are counted separately, because a case that ends on the clock has said nothing about its sources. Everything runs on CPU. No hosted model API and no API key: the run receipts record hostedInferenceCalls = 0. Model, inference engine and corpus are each pinned by content hash, and the served model is checked against the expected one before any case runs. 28 adversarial tests cover fabricated citations, misattributed authorship, altered hashes and false concurrency. An equal resource comparison pits one agent against four, sequential against concurrent, at identical ceilings for model calls, tokens, documents and CPU threads. No quality advantage is claimed anywhere: the natural challenges have no answer key, and the README marks every statement PROVEN or NOT CLAIMED in a table at the top. A system that cannot refuse cannot be trusted when it accepts.
How the agents run concurrently
WHICH AGENTS RUN AT THE SAME TIME Research profiler and industry analyst: two separate Mozaik agents, driven independently through runLoop on the same runtime, started together for a case. Retrieval runs on worker threads, then both do real local inference against a llama.cpp server with two slots. Writer and independent critic run after them, the critic in a fresh agent and model context. WHAT STATE THEY SHARE Mozaik shared state and the peer bus. The analysts publish into shared state; the writer consumes both from there, not as arguments. In the verified block: 54 peer events, 18 Mozaik answers, 4 distinct agent IDs. HOW THEY COORDINATE No central scheduler. Each agent finishes its loop and publishes. The writer waits on shared state for both. The critic gets the source evidence and the proposal, but not the writer's hidden state or retrieval ranking, so its judgement is not anchored. HOW TO CHECK WE ARE NOT BLUFFING Two HTTP requests in flight do not prove concurrent inference, so we never claim it that way. The verifier requires all three: two distinct producer IDs, overlapping task intervals, and a timestamp inside that overlap where two distinct llama.cpp slots are both PROCESSING. A negative control that deletes slot evidence must be rejected, and is. The verdict also records client_only_false_concurrency_rejected = true and same_agent_false_concurrency_rejected = true. MEASURED, verified block, 6 cases, 974.5 s observed: - 7933 samples of the server slot table - 5009 show two slots processing at the same instant: 63.1 percent of observed compute - 614.5 s of real concurrency across 4 windows - max simultaneous slots: 2, the server capacity The sequential and single agent arms face the opposite test: a mutex plus three clean readings of both slots idle before each call and at every arm boundary. That is the part that is easy to fake. evidence/concurrency-block1-verified.svg is drawn from the trace alone, and README.md shows how to regenerate it.