Use of Gemini 3.6 Flash creating a PR
Vertex AI Endpoints
Successful Autonomous PR merged with PARS-Agent #1
Successful Autonomous PR merged with PARS-Agent #2
Successful Autonomous PR merged with PARS-Agent #3
Successful Autonomous PR merged with PARS-Agent #4
Successful Autonomous PR merged with PARS-Agent #5
Successful Autonomous PR merged with PARS-Agent #6-12 consolidated by maintainer
Successful Autonomous PR merged with PARS-Agent #13

About the project

Inspiration

Most coding agents are impressive when a human is standing beside them. They can explain a repository, generate a patch, or suggest a pull request but they often stop at the exact point where real operational work begins. A person still has to choose the repository, select the issue, verify that the issue is actionable, supervise the edit, check the tests, press the pull-request button, and then repeat the entire process for the next target.

I wanted to build something different: a background software-contribution operator that could continue working after the initial campaign policy was configured.

PARS-Agent began with a simple question:

Can an agent discover real problems in public repositories, decide which ones are appropriate, produce bounded fixes, validate its own work, open review-ready pull requests, and continue to the next target without requiring a human to coordinate every step?

The project was built for the All Things Agentic Hackathon: The Taskmaster. It extends the evidence-first philosophy behind PARS(Poole Adaptive Reasoning Stack development started Aug. 4, 2026) into a real operational system. Instead of treating Gemini as an unconstrained code generator, PARS-Agent places Gemini inside a deterministic control plane with explicit authority boundaries, immutable repository snapshots, independent review, durable receipts, idempotent publication, and visible campaign progress.

The goal was not to build a chatbot that talks about software engineering. The goal was to build an agentic system that performs useful software-engineering work in the real world while remaining observable, recoverable, and limited in what it is allowed to do.

That distinction shaped the entire project:

Gemini can rank, propose, and review.
Google ADK coordinates specialized agent roles.
PARS-Agent decides what authority exists, what evidence is required, when a target is resolved, and whether a pull request may be published.
GitHub maintainers retain final authority over every contribution.
PARS-Agent can open pull requests, but it cannot merge them, approve them, force-push upstream, or modify a maintainer’s default branch.

The project was also inspired by a practical frustration: independent builders and open-source maintainers are surrounded by issues that are useful but too small, repetitive, or distributed to receive immediate attention. A trustworthy background agent could help turn that neglected work into reviewable contributions without pretending that autonomous code generation should replace maintainers.

PARS-Agent is my attempt to build that missing operational layer.

What it does

PARS-Agent is an autonomous GitHub issue-to-ready-pull-request system.

An operator configures a campaign once by selecting the GitHub identity, accepted issue policies, repository constraints, budgets, safety limits, and schedule. After that, the system can operate as a background campaign rather than a sequence of manually triggered coding sessions.

A campaign performs the following loop:

Discover public GitHub issues.
PARS-Agent searches for issues carrying explicit contribution signals such as help wanted or good first issue.
Apply deterministic policy filters.
It rejects targets that violate repository, label, scope, identity, authority, or safety rules before spending Gemini tokens.
Freeze the accepted target batch.
The exact repository, issue, labels, commit state, and relevant metadata are captured as an immutable snapshot. Successor workers use the same frozen batch instead of silently rediscovering a different set of issues.
Rank accepted candidates with Gemini.
A Gemini-powered ranker evaluates the remaining policy-eligible targets and selects an appropriate candidate.
Revalidate the repository state.
Before authoring or publication, PARS-Agent verifies that the issue and repository still match the frozen evidence. A changed target cannot silently inherit approval from an older snapshot.
Author a bounded change.
A Gemini author proposes exact file changes, a test plan, a pull-request title, and a commit message. The proposal is constrained by file-count, repository-policy, and authority limits.
Run deterministic validation.
The system checks the proposal’s structure, file paths, prohibited changes, repository consistency, patch applicability, and configured quality requirements.
Perform independent Gemini review.
A separate reviewer evaluates issue alignment, minimality, repository consistency, test quality, and risk. The author cannot approve its own proposal.
Publish through the selected user’s fork.
When every gate passes, PARS-Agent creates or reuses the selected account’s fork, creates a bounded branch, commits the exact approved changes, and opens a pull request against the upstream repository.
Record durable evidence.
Firestore stores campaign state, target outcomes, publication receipts, continuation events, leases, idempotency keys, provider summaries, and audit evidence.
Continue to the next unresolved target.
Google Cloud Tasks dispatches the next worker immediately. Google Cloud Scheduler operates as a watchdog in case a continuation delivery is delayed or lost.
Stop only when every accepted target has a terminal outcome.

