ReadinessOps Agent Fleet Governance

An evidence-driven governance control plane that detects change, reassesses AI agents, requires human review, and enforces published delegation boundaries at runtime.

Comment

Inspiration

Enterprise AI agents are moving from systems that recommend actions to systems that can perform them.

As that happens, the governance question changes. It is no longer enough to ask whether an agent is capable. Organizations also need to know what the agent is currently allowed to do, and whether the conditions behind that decision are still valid.

An agent may change after approval. Its identity, permissions, tools, instructions, model configuration, evidence, or validation requirements may change over time.

For that reason, we did not want ReadinessOps to treat governance as a one-time assessment.

We built ReadinessOps Agent Fleet Governance to manage AI delegation as an ongoing process based on current evidence, human decisions, and runtime controls.

The basic approach is that AI can analyze and propose, people make governance decisions, and those decisions must be explicitly reflected in the controls that determine whether an agent can act.

What it does

ReadinessOps is a governance control plane for enterprise AI agent fleets.

When new evidence is introduced, the system identifies which agent may be affected and reassesses whether its current Delegation Boundary is still valid.

The implemented flow is:

Evidence → Impact Analysis → Reassessment → Governance Proposal → Human Review → Publication → Runtime Enforcement → Trace

New evidence is uploaded to Cloud Storage and triggers Pub/Sub. An authenticated private Cloud Run worker receives the event, and Model Armor checks the evidence before it enters the agent workflow.

The system identifies the affected agent revision and uses specialized agents to reassess runtime, governance, value, and routing implications.

If the change is material, the affected agent can move from READY to SUSPENDED.

The system then prepares grounded decision material for human review. AI-generated proposals remain in REVIEW_REQUIRED until a person reviews them.

Human approval does not immediately change execution authority.

ReadinessOps separates Approval from Publication. Approval records the human decision. Publication makes the reviewed Delegation Boundary effective for runtime enforcement.

Only after the required publication step can the agent return to READY.

Before a protected action is executed, a deterministic action gate checks the currently published Delegation Boundary.

The analysis environment cannot perform the protected action using its own identity. A separate Executor Identity is allowed to proceed only when the published boundary permits it.

The full path from evidence change through reassessment, human review, publication, authorization, and execution is retained as an auditable trace.

How we built it

ReadinessOps is implemented on Google Cloud using Gemini 3.5 Flash on Vertex AI and Google Agent Development Kit.

The current implementation also uses Vertex AI agent runtime capabilities, Agent Identity, Agent Gateway, Agent Registry and A2A Agent Cards, Model Armor, Cloud Run, Pub/Sub, Cloud Storage, Firestore, Cloud Build, Artifact Registry, Cloud Logging, and Python.

Responsibilities are divided across specialized agents rather than assigned to one unrestricted agent.

The fleet includes roles for Evidence Impact, Governance, Value and Portfolio, Model Routing, Governance Orchestration, and Action Execution.

The Governance Orchestrator coordinates reassessment and prepares decision material, but it cannot approve, publish, or execute protected actions.

Firestore stores the governance state used by the current implementation.

Cloud Run provides separate runtime components, while Google Cloud IAM and separate service identities are used to separate analysis from protected execution.

The governance and analysis plane uses an Analysis Identity. Protected actions use a separate Executor Identity and runtime.

This means that an agent can conclude that an action should occur without automatically receiving permission to perform that action.

We also separated AI-based interpretation from deterministic controls.

AI agents are used to interpret evidence and prepare proposals. Critical state transitions and execution authorization are handled by deterministic checks.

Decision material is grounded against available evidence before human review, and protected execution is checked against the published governance state rather than against a natural-language recommendation from an agent.

Challenges we ran into

The main challenge was not connecting Gemini to the application. It was deciding where agent autonomy should stop.

We had to work through several questions during implementation.

Should an agent that detects a material change also be allowed to determine whether execution should continue?

