This post was created specifically for the purposes of entering the All Things Agentic Hackathon, The Taskmaster track.
I already had AI-safety tooling. Separate, independently-tested deterministic tools: a prompt-injection scanner, a claim/provenance integrity engine, a cross-session re-entry detector, an audit logger. Each one worked, on its own, against the thing it was built to test. None of them had ever been asked to do the one job they were actually built for: gate an autonomous coding agent, not just review a single message.
Quorum is what happens when you point them at that job — and then spend real time trying to prove yourself wrong about whether it actually works.
The premise
An autonomous coding agent shouldn't be trusted on its own say-so. So Quorum gives one a gate it has to clear before anything it drafts can ship — deterministic verifiers wired together, not vibes-based review, and never one model judging its own output.
A Worker Agent (Gemini 3.5, via Google's Agent Development Kit, running on Vertex AI) reads a task description, drafts a small code patch, writes a rationale, and lists the specific factual claims that rationale depends on. It self-checks by actually running the target repository's real test suite against the patch, in a throwaway copy, before calling itself done.
That proposal then hits the gate:
Sentry scans the agent's own diff and rationale for injected or manipulative content — not the target code, the agent's own output.
IntentGraph checks whether the task description is a reformulated return to an objective the gate already rejected — the re-entry attack where you get told no and just ask again with different words.
Claim verification, inside the gate itself, re-reads every cited source. VERIFIED is granted only when the claim quotes exact text found verbatim at a specific location — never from the agent's self-report, and never from keyword or topic overlap alone. The Reasoning Kernel then separately checks the resulting claim graph's logical structure.
Every stage writes to an append-only audit trail, win or lose. The gate returns PASS (opens a real pull request), REJECT (feeds the reason back for exactly one automatic redraft), or ESCALATE (stops for a human — never auto-resolved).
Round one: deploying it found real bugs
The architecture worked locally. Deploying it to Cloud Run found things no local test did — gemini-3.5-flash only served from Vertex AI's global location in this project, not the region assumed; a missing Firestore composite index that silently made every audit read fall back to the container's own ephemeral disk instead of the real database. Neither showed up until the service was actually live and actually queried.
Once those were closed, I didn't want to just say the gate worked — I ran it live against the deployed service, on all three of its own outcomes, and confirmed each one independently rather than trusting the response body alone: a real PASS that opened a real pull request, confirmed via the GitHub API; a real REJECT on a crafted manipulation phrase; a real ESCALATE on an ungrounded claim the Kernel correctly refused to resolve.
Round two: attacking it found deeper bugs
That's where most write-ups stop. This one didn't, because I don't come from a software engineering background — I come from program delivery — and the one instinct that background did give me was: don't trust your own sign-off. So I spent two rounds attacking the live service myself, and then had a second, independent AI re-audit the finished design specifically to catch what I couldn't see from inside my own build.
What I found attacking it: a trigger phrase split across a sentence boundary that slipped past a contiguous-match regex; a fabricated claim of prior human approval sitting only in free rationale text; a request to disable one of the safety system's own rules; a spelled-out email bypassing a literal-format PII pattern. All fixed, each verified against the exact payload that evaded it beforehand.
What the independent re-audit found was more structural, and more interesting:
Claim verification could mark a false claim VERIFIED. The claim "The gate rejects supported Kernel claims" — actually false, PASS is what happens on a SUPPORTED verdict — passed because every one of its distinctive words happened to occur somewhere in a large source file discussing that general topic. Keyword co-occurrence was never real confirmation of a specific assertion. Fixed by restricting VERIFIED to an exact quoted span found at a specific line — the ratio/overlap path can only ever produce REPORTED now.
A rejected objective's safety boundary could be recorded against the wrong turn, or not at all. In a fresh session, a preflight-rejected task left no trace in the re-entry graph whatsoever. In an existing session, the marker retroactively flagged whichever turn happened to be last — the preceding, innocent one, not the one that was actually rejected. Fixed by recording the real (PII-scrubbed) rejected content as its own node before marking it.
An internal redraft's exemption from re-entry scoring was too broad. It ignored any high-risk score once a redraft was in progress, not just the risk tied to its own immediately-preceding attempt — meaning a genuinely unrelated, older red flag from earlier in the same session could get waved through. Fixed by tracking the exact boundary node each redraft attempt owns, and only exempting risk traceable to those specific nodes.
A Firestore merge could silently drop a safety flag. Two copies of the same turn — one correctly flagged as a safety boundary, one not — were treated as identical duplicates, and the unflagged copy could win. Fixed to OR the flag across both, so a True never silently loses to a False.
Every one of these is now fixed and has a regression test built specifically to reproduce the original failure and confirm it stays closed.
What's still honestly disclosed, not fixed
Sentry is pattern-based defense in depth, not comprehensive protection — Unicode homoglyph substitution, zero-width character splitting, phone numbers, and API-key-shaped secrets still pass with zero findings, and that's written down, not hidden. Claim verification confirms accurate quotation at a cited location, not the truth of the sentence built around that quote — a real, narrower gap than the one already closed, and the honest current boundary of what this specific check can do. Firestore's write lock closes the load-mutate-save race within one Cloud Run instance; it doesn't yet span multiple instances racing on the same session — the real fix is a Firestore transaction around the whole cycle, still open work.
The actual thesis
A system whose entire job is deciding whether to trust something has to be checked the same way it checks everything else — by someone other than the person who built it, saying what's proven and what isn't, and never blurring the two. That's not a caveat on this project. It's the same discipline the gate itself is built to enforce, just pointed back at me instead of at the Worker Agent.
Quorum — built for the All Things Agentic Hackathon, The Taskmaster track. Gemini 3.5 via Vertex AI, Google ADK, Cloud Run, Firestore.
Top comments (0)