-
-
Judge console: one click runs the live Google Cloud pipeline and displays durable proof.
-
Red Tag — an autonomous operations agent that acts once and proves recovery.
-
Architecture: Cloud Run, Pub/Sub, Firestore, Vertex AI, and five Google ADK stages.
Inspiration
Red Tag began with an uncomfortable real measurement: the build machine's system drive had only 19.97 GB free while another drive had 927.86 GB free. Moving data was easy; deciding what an autonomous agent could safely delete was not. Ordinary cleanup tools optimize for bytes removed. An operations agent must also survive retries, worker crashes, and duplicate messages without repeating a destructive action.
What it does
Red Tag is a background operations agent for disk pressure. A real threshold measurement creates an incident without waiting for a chat prompt. Five Google ADK agents normalize the report, investigate evidence, select the smallest reversible plan, submit it to a deterministic safety boundary, and verify closure.
The Windows adapter can delete only files inside a signed managed-cache directory. It records before/after bytes, preserves protected files, rejects unmarked parents, and produces machine-verifiable evidence. Replaying the same delivery is blocked: the ledger still shows exactly one action.
For judges, the public console runs the entire cloud pipeline with one click and no credentials.
How we built it
The public control plane runs on Google Cloud Run. Pub/Sub sends authenticated push messages to a private worker. Google ADK 2.7 orchestrates five specialist stages using Gemini 3.6 Flash on Vertex AI's global endpoint. Firestore stores incidents, evidence, audit events, deliveries, and transactional action claims.
The crucial design choice is that the model proposes, but deterministic code authorizes. A Python safety boundary owns the allowlist, approval rules, target validation, signed markers, and SHA-256 idempotency key. The real Windows adapter and cloud demonstration share that same contract.
Challenges
The hardest problem was separating agent reasoning from execution correctness. LLMs and message systems retry by design, so prompt instructions cannot guarantee exactly-once behavior. We placed a durable action claim between planning and execution, made failed workflows release retryable delivery claims, and required the adapter to return before/after proof.
A second challenge was making a destructive-looking demo safe and judgeable. We used a dedicated synthetic managed cache, fail-closed path checks, a protected file, an unmarked-parent rejection test, and an intentional duplicate replay.
Accomplishments
- Public one-click Google Cloud proof with no credentials or payment.
- Five live Gemini/Google ADK evidence stages.
- Authenticated Cloud Run worker, Firestore audit trail, and Pub/Sub delivery.
- Real Windows cache action: 67,108,864 bytes (64 MiB) verified as freed.
- Protected-file preservation and unmarked-parent rejection.
- Duplicate delivery leaves exactly one action in the durable ledger.
- Nine reliability/API tests plus Ruff static analysis.
- A 2:38 narrated demo built around a live, reproducible proof.
What we learned
Autonomous operations is less about generating a clever plan than making the action boundary boring, inspectable, and impossible to repeat. The strongest architecture lets models retry freely while deterministic code owns permissions, claims, execution, and evidence.
What's next
Next we will add signed remote-device enrollment, OpenTelemetry trace correlation, configurable cache providers, and an approval inbox for targets outside the autonomous allowlist. The same exactly-once boundary can then cover container rollbacks and cloud resource remediation.
Log in or sign up for Devpost to join the conversation.