PARS-Agent uses the following campaign completion law:

[ A = P + R + U ]

where:

(A) is the number of accepted targets,
(P) is the number of targets with a published ready pull request,
(R) is the number of terminally rejected targets,
(U) is the number of unresolved targets.

A campaign is complete only when:

[ U = 0 ]

A single Cloud Run worker processes a bounded slice of targets so that execution remains recoverable and compatible with serverless runtime limits. That worker boundary is not a campaign limit. When unresolved targets remain, a successor worker continues the same frozen campaign.

Mission Control exposes the authoritative state of the campaign, including:

issues observed;
accepted targets;
published pull requests;
terminally rejected targets;
resolved targets;
unresolved targets;
frozen target-batch identity;
actual pull-request links;
current worker slice;
continuation dispatch state;
continuation delivery state;
configured Gemini model;
campaign trace;
evidence ledger;
candidate attempts;
deterministic triage decisions;
sanitized Gemini provider events.

PARS-Agent is deliberately bounded. It may:

search public repositories;
read issues and repository state;
use Gemini to rank, author, and review;
create a fork under the selected account;
create a branch in that fork;
commit approved changes;
open a pull request;
continue through the campaign.

It may not:

merge a pull request;
approve its own work;
comment on issues or pull requests without separate authority;
force-push to an upstream repository;
write to an upstream default branch;
expose credentials;
bypass repository policy;
treat a changed repository snapshot as unchanged;
mark a campaign complete while accepted targets remain unresolved.

How we built it

I built PARS-Agent as an independent builder using an AI-assisted development process, with Google’s agent and cloud technologies forming the operational runtime.

The system is not a single prompt wrapped around the GitHub API. It is a multi-layer architecture in which probabilistic model outputs are governed by deterministic state machines, authority checks, and durable evidence.

Agent layer

PARS-Agent uses Google Agent Development Kit to coordinate specialized roles:

Ranker — evaluates accepted candidates and selects the next target.
Author — produces a typed, bounded repository-change proposal.
Reviewer — independently evaluates issue alignment, minimality, test quality, consistency, and risk.
Orchestrator — controls handoffs, validates typed outputs, enforces snapshot consistency, and decides whether publication may begin.

The system uses Gemini 3.6 Flash through Google’s Gemini/Vertex AI stack. The configured model is propagated to the ranker, author, reviewer, and orchestrator rather than allowing individual roles to silently fall back to different hard-coded models.

Every provider session emits sanitized structured logs containing fields such as:

component
provider
model
role
event
workflow
session_id
timestamp
message

This makes the exact Gemini model visible in Google Cloud Logging through jsonPayload.model without persisting prompts, source replacement content, full model responses, credentials, or authorization headers.

Deterministic control plane

The deterministic control plane governs:

campaign creation;
accepted-target policy;
authority limits;
quotas and budgets;
emergency stop;
immutable snapshot generation;
target-batch freezing;
candidate lifecycle;
leases;
idempotency;
duplicate-delivery suppression;
proposal validation;
independent-review requirements;
publication authorization;
campaign completion;
continuation dispatch;
recovery after partial failure.

Gemini can propose a change, but it cannot make a proposal valid merely by claiming that it is valid. The control plane requires machine-verifiable evidence before publication.

Google Cloud architecture

The deployed system uses:

Cloud Run for Mission Control, the authenticated API, campaign views, Run Detail, event streaming, and continuation endpoints.
Cloud Run Jobs for bounded Taskmaster execution.
Firestore for durable campaign state, immutable target batches, outcomes, receipts, leases, evidence, and recovery.
Cloud Tasks for authenticated successor-worker delivery.
Cloud Scheduler as a one-minute watchdog for unresolved campaigns.
Pub/Sub for durable event-delivery paths used by the broader agent runtime.
Vertex AI for Gemini execution.
Cloud Logging for structured, searchable provider and orchestration events.
Secret Manager for the GitHub credential, control token, and connection material.
Cloud Build for reproducible container builds.
Artifact Registry for Mission Control and Taskmaster container images.
Cloud Storage for durable build and runtime artifacts where required.
IAM service accounts with separated deployment, execution, invocation, continuation, and service-agent responsibilities.

GitHub publication architecture

PARS-Agent uses the GitHub API through the operator-selected account.

For each approved target, it:

confirms the upstream repository and immutable snapshot;
creates or reuses the selected account’s fork;
creates a deterministic campaign branch;
applies only the independently approved changes;
commits with a generated but bounded message;
opens a pull request against the upstream repository;
stores the repository, issue, branch, commit, pull-request number, URL, and proposal fingerprint as durable evidence.

