IVE Strategic Execution Agent

An AI execution agent that turns business context into verified actions using Gemini, Google ADK, Google Cloud, and secure real-world tools.

Comment

Inspiration

What it does

Inspiration

Many AI systems are excellent at generating insights, recommendations, and plans. But there is still a major gap between knowing what should be done and actually executing it.

The IVE Strategic Execution Agent was created to close that gap.

It is an autonomous strategic execution agent that turns real business context into verified, persistent actions, while maintaining user isolation, traceability, and accountability.

The project was developed as a new agentic component designed to integrate with the existing InsightValues ecosystem.

What it does

The IVE Strategic Execution Agent follows a complete execution loop:

Context → Reasoning → Action → Verification

  1. It receives a user goal and a specific project context.
  2. It securely retrieves the authenticated user's real project data.
  3. Gemini reasons about the business context and determines a high-priority action.
  4. The agent executes that action through controlled tools.
  5. It reads the resulting record back from the database.
  6. The execution is marked as verified only after persistence has been confirmed.

This means the agent does more than recommend what a user should do.

It acts — and verifies that the action actually happened.

How we built it

The agent is implemented as a separate Python service using Google ADK and Gemini, deployed on Google Cloud Run.

Its execution architecture combines:

  • Google ADK for agent orchestration
  • Gemini for multi-step reasoning
  • Google Cloud Run for production deployment
  • Supabase for authenticated project context and persistent actions
  • PostgreSQL Row Level Security for user-level data isolation
  • Flutter as the client platform for the broader InsightValues ecosystem

The agent uses controlled tools including:

  • get_project_context
  • create_action
  • get_action
  • write_agent_memory

Authentication is bound to the user's Supabase JWT. The authenticated user identity is derived from the verified token rather than trusted from request data.

Project access is additionally constrained by both application-level filtering and database Row Level Security.

Verified execution

A central design principle is that an LLM response is not considered proof of execution.

After creating an action, the agent calls get_action to retrieve the persisted database record.

Only after successful verification does the execution reach:

RESULT_VERIFIED

This creates an auditable chain:

User Goal → Authenticated Context → Gemini Reasoning → Tool Call → Database Write → Read-Back Verification

During our production smoke test, the deployed Cloud Run agent successfully executed the complete loop against real project data and reached VERIFIED status.

Challenges we ran into

One of the most important challenges appeared only after production deployment.

Cloud Run IAM and the application were initially both using the standard HTTP Authorization: Bearer header for different identity systems.

Cloud Run expected a Google identity token while the application expected a Supabase JWT.

Unit and integration tests using FastAPI TestClient could not reveal this infrastructure-level collision because they bypassed the Cloud Run IAM layer.

We diagnosed the problem in production and redesigned the transport boundary so the public API can be reached while authentication remains enforced by cryptographically verified Supabase JWTs and database RLS.

This was an important lesson: agent security must be validated across the complete production path, not only inside the application.

Accomplishments that we're proud of

We successfully built and deployed a real agentic execution pipeline that:

  • reasons over real business context
  • operates on authenticated user data
  • creates real persistent actions
  • verifies its own execution
  • isolates users through RLS
  • provides execution traceability
  • runs as a production service on Google Cloud

Most importantly, the final production smoke test completed the full sequence:

get_project_context → create_action → get_action → RESULT_VERIFIED

The action generated by the agent was successfully persisted in the production database and associated with the correct project and authenticated user.

What we learned

Building an agent that generates intelligent text is relatively straightforward.

Building an agent that can safely act on real systems and prove what it did is a much harder engineering problem.

We learned that production agentic systems need explicit boundaries between:

  • reasoning
  • identity
  • authorization
  • tool execution
  • persistence
  • verification

We also learned that verification should be treated as a first-class stage of agent execution rather than an assumption after a tool call.

What's next for IVE Strategic Execution Agent

The current implementation proves the core execution architecture.

Next, we plan to expand the agent from individual strategic actions into a broader execution system capable of:

  • decomposing complex goals into multi-step action plans
  • prioritizing actions dynamically
  • maintaining long-term agent memory
  • monitoring execution outcomes
  • reassessing strategies when business conditions change
  • coordinating specialized agents
  • explaining why priorities changed over time

The long-term objective is to evolve IVE from an AI that provides business intelligence into an accountable strategic execution layer:

From insight to impact.

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for IVE Strategic Execution Agent

Built With

Share this project:

Updates

Submission history