Should a human approval immediately change production execution authority?

Should the same identity that performs analysis also be able to execute protected actions?

What should happen when new evidence changes the assumptions behind a previously approved agent?

Which parts of the process can depend on probabilistic model output, and which parts need deterministic controls?

These questions led us to separate analysis, approval, publication, authorization, and execution.

Another challenge was making a multi-agent governance process understandable and auditable.

Detecting a change and suspending an agent is not enough for an operational system. The system also needs to show why the agent was stopped, what needs to be reviewed, what decision was made, and what must happen before execution can resume.

This led to the lifecycle used in the current implementation:

READY → SUSPENDED → Reassessment → Human Review → Publication → READY

Accomplishments that we're proud of

We implemented and verified an end-to-end governance and execution path rather than stopping at an AI-generated recommendation.

The current flow covers evidence change, automated impact detection, agent suspension, multi-agent reassessment, grounded governance proposals, human review, explicit publication, reactivation, runtime authorization, identity-isolated execution, and end-to-end traceability.

One result we wanted to verify was whether the same protected action would be treated differently depending on the identity attempting to perform it.

In the implemented flow, the Analysis Identity is denied access to the protected action.

The authorized Executor Identity can be permitted and can execute the same action when the published Delegation Boundary allows it.

This connects the Delegation Boundary to actual runtime authorization rather than leaving it as documentation.

We also implemented the distinction between approval and publication.

A reviewer can approve a proposed governance change without that action immediately changing current execution authority. The reviewed decision must be explicitly published before it affects runtime enforcement.

What we learned

The project changed how we think about enterprise use of AI agents.

Model capability alone does not determine whether an organization should delegate work to an agent.

Organizations also need to be able to define the scope of that delegation, observe when its assumptions change, revoke it when necessary, and restore it under clear conditions.

We also learned that governance cannot end when an approval decision is recorded.

If an AI agent can perform real actions, the approved decision needs to remain connected to the controls that determine what the agent can do in operation.

That makes governance an ongoing operational process: detect what changed, determine whether the current delegation still applies, stop execution when necessary, involve a person where required, update the applicable boundary, and enforce that boundary when the agent acts.

The project also reinforced that agent systems share many concerns with other distributed systems.

Identity separation, event-driven processing, deterministic authorization, observability, traceability, and explicit state transitions become increasingly important as agents are given more responsibility.

These controls are not intended to prevent greater use of AI agents. Their purpose is to make greater delegation possible while keeping clear control over when an agent can act, when it must stop, and what is required before it can resume.

What's next for ReadinessOps Agent Fleet Governance

The hackathon implementation focuses on demonstrating the governance and execution control loop using synthetic evidence and without production PII.

The next step is to extend the same architecture toward enterprise operating environments.

Areas for further development include richer evidence ingestion, PDF and structured document processing, enterprise system connectors, broader agent inventory and registry integration, continuous reassessment policies, portfolio-level governance, private enterprise evaluations, and operational measures such as review time, exception rate, accuracy, and cost per outcome.

We also want to make Delegation Boundaries easier to manage across larger agent fleets.

The goal is to help organizations understand not only whether an individual agent is operating correctly, but also where authority has been delegated across the organization, what evidence supports that delegation, and how the authority changes over time.

The longer-term objective is to make it easier for organizations to answer practical questions about AI agents: what an agent may do, why it is allowed to do it, who approved the decision, what has changed since that decision, when the agent should stop, and what needs to happen before it can resume.

ReadinessOps is intended to make those decisions part of the operating system around enterprise AI agents rather than leaving them only in policies or review documents.

Built With

  • artifact-registry
  • cloud-build
  • cloud-run
  • cloud-storage
  • firestore
  • gemini
  • google-adk
  • google-cloud
  • google-cloud-iam
  • model-armor
  • pub-sub
  • python
  • vertex-ai
Share this project:

Updates

Submission history