Stable campaign, repository, issue, and snapshot identities prevent a newly generated discovery ID from duplicating an already published pull request.

Mission Control

Mission Control is not a mock dashboard. It is the operator and judge-facing projection of the same durable state used by the campaign workers.

It presents:

live campaign status;
immutable authority configuration;
accepted-target decisions;
candidate attempts;
publication receipts;
pull-request links;
Gemini model and provider events;
continuation dispatch and delivery;
campaign trace;
evidence ledger;
security boundaries;
setup and deployment verification.

The campaign page and Run Detail page reconstruct progress from the same authoritative batch-wide receipts so that an older worker cannot overwrite newer campaign truth.

Windows-first setup

Because the project needed to be accessible to a Windows builder and reproducible by judges, I packaged a Windows launcher and browser-based Setup workflow.

The setup process verifies:

Python and packaged runtime availability;
Google Cloud CLI authentication;
Application Default Credentials;
project and billing access;
required APIs;
Firestore database configuration;
Artifact Registry;
Cloud Build;
Cloud Run;
Cloud Run Jobs;
Secret Manager;
Cloud Tasks;
Cloud Scheduler;
service identities;
queue state;
IAM bindings;
GitHub token type and scope;
public-fork readiness;
final deployment health.

The product was repeatedly tested through fresh extraction and cleanroom execution rather than only from the development directory.

Validation and release discipline

The final v0.10.7 release passed:

470/470 source tests;
470/470 tests against the exact packaged ZIP in cleanroom extraction;
all Taskmaster subtests;
Python syntax verification;
JavaScript syntax verification;
HTML identity checks;
ZIP integrity checks;
duplicate-entry checks;
manifest and checksum verification;
frozen-surface verification;
Windows-launcher identity verification.

The release process also preserved RED tests that reproduced earlier defects before confirming the corresponding GREEN fixes.

Challenges we ran into

The most difficult part of PARS-Agent was not asking Gemini to write code. The difficult part was making a real background agent continue correctly, report the truth, preserve authority, recover from failures, and avoid publishing duplicate or unsafe work.

The challenge list below is intentionally detailed because many of the most important lessons came from failures that only appeared during live execution.

Defining real autonomy

The earliest versions still required too much human coordination. Repositories had to be entered manually, tasks had to be selected manually, and publication could depend on a person pressing the next button.

That did not satisfy the project’s goal. A truly autonomous campaign needed to perform scheduled discovery, deterministic acceptance, Gemini ranking, authoring, independent review, publication, and continuation after one bounded setup step.

The design therefore evolved from individual missions into durable autonomous contribution campaigns.

Moving past the first pull request

One of the most serious bugs caused the campaign service to return immediately after the first successful pull request.

The system could discover many accepted targets, publish one useful PR, and then project the worker as complete even though the campaign itself was not complete.

This forced us to separate two concepts:

worker completion, meaning one bounded Cloud Run transaction ended;
campaign completion, meaning every accepted target had reached a terminal outcome.

That distinction became the foundation of the final campaign invariant.

Accidentally turning a worker slice into a campaign cap

To keep Cloud Run execution bounded, the worker attempted a maximum of eight candidates per transaction. In an earlier release, that execution boundary behaved like a campaign-wide limit.

A campaign with 30 accepted targets would attempt eight, publish one, and then stop without moving to target nine.

The final design keeps the bounded slice but requires an authenticated successor worker whenever unresolved targets remain.

Incorrect `RETRY_PENDING` semantics

Candidate-local failures including malformed Gemini output, author abstention, independent-review rejection, deterministic quality rejection, prohibited file changes, and stale repository snapshots were initially recorded as indefinitely retryable.

That created several problems:

rejected candidates remained counted as pending;
the first eight candidates could be selected repeatedly;
later accepted targets were starved;
the dashboard showed numbers such as one published and 29 pending even after seven other targets had already been evaluated;
repeated Gemini calls could reproduce the same rejected proposal.

We replaced this behavior with explicit terminal target outcomes:

READY_PR_OPENED
TERMINAL_REJECTED

Only genuine campaign-wide failures such as provider outage, unavailable GitHub API, exhausted external quota, authentication failure, or emergency stop remain retryable.

“Continuation queued” did not mean a worker was queued

An earlier version updated next_scan_at and displayed the continuation as queued. No Cloud Run successor was necessarily dispatched.

This was a dangerous observability bug because the user interface claimed progress while nothing was actually scheduled to execute.

The final system distinguishes:

ENQUEUED
ALREADY_EXISTS
DELIVERED
WORKER_SUCCEEDED
WORKER_RETRYABLE
WORKER_FAILED
FAILED
DISABLED
NOT_REQUIRED

Continuation is now based on durable Cloud Tasks receipts, not an inferred future timestamp.

Immediate continuation was rejected as “not due”

After Cloud Tasks delivery was added, another subtle bug appeared: the continuation request entered the normal campaign scheduling path and was rejected as CAMPAIGN_NOT_DUE.

The system had successfully created the successor task, Cloud Tasks had successfully delivered it, and the application itself then refused to perform the work because the ordinary interval had not elapsed.

The fix introduced a validated continuation path that:

verifies the deterministic continuation payload;
loads the exact frozen target batch;
confirms campaign identity and delivery authority;
forces execution of the unresolved batch;
bypasses the normal discovery interval without bypassing safety policy.

Cloud Scheduler could not be the primary continuation mechanism

Cloud Scheduler was originally asked to do too much. A periodic schedule is useful as a watchdog, but it is not an exact successor-worker queue.

The final architecture uses:

Cloud Tasks for immediate, authenticated continuation;
Cloud Scheduler as recovery protection when an unresolved campaign has no recent successful worker.

We also had to correct Scheduler identity handling because Google can send a fully qualified job-name header rather than only the short job ID expected by the first implementation.

Queue existence was mistaken for queue health

A Cloud Tasks queue could exist while remaining paused or otherwise unable to dispatch.

Earlier setup verification checked for existence but not a verified RUNNING state. This could make Mission Control report a queued continuation while the queue was incapable of delivering it.

Deployment now describes the queue, resumes it when necessary, describes it again, and fails verification unless the queue is actually running.

Stale and contradictory campaign progress

The campaign screen and Run Detail screen initially derived their status from different worker-local projections.

That caused several contradictions:

one screen could show the original accepted count while another showed only the latest worker;
an older Run could overwrite newer campaign-wide truth;
published PRs could be missing from the current screen;
rejected targets could still be counted as unresolved;
“queued” status could survive after a later failed dispatch;
progress could appear frozen even while durable receipts had changed.

The final UI reconstructs progress from one authoritative source:

the frozen accepted-target batch;
all terminal target outcomes;
all ready-PR publication receipts;
all continuation lifecycle receipts;
the configured Gemini model.

Preserving one frozen accepted-target batch

Repeating GitHub discovery between worker slices could silently replace or reorder the campaign’s target set.

That would make progress counts unstable and could allow newly discovered issues to displace previously accepted ones.

The final campaign freezes a target batch once and reuses its stable identity across all successor workers. New discovery belongs to a future campaign cycle, not the middle of an existing batch.

GitHub state changes between discovery and publication

GitHub repositories are mutable. An issue can be closed, edited, relabeled, or converted into a discussion. A repository can change its default branch, files, or relevant commit state while Gemini is working.

We repeatedly encountered candidates that no longer matched their original discovery state.

PARS-Agent therefore revalidates the exact repository and issue snapshot before authoring and again before publication. A changed snapshot receives a deterministic rejection or a new future evaluation; it cannot inherit stale approval.

Not every accepted-looking issue was actionable

Some issues had appropriate labels but were still unsuitable:

roadmap questions rather than implementation requests;
general discussions with no bounded acceptance criteria;
requests requiring unavailable domain context;
changes that would require broad architectural redesign;
issues whose apparent fix depended on hidden services;
repositories that prohibited the necessary file type;
workflow changes forbidden by policy;
proposals containing placeholder content;
proposals that were too broad for a safe autonomous contribution.

This made deterministic triage and terminal rejection as important as successful publication.

Gemini author abstention and malformed typed output

Gemini did not always return a usable repository-change proposal.

We encountered:

schema-invalid output;
abstention;
incomplete file changes;
incorrect repository assumptions;
missing tests;
proposals that did not directly address the issue;
unsafe or prohibited file paths;
proposals that were syntactically plausible but operationally weak.

The system had to treat typed-output validity as a hard gate rather than attempting to interpret malformed responses optimistically.

Independent review could not be ceremonial

A second Gemini call is not automatically an independent quality gate.

We needed to ensure that the reviewer:

received a controlled proposal representation;
evaluated the issue and immutable snapshot;
used an explicit typed schema;
returned issue alignment, minimality, test quality, repository consistency, and risk;
could reject the author;
could not publish directly;
used the same configured model surface as the other roles;
left a durable review receipt.

Several real proposals were correctly rejected because the independent review or deterministic test-quality gate identified weaknesses.

Duplicate delivery and idempotency

Cloud Tasks, Scheduler, HTTP retries, and serverless restarts all create at-least-once delivery conditions.

A retry must not:

open a duplicate PR;
create a second branch for the same immutable target;
reapply an already published patch;
count the same target twice;
replay a completed Gemini workflow;
regress campaign progress.

We introduced stable target identities, deterministic task names, scan leases, publication fingerprints, delivery identities, and duplicate-completion suppression.

Waiting for maintainer acceptance blocked progression

An early interpretation of campaign state treated an open PR as unfinished work and could wait for a maintainer to accept or merge it before proceeding.

That was incompatible with open-source reality. Maintainer review can take days or weeks.

PARS-Agent’s responsibility ends when it opens a review-ready pull request and records the publication receipt. The campaign must then continue immediately. Merge authority remains with the maintainer and is not part of agent completion.

GitHub token failures

GitHub authentication created several distinct problems:

invalid or expired credentials producing 401 Bad credentials;
repository-limited tokens passing basic access but failing public-fork operations;
fine-grained token permissions that did not support the required cross-repository workflow;
private-repository push restrictions;
organization SSO requirements;
organization policies producing 403 responses;
uncertainty about whether a token could create and update forks;
ensuring tokens were never printed or included in evidence packages.

The Setup workflow now distinguishes basic token validity from PUBLIC FORKS READY capability.

Selected-account authority

PARS-Agent had to publish from the explicitly selected GitHub account and nowhere else.

We implemented selected-account checks so that publication is tied to one immutable actor identity. The system cannot silently use another account, a maintainer credential, or an upstream write path.

Preventing excessive or arbitrary limits

Early configurations included budget and PR limits that were too restrictive for real campaigns. At one point, a small hard-coded budget cap prevented useful missions from running even though valid Google Cloud credits were available.

The final design separates:

explicit operator-selected limits;
external provider quotas;
worker execution boundaries;
campaign completion.

A worker can remain bounded without imposing an arbitrary campaign cap. A value of zero can represent no PARS-imposed daily or outstanding-PR limit while external GitHub, Gemini, Google Cloud, and budget constraints still apply.

Firestore database setup

Firestore introduced several deployment blockers:

the default database did not exist;
a database had been created in Datastore Mode rather than Native Mode;
the application expected a named database;
the configured database and deployed service did not always agree;
setup verification could pass one Firestore check but fail the actual runtime round trip.

The final setup verifies the exact project, database name, mode, and round-trip behavior.

Secret Manager IAM failures

Cloud Run initially failed to read required secrets because the runtime service account lacked secretmanager.secrets.get/access authority.

We had to separate deployer identity from runtime identity and bind access to the exact service account used by Mission Control and the worker.

Google ADK availability

One early cloud probe failed because google.adk was not installed in the runtime image.

This exposed a broader packaging lesson: local availability did not prove container availability. The deployment now verifies the actual packaged dependency and runtime import path.

Cloud Build and Artifact Registry identity problems

Building and deploying containers required multiple Google-managed and project-managed identities to cooperate.

We encountered:

missing Artifact Registry repositories;
Cloud Build permissions;
immutable-tag behavior;
image identity and expected-commit mismatches;
Cloud Run deployment failures;
Cloud Run Job launch-authority failures;
runtime-contract gates;
stale or incorrect images being deployed after a local fix.

The release process now verifies image provenance, expected runtime mode, commit identity, manifests, and deployed resource names.

Cloud Tasks service identity on Windows

A major Setup regression came from invoking:

gcloud beta services identity create

The user’s Windows Google Cloud CLI used a bundled Python installation that could not install the optional beta component during a non-interactive PARS-Agent setup.

Setup failed before deployment even began.

The hotfix removed the beta-component dependency. PARS-Agent now uses the standard gcloud auth print-access-token command and the Service Usage generateServiceIdentity REST operation, then polls the operation and verifies that the exact Cloud Tasks service agent materialized.

Exact OIDC audience and invocation authority

Cloud Tasks continuation requires more than creating a task.

The queue, service account, target URL, OIDC token, audience, and Cloud Run invocation policy must all agree exactly.

Small mismatches produced delivery failures that looked like application bugs. Setup now verifies:

the dedicated continuation service account;
token-creation authority;
Cloud Run invocation authority;
exact continuation URL;
exact OIDC audience;
queue location;
authenticated endpoint behavior.

Windows dependency installation regression

Another Windows packaging bug passed two Python packages as one malformed pip argument:

"google-cloud-secret-manager google-cloud-tasks"

That looked visually correct in a command log but was interpreted as one invalid dependency.

The final release installs and verifies the packages separately, including an explicit import check for google.cloud.tasks_v2.

Local Windows and Python setup friction

Earlier development exposed several local setup problems:

