Inspiration

AI infrastructure is operated against changing power, weather, price, capacity, and workload deadlines. Existing observability tools explain what happened and conventional optimizers react to current utilization. We wanted an operating system that could reason about what is likely to happen next, compare alternatives without letting an LLM invent numbers, and preserve human and OS authority over execution.

What it does

An operator gives FLEX one objective and a set of hard constraints. Sentinel validates the event. Analyst retrieves point-in-time evidence from three Vertex AI Agent Search stores and interprets the operating condition. Optimizer delegates region, schedule, energy, cost, and deadline calculations to deterministic FLEX Quant. Auditor independently recomputes the constraints, checks lineage and Google grounding evidence, and either approves the verified proposal or returns HOLD.

After approval, FLEX OS verifies the exact proposal, scope, lease, resource ceiling, and rollback contract. The judge demo then creates one private ephemeral Google Compute Engine worker, runs an admitted training canary, reads the result back, and deletes the worker. Every stage exposes provider usage, output hashes, citations, losing alternatives, signature state, and the final receipt.

How we built it

We built four isolated model roles with Google ADK SequentialAgent and Gemini 3.7 Flash on Vertex AI. Agents communicate with HYPHA, our typed envelope protocol that fixes the input kind, output kind, sender, receiver, lineage, authority, and hash at every handoff.

The evidence plane uses three Vertex AI Agent Search stores—External Intelligence, FLEX Evidence, and FLEX Operations—followed by the Ranking API, Vertex generateContent, and Check Grounding. The verified provider chain returned a support score of 0.983701. Generated language never calculates a Quant value.

FLEX Quant is a deterministic Rust runtime that compares identical-input policies with checked arithmetic and replayable receipts. FLEX OS independently enforces the admission boundary. Cloud Run hosts the specialist services; Pub/Sub carries ordered typed handoffs; Firestore stores admission state; KMS signs admitted envelopes; Cloud Storage retains evidence; Artifact Registry and Cloud Build pin the runtime image. The proof-of-action canary runs on a private GCE worker with no external IP and forced deletion.

The data foundation preserves immutable NASA POWER, NOAA GFS/GEFS issue-time evidence, and public KPX data as Bronze, then produces deterministic Silver normalization and leakage-safe Gold DecisionTuples across 25 operating regions.

Challenges

The hardest problem was preserving a strict boundary between generated reasoning and numeric decision authority. We rejected designs in which RAG or Gemini could emit cost, energy, or scheduling numbers directly into a proposal. The evidence plane therefore uses the provider-supported Agent Search → Ranking → Vertex GenerateContent → Check Grounding path, while the private Google control plane creates, verifies, and deletes a separate ephemeral training worker.

Accomplishments that we're proud of

  • Four Gemini roles with strict, machine-checked separation of concerns.
  • Three real Agent Search stores, semantic ranking, generated explanation, and claim-level grounding verification.
  • Deterministic Quant isolation: generated text is never a numeric input.
  • 25 geographic regions and 100 real historical Gold decision cases.
  • 100/100 clean workflows and 100/100 registered injected faults handled correctly in the verified scorecard.
  • Seven hard gates with zero unauthorized effects in the measured candidate set.
  • A real private Google Cloud canary that executes CREATE → TRAIN → VERIFY → DELETE and retains a content-addressed receipt.
  • Explicit non-win, HOLD, missingness, revision, and claim-boundary reporting.

What we learned

An enterprise agent is more useful when it can prove why it stopped than when it always returns a confident answer. Retrieval, model reasoning, deterministic optimization, independent verification, and execution admission need different authorities. Google Cloud's search, ranking, generation, grounding, event, identity, and runtime services let us express those boundaries as an operational system rather than a chatbot demo.

What's next

Next steps are customer-authorized scheduler adapters, separate-failure-domain durability, multi-node validation, and real facility telemetry.

Built With

  • agent-search
  • artifact-registry
  • check-grounding
  • cloud-build
  • cloud-kms
  • cloud-run
  • cloud-storage
  • compute-engine
  • firestore
  • flex-os
  • flex-quant
  • gemini-3-7-flash
  • google-adk
  • hypha-protocol
  • kpx
  • nasa-power
  • noaa-gfs-gefs
  • pubsub
  • python
  • ranking-api
  • rust
  • vertex-ai
Share this project:

Updates

Submission history