How Virtual Jury works

An architectural walkthrough for judges: where Google ADK sits, what the model decides versus what code enforces, how twelve isolated jurors run on a pooled Google Kubernetes Engine fleet, and how every number in a findings report traces back to a tool call.

1. System

2. Google ADK: the Clerk of Court

The orchestrator is a single ADK LlmAgent — the Clerk of Court — running Gemini 3.1 Pro on Vertex AI's global endpoint (the jurors run Gemini 3.7 Flash: pro-tier judgment for the one agent that narrates findings, flash for the fleet where parallel volume matters). It is built per run with six tools bound to that run's state, then driven by InMemoryRunner.runEphemeral() with one user message: "Run the jury procedure for this case and write the findings report." The agent's final response is the report.

// api/orchestrator/clerkAgent.ts
const agent = new LlmAgent({
  name: 'clerk_of_court',
  model: 'gemini-3.1-pro-preview', // Vertex AI, location 'global'
  instruction: CLERK_INSTRUCTION, // procedure + report format
  tools: buildClerkTools(state).map(toFunctionTool),
});
const runner = new InMemoryRunner({ agent, appName: 'virtual-jury' });
for await (const event of runner.runEphemeral({
  userId: 'counsel',
  newMessage: { parts: [{ text: 'Run the jury procedure…' }] },
})) if (isFinalResponse(event)) report += text(event);

// api/orchestrator/tools.ts (excerpt)
execute: async ({ panel }) => {
  const ps = needPanel(panel);               // unknown panel → throws
  if (!ps.sealed) throw new Error(
    'Verdicts must be sealed before deliberation');
  if (ps.rounds.length >= spec.rounds)
    return { ok: false, reason: 'max rounds reached' };
  const r = await runRound(ps.panel, ps.sealed, ps.rounds, …);
  const outcome = panelOutcome(r.split, spec.verdictRule);
  // plaintiff | defendant | hung — computed, then handed to the model
}

3. One run, end to end

The juror protocol

Jurors are stateless across calls (A2A message/send carries no session); the decisions are not — they persist in Firestore and are replayed into each call by the orchestrator. All cross-juror information flows through the orchestrator's digest; a juror never sees another juror's name, persona, or identity.

4. Isolation, identity, and why it matters here

Two things make the isolation real rather than asserted. Tenancy: each juror is a distinct workspace on the pooled service; PostgreSQL row-level security scopes every query to the tenant resolved from the request, and the A2A signature binds the tenant id into the signed string, so the orchestrator can only address the juror it signed for. Protocol: verdicts are sealed before any digest exists, and the digest that follows is anonymized — identities and personas never cross the boundary. The persona generator is a seeded PRNG (mulberry32), so a panel is reproducible from its seed; combined with stateless jurors, a whole run is a deterministic function of its inputs plus model sampling.

5. Google services, concretely

6. Failure handling and limits

• A juror times out or errors → recorded absent at sealing (prior position kept in deliberation); the panel continues at ≥ ⅔ quorum, otherwise QuorumError ends the run with the reason in the stream.
• Vertex 429 bursts → jittered backoff (2s/5s/12s/20s), per-panel concurrency 6.
• Re-running a run id → reuses the juror rows it already created (personas are deterministic, so they still match).
• Model Armor unavailable → unscreened, disclosed in-stream. Blocked → run fails closed; intake returns 422.
• Abuse bounds → per-IP rate limits (30 runs / 40 intakes per hour during judging); ≤ 12 jurors, ≤ 8 variants (9 panels), ≤ 3 rounds, ≤ 12k characters per case.
• Workspace lifecycle → when a run reaches done or error, every juror workspace it provisioned is deleted (registry row, tenant identity, and row-level data — a teardown event in the stream records the count). A sweeper on boot and hourly deletes any stray juror rows older than 2 hours (runs finish in under 2 minutes), so a crashed run can't leak tenants. Reopening an old run still replays fully: it reads the run's own persisted events, not the fleet.

7. Verify it yourself

1. Open the app, choose an example from Examples ▾, keep Clerk of Court, empanel. Watch the procedure log: screened → provisioned → sealed → round → verdict → report → teardown.
2. Compare any number in the report to the event it came from — the splits in the log are the tool results the Clerk was given.
3. Click reasoning chain in Cloud Trace ↗ on a finished run: the jury.run trace shows every Clerk tool call with its result and every juror call underneath it. The telemetry card's counts come from BigQuery; the same juror calls appear there as fleet-side spans.
4. Read the code: clerkAgent.ts (ADK), tools.ts (enforcement), deliberation.ts (protocol), roundtable.ts (fleet + HMAC). Tests: npm test — 49, including the procedure enforced with no pods.

Disclosure: Virtual Jury was created during the hackathon submission period on top of Roundtable, our pre-existing open-source agent runtime (Apache-2.0), used as the underlying platform with no core code changes. Everything described above the fleet line is new work.