gcloud or pip not being recognized;
interrupted gcloud init;
missing Application Default Credentials;
normal gcloud login and ADC login using different accounts;
nested or incorrect directory changes;
Windows path quoting;
virtual-environment launcher copy failures;
stale extracted folders containing older code;
users accidentally running a previous executable after downloading a hotfix.

The final documentation requires fresh extraction, explicit version verification, separate gcloud and ADC checks, and visible setup receipts.

Setup regressions

Several releases fixed campaign behavior but accidentally broke deployment.

This reinforced an important rule: a progression fix is not complete unless the entire fresh-install path still works.

Later releases added focused regression tests for:

Windows service-identity creation;
Cloud Tasks dependency installation;
queue state;
IAM wiring;
Setup browser flow;
API enablement;
packaged runtime imports.

Missing Gemini model evidence

Gemini was executing, but the configured model was not clearly visible as a first-class Google Cloud log field.

Provider summaries existed, yet judges and operators should not have to infer the model from buried or inconsistent text.

We added structured JSON logging with:

jsonPayload.component = "pars-agent-gemini"
jsonPayload.model = "<configured-model>"

We also removed hard-coded role-specific fallbacks so that ranker, author, reviewer, and orchestrator use the configured campaign model.

Observability without leaking sensitive material

Detailed provider logging creates a security risk.

The system needed enough evidence to prove that Gemini executed while excluding:

prompts;
source replacement content;
full model responses;
GitHub credentials;
access tokens;
authorization headers;
private repository material.

The final provider console and Cloud Logging events store sanitized lifecycle events, typed output summaries, failure categories, token/cost metadata where available, and model identity but not sensitive content.

Mission Control had to show truth, not optimism

Several failures were made worse by optimistic labels such as “executed,” “queued,” or “complete.”

We learned that an operational dashboard must distinguish:

accepted from attempted;
attempted from resolved;
resolved from published;
task created from task delivered;
worker delivered from worker succeeded;
a bounded Run ending from a campaign completing;
model configured from model actually observed.

Mission Control now favors explicit lifecycle states over reassuring but ambiguous labels.

Preserving state across upgrades

The project evolved quickly through multiple hotfixes. Each upgrade needed to preserve:

campaigns;
target batches;
Firestore receipts;
existing forks;
branches;
commits;
pull requests;
Scheduler jobs;
Cloud Tasks queues;
selected GitHub identity;
secrets;
audit history.

Deleting and recreating the campaign would have hidden the original progression bug. Instead, migrations were designed to reinterpret earlier RETRY_PENDING records, recognize already published PRs, and continue at the first genuinely unresolved target.

Testing asynchronous systems

Many bugs did not appear in simple unit tests. They required interactions among:

Firestore state;
Cloud Tasks delivery;
Scheduler watchdog execution;
serverless retries;
cached Run projections;
GitHub snapshot changes;
Gemini abstention;
independent review;
multiple worker slices.

We built RED tests that reproduced each failure before accepting the fix, including a 30-target integration fixture that advances across four workers:

Worker 1: resolved  8 — unresolved 22
Worker 2: resolved 16 — unresolved 14
Worker 3: resolved 24 — unresolved  6
Worker 4: resolved 30 — unresolved  0

Cleanroom packaging

A development directory can pass while the downloadable ZIP fails.

We therefore tested the exact release archive after fresh extraction. This uncovered:

missing dependencies;
stale files;
accidental modifications to frozen surfaces;
package-manifest differences;
Windows-only setup defects;
files that existed locally but were absent from the release.

The final package passed the same full test set from source and from its exact cleanroom-extracted bytes.

Protecting frozen and inherited surfaces

PARS-Agent contains previously verified components and Taskmaster surfaces that were not supposed to change during a targeted hotfix.

One release accidentally modified a frozen root file. The regression suite caught it, the failure was preserved as evidence, the file was restored, and the complete suite was rerun.

Hackathon proof requirements

Building the product was only part of the challenge. The submission also needed to make the architecture and real cloud execution understandable to judges.

That required:

a public or judge-accessible repository;
exact setup instructions;
a clear architecture diagram;
visible Google Cloud execution;
visible Gemini model evidence;
real GitHub pull requests;
clear disclosures about pre-existing concepts and AI-assisted development;
a public demonstration video under four minutes;
no exaggerated claim that a test proved a live campaign outcome;
no credentials or private administrative links in the submission package.

The judge package, comprehensive README, architecture assets, evidence receipts, demo script, and submission checklist were built to address those requirements.

Accomplishments that we're proud of

Real public pull requests

PARS-Agent progressed beyond simulated patches and local demonstrations.

At the point-in-time evidence snapshot prepared for the hackathon submission, the public contribution set contained:

