ProofBid: An Autonomous Tender-Prep Agent That Refuses to Fabricate

I built ProofBid, and wrote this article, for the purposes of entering the All Things Agentic Hackathon (Google × Devpost, August 2026). Everything described below was implemented and verified during the submission period.

The friction I brought

The hackathon's Taskmaster track has a "Bring Your Own Friction" mandate: find a messy, multi-step chore in your own job and build an agent that actually finishes it. Mine was easy to pick. My day job is business operations in the enterprise-equipment channel, and preparing the bid package for an equipment procurement tender is the most stressful recurring chore I know.

The pain is not writing text. It is assembly under proof obligations: requirements arrive scattered across documents; every qualification and product claim needs a specific piece of evidence behind it; pricing must stay consistent across the quotation, the bill of materials, and the summary; and one missing project-specific manufacturer authorization can invalidate an otherwise perfect package.

A chat assistant can summarize this work. It cannot be trusted to finish it, because "finished" means files a reviewer can sign off on—and a language model left in charge of facts will eventually paper over a gap with something plausible. That failure mode is disqualifying in tendering.

What ProofBid does

ProofBid turns one tender event into a complete, reviewable preparation package—or an honest refusal.

One click in a public React workbench fires the event. FastAPI on Cloud Run accepts it and returns 202. A Cloud Run Job executes the agent in the background. Cloud Storage holds task state, receipts, and deliverables. The workbench polls status, shows a live tool timeline, and offers the final ZIP only after integrity validation passes.

Two synthetic public cases differ by exactly one variable:

Green: all evidence present. The run ends completed, with 12/12 requirements matched against 63 evidence references and a validated Word/Excel/JSON/Trace/ZIP package. Both readiness flags are true.
Blocked: the same tender and catalog, with only the project authorization removed. The run ends blocked with exactly one missing item, the stable reason code PROJECT_AUTHORIZATION_MISSING, both readiness flags false—and it still delivers a validated evidence ledger and remediation package.

Nothing is fabricated to make a result look complete. Signing, pricing freeze, sending, and submission are locked: submission_executed=false and high_risk_actions_locked=true are invariant contract fields in every result.

The architecture decision that matters: routing vs. authority

The obvious critique of a safety-first agent is "isn't the model just a thin wrapper around a pipeline?" ProofBid's answer is to make the division of power explicit.

Gemini 3.5 Flash (through Vertex AI) drives the run via Google ADK FunctionTools, and its decision rights are real: it chooses the order of registered tools within enforced dependencies, decides when analysis is sufficient, chooses the correct terminal branch—complete versus blocked—and may choose exactly one legal retry after a transient renderer failure. In verified runs those are ten FunctionTool calls per task, each with a real ADK function_call_id.

Deterministic Python code owns everything a bid reviewer must be able to trust: requirement extraction, evidence matching, BOM and pricing arithmetic, readiness gates, document rendering (python-docx, openpyxl), and cross-artifact validation.

The seam between the two is a server-side state machine. The model receives no paths, shell, SQL, URLs, prices, or business facts as parameters. The runtime enforces a tool allowlist, call budgets, input digests, dependency order, idempotency, and bounded retry. Unknown tools, input drift, duplicate terminal actions, provider errors, and schema errors all fail closed. finalize_complete is unreachable until the domain and delivery validators pass; a business evidence gap must end at finalize_blocked.

Every tool call lands in a SHA-256-chained receipt (tool_receipts.jsonl), packaged with an exact-set manifest, so anyone can audit which decisions the model actually made.

What "verified" means here

I tried to hold the project to evidence standards similar to the domain it serves:

69 Python tests plus a 50-case synthetic Eval matrix (structure, missing evidence, product/pricing, prompt injection, bounded recovery) at 50/50 on local runs;
Playwright desktop and mobile checks against the real built frontend;
real Cloud Run Job executions for green, blocked, and one admin-only recovery route, each reconciled across the Gemini provider receipt, structured logs, Cloud Run revision and image digest, and matching ZIP SHA-256 hashes in Cloud Storage and the public service;
a clean-clone gate: a fresh public HTTPS clone must pass installs, tests, Eval, frontend build, Playwright, a Docker build, and a container run end to end.

All public data is synthetic by design. Real tender documents are confidential, and a fixed single-variable pair of cases lets a reviewer verify that completion and blocking are driven by evidence rather than prompt luck. Real-document parsing is the next product step—behind human approval receipts, not automated signing or sending.

What I learned

Agent autonomy is strongest when its decision rights are explicit. A constrained tool router is still meaningfully agentic if it owns recovery and terminal-branch decisions, while typed deterministic tools protect professional truth.
A truthful blocker is a feature, not a failure. Distinguishing a business blocker from a technical failure—and still shipping a validated remediation package—turned the "sad path" into the most convincing part of the demo.
Receipts beat claims. Chained digests, provider receipts, and reconciled cloud evidence made every demo statement checkable, which changed how I built everything upstream of the video.