Inspiration
Contractor readiness information is often spread across documents, training records, inspections, corrective actions, and previous assessments. The challenge is not simply deciding whether a contractor is ready. Safety, Health, Environment and Quality teams also need to understand what changed, why the contractor is in its current state, what action is permitted, who needs to approve consequential work, and whether the resulting state was actually verified.
We wanted to explore a different approach: an AI agent that could take a contractor-readiness goal and move the work forward, while still respecting operational controls.
That led to the core principle behind SiteReady AI:
Controlled autonomy — act when permitted, stop when human judgment is required, and verify the result.
What it does
SiteReady AI is an autonomous contractor-readiness Taskmaster agent for SHEQ teams.
Instead of behaving like a simple chatbot, SiteReady takes a contractor through a complete operational workflow:
ASSESS → COMPARE → EXPLAIN → DECIDE → ACT / APPROVE → VERIFY
The agent can:
- assess contractor readiness using verified SiteReady data
- compare the current assessment with historical state
- explain evidence-backed readiness issues
- determine the permitted execution policy
- execute routine follow-up work autonomously when the policy allows it
- stop consequential work and require explicit human approval
- create or reuse follow-up actions without creating duplicates
- verify the resulting execution state
- record human-attention, notification, and escalation state for auditability
The two demonstration scenarios show the control boundary clearly.
C002 follows the autonomous path: the Taskmaster workflow completes, permitted follow-up processing is performed, and the result is verified.
C003 follows the human-governance path: the contractor is high risk and not ready with five critical issues, so SiteReady stops at a human approval boundary instead of autonomously executing the consequential work.
How we built it
SiteReady AI was built around Google technologies and a deterministic workflow architecture.
The application uses:
- Google ADK for the agent framework
- Gemini 3.5 Flash for reasoning and orchestration
- Google Cloud Run for the production application
- Google Cloud Firestore for persisted workflow state and records
- Python and FastAPI for the application and API layer
The architecture separates reasoning from execution control.
The browser communicates with the FastAPI application. The FastAPI layer invokes the Google ADK agent, which uses Gemini to select the authoritative Taskmaster workflow. The deterministic SiteReady tools then handle execution policy, persistence, approvals, follow-up actions, notifications, and verification.
This separation was intentional. Gemini provides the reasoning and orchestration layer, while the Taskmaster workflow remains authoritative for what the system is actually allowed to execute.
We also built explicit governance into the agent instructions and workflow so that the agent does not invent contractor information, bypass the Taskmaster policy, guess approval IDs, or claim that an action was completed unless the underlying tool actually performed the operation.
Challenges we ran into
One of the biggest challenges was getting an agentic workflow to behave like an operational system rather than a conversational assistant.
We had to make a clear distinction between:
- recommending an action
- requesting human approval
- actually executing an action
- verifying that execution
Production testing also exposed an environment-configuration problem in the Google ADK / Gemini runtime. Cloud Run was healthy, but Taskmaster requests initially failed because the production Google Gen AI client had no API key configured. We traced the failure to the actual runtime exception rather than guessing, then moved the production runtime to the Google Cloud / Vertex AI authentication path.
A second issue was a frontend wrapper around the Taskmaster function. The backend workflow was working, but the browser was failing before the Taskmaster function could execute correctly. We isolated the issue in the browser, removed the faulty wrapper, reran the regression suite, and redeployed.
The final result was verified in production rather than relying only on local tests.
Accomplishments that we're proud of
The biggest accomplishment is that SiteReady AI demonstrates controlled autonomous execution in a real end-to-end workflow.
The project successfully demonstrates both sides of the decision boundary:
C002 — the agent acts.
The Taskmaster workflow completed autonomously and verified the resulting state.
C003 — the agent knows when not to act.
The workflow identified a high-risk contractor with critical issues, stopped at the approval boundary, created the required practitioner attention state, and prepared the follow-up actions without executing them before approval.
We are also proud of the duplicate protection and verification mechanisms. Repeated processing does not blindly create duplicate approval or follow-up records.
The production system was regression tested with 15 automated tests passing, and the production endpoints were verified for both the autonomous and human-approval paths.
What we learned
We learned that building a useful agentic system is not primarily about making the model more conversational. It is about designing clear boundaries around what the model can reason about, what tools are authoritative, what actions are permitted, and where a human must remain in control.
We also learned the importance of separating:
reasoning → policy → execution → verification
That separation made the system easier to test, safer to operate, and easier to explain to a judge or practitioner.
Another important lesson was the value of production evidence. A workflow that works locally is not enough. We had to verify the actual Cloud Run deployment, the production API behaviour, the Google ADK runtime, persistence, approval handling, and verification end to end.
What's next for SiteReady AI
The current project is a hackathon prototype focused on demonstrating the controlled-autonomy workflow.
The next stage would be to evolve SiteReady into a broader operational platform with stronger enterprise integrations and production-grade workflow capabilities.
Potential areas include deeper integration with existing contractor-management and SHEQ systems, richer evidence ingestion, role-based approval workflows, stronger operational analytics, and production notification infrastructure.
The long-term goal is to move from simply identifying contractor-readiness issues to providing a trusted operational layer that helps SHEQ teams continuously investigate, decide, act, stop when necessary, and verify.
Log in or sign up for Devpost to join the conversation.