9 public PARS-Agent pull requests;
2 pull requests merged by upstream maintainers;
6 pull requests still open for maintainer review;
1 pull request closed without merge;
26 changed files;
1,117 additions;
191 deletions.

The two merges are especially meaningful because they were not self approved demonstrations. Independent upstream maintainers reviewed the work and chose to merge it.

A true background campaign architecture

PARS-Agent evolved from isolated agent runs into a durable campaign system that can:

discover;
accept;
freeze;
rank;
author;
review;
publish;
continue;
recover;
audit;
complete only at zero unresolved targets.

The system no longer defines success as “Gemini returned code.” Success requires a real terminal outcome for every accepted immutable target.

Bounded autonomy instead of unrestricted autonomy

PARS-Agent demonstrates that autonomy and control do not have to be opposites.

The agent can perform useful external work while preserving strict boundaries:

selected-account fork only;
no upstream default-branch write;
no merge authority;
no approval authority;
no silent issue comments;
no credential exposure;
immutable snapshot revalidation;
independent review;
deterministic publication gates;
emergency stop;
durable audit evidence.

Independent model review

The author and reviewer are separate roles. A proposal cannot publish merely because the generating model is confident.

The reviewer can reject the proposal, and deterministic gates can reject both author and reviewer outputs.

Durable, inspectable evidence

The project records enough state to reconstruct what happened:

what was discovered;
why a target was accepted;
what snapshot was frozen;
which target Gemini ranked;
whether the author returned a valid proposal;
why a proposal was rejected;
what independent review concluded;
what files changed;
which branch and commit were created;
which pull request was opened;
whether a successor task was enqueued and delivered;
which model performed each role.

Authoritative campaign progress

Mission Control now exposes the full campaign equation rather than a single success badge.

A user or judge can see published, rejected, resolved, and unresolved targets and inspect the actual pull requests and continuation lifecycle.

Searchable Gemini model proof

The exact configured Gemini model appears in structured Google Cloud logs through a searchable jsonPayload.model field.

This makes the Google AI dependency observable rather than merely asserted in documentation.

Strong regression coverage

The final release passed:

470/470 source tests
470/470 exact packaged-ZIP cleanroom tests

It also passed Taskmaster subtests, syntax checks, HTML identity checks, frozen-surface verification, package-integrity verification, and checksum validation.

Windows-accessible deployment

PARS-Agent includes a packaged Windows entry point and a browser guided Setup workflow rather than assuming that judges or independent builders will reconstruct a cloud deployment from undocumented shell fragments.

Honest evidence boundaries

One accomplishment I am particularly proud of is the decision not to hide failures or overstate results.

The release evidence distinguishes:

a unit-tested behavior from a live cloud-accepted behavior;
an open pull request from a maintainer merge;
a queued task from a delivered task;
a completed worker from a completed campaign;
a configured Gemini model from an observed model log;
a controlled live-acceptance candidate from a fully proven production deployment.

That honesty made the project harder to finish, but it also made the final system more trustworthy.

What we learned

Autonomy is a lifecycle, not a model call

The central lesson was that an autonomous agent is not defined by how impressive one generated response looks.

Real autonomy requires:

durable state;
continuation;
recovery;
idempotency;
authority;
observability;
terminal outcomes;
truthful completion conditions.

A model can author a patch in seconds. Building a system that safely continues through 30+ mutable, external targets is a different problem.

Bounded execution should not mean bounded ambition

Serverless workers need limits. Campaigns need completion.

The correct architecture bounds each transaction while allowing durable continuation across transactions. Confusing those two levels created one of the most important bugs in the project.

Rejection is productive work

A trustworthy agent should not force every accepted-looking issue into a pull request.

Determining that an issue is stale, non-actionable, unsafe, too broad, or unsupported is a valid terminal outcome. Rejecting unsuitable work protects maintainers and allows the campaign to move forward.

State names must correspond to real evidence

Terms such as “queued,” “executed,” and “complete” should only appear when their underlying event actually occurred.

A future timestamp is not a queue receipt. A task receipt is not a delivery receipt. A delivered request is not a successful worker. A successful worker is not a complete campaign.

Deterministic systems and generative models complement each other

Gemini is strong at interpreting issue intent, understanding unfamiliar repositories, producing bounded edits, and reviewing proposals.

Deterministic code is strong at authority, identity, snapshots, limits, invariants, publication gates, and auditability.

PARS-Agent became more capable when each side was allowed to do the work it is best suited for.

Independent review must have real power

Review only matters when it can stop publication.

Separating authoring from review improved both safety and the quality of evidence. It also made failures easier to understand because the system could distinguish malformed author output, deterministic-policy rejection, and reviewer rejection.

External systems are always changing

GitHub repositories, IAM policies, service identities, queues, credentials, APIs, and serverless instances are not static.

The agent must assume that previously observed state may have changed and must verify it again before acting.

At-least-once delivery must be treated as normal

Retries are not exceptional in distributed systems. They are expected.

Idempotency cannot be added later as a cosmetic improvement. It must be part of target identity, branch naming, task naming, publication, receipts, and progress accounting from the beginning.

Setup is part of the product

A cloud application that works only in the original builder’s terminal is not ready for judges or users.

Windows authentication, Google Cloud service identities, API enablement, IAM propagation, dependency packaging, GitHub token capabilities, and fresh extraction all became first-class product concerns.

Observability must answer the operator’s real questions

Operators do not only need raw logs. They need direct answers:

What is the campaign doing?
Which model is running?
Which target is active?
How many targets are resolved?
Why was this candidate rejected?
Was the next worker actually dispatched?
Is the queue running?
Which PRs were created?
Does the system need intervention?

Mission Control was redesigned around those questions.

Live evidence matters more than optimistic summaries

The strongest evidence was not a generated report saying that the system worked. It was:

a real GitHub pull request;
an upstream maintainer merge;
a visible Cloud Run execution;
a Cloud Tasks delivery receipt;
a stable target-batch identity;
a later worker processing a later target;
a structured Gemini model log;
a full cleanroom test run.

Failures can improve the architecture

The campaign-progression bugs were frustrating, but each one exposed an architectural ambiguity that needed to be removed.

The final completion law, frozen target batch, terminal rejection model, successor worker lifecycle, and authoritative UI all came directly from investigating live failures rather than hiding them.

What's next for PARS-Agent

The immediate next step is final live acceptance of the v0.10.7 campaign path: preserve the existing campaign, resume it, verify that each incomplete worker dispatches a real successor, and observe the same frozen batch advance until unresolved targets reach zero.

Beyond the hackathon, the roadmap includes:

Better candidate quality

Improve ranking and preflight analysis so Gemini spends more time on issues with:

clear acceptance criteria;
reproducible failures;
available test infrastructure;
bounded change scope;
compatible repository policy;
a high probability of maintainer usefulness.

Broader repository support

Expand safe support for:

more programming languages;
more package managers;
monorepos;
large repositories;
generated-code boundaries;
repository-specific test commands;
contribution-guide interpretation;
language-specific formatting and linting.

Stronger test execution

Add richer isolated test environments and repository-adaptive validation so that more proposals can include direct execution evidence rather than only static checks.

Maintainer-aware learning

Use public, non-sensitive outcomes such as merged, revised, or closed pull requests to improve future ranking and proposal quality without treating a maintainer’s decision as training data that overrides explicit repository policy.

Richer campaign analytics

Track:

time to first useful PR;
time per resolved target;
acceptance-to-publication rate;
rejection categories;
reviewer disagreement;
provider cost per terminal outcome;
maintainer merge rate;
repeated repository failure patterns;
continuation latency;
queue and worker health.

Multi-campaign operation

Support multiple independent campaigns with separate:

GitHub identities;
repository allowlists;
policy profiles;
budgets;
schedules;
service accounts;
evidence ledgers;
completion objectives.

Stronger recovery tools

Add operator-visible recovery controls for replaying only genuinely retryable campaign wide failures while preserving terminal target outcomes and duplicate-publication protection.

Maintainer-facing evidence

Generate concise, transparent pull-request evidence that helps maintainers understand:

why the issue was selected;
what changed;
what was tested;
what the agent could not verify;
which model roles participated;
what authority limits were enforced.

Production hardening

Continue improving:

service-account isolation;
IAM minimization;
queue monitoring;
cost attribution;
audit retention;
incident recovery;
regional configuration;
rate-limit handling;
supply-chain verification;
signed release artifacts.

More useful work, not more unchecked authority

The long-term objective is not to give PARS-Agent permission to merge its own work.

The objective is to make it increasingly capable of producing useful, reviewable contributions while preserving the maintainer’s control.

PARS-Agent should become more autonomous in coordination, recovery, validation, and evidence but remain deliberately limited at the point where another human or organization owns the repository.

The project’s guiding principle remains:

Autonomy should increase the amount of useful work a system can complete not reduce the amount of evidence required to trust it.

Built With

cloud-run-jobs
css3
docker/containers
gemini-3.6-flash
github
github-actions
github-rest-api
google-agent-development-kit
google-artifact-registry
google-cloud
google-cloud-build
google-cloud-iam
google-cloud-logging
google-cloud-pub/sub
google-cloud-run
google-firestore
google-secret-manager
html5
javascript
powershell
python
rest-apis
sha-256
vertex-ai