Protótipo Implantado em Produção
IVE Strategic Execution Agent
A implementação de referência do motor IVE, construída para o All Things Agentic Hackathon 2026. Recebe um objetivo estratégico, carrega contexto real via Supabase, raciocina com Gemini, cria uma ação, verifica sua persistência com uma leitura-após-escrita e registra a decisão em memória de negócio.
Google ADK
FastAPI
Google Cloud Run
Supabase + RLS
JWT (ES256 / JWKS)
Da informação à ação verificada
A maioria das ferramentas de IA responde perguntas. IVE foi construído para ir além: receber um objetivo de negócio, raciocinar sobre o contexto real de um projeto, decidir a ação de maior prioridade, executá-la e provar — não apenas afirmar — que ela foi persistida corretamente.
Do objetivo à ação verificada
Authorization: Bearer <Supabase JWT>
↓
validate_supabase_jwt() → ES256 / JWKS → authenticated_user_id (nunca do corpo da requisição)
↓
get_project_context() → projeto, memórias recentes e ações pendentes reais (RLS)
↓
Gemini raciocina sobre o contexto e identifica o gap estratégico
↓
create_action(…) → insere em action_queue (RLS, id determinístico)
↓
get_action(action_id) → leitura-após-escrita: found=true confirma a persistência
↓
write_agent_memory(…) → decisão verificada → business_memory
↓
RESULT_VERIFIED / AGENT_COMPLETED
Stack técnica
| Camada | Tecnologia |
|---|---|
| Modelo | Gemini 3.5 Flash |
| Orquestração do agente | Google ADK (LlmAgent, Runner, RunConfig) |
| Serviço HTTP | FastAPI — GET /health, POST /run |
| Hospedagem | Google Cloud Run (região europe-west2) |
| Autenticação | JWT do Supabase, validado via JWKS (ES256, sem segredo compartilhado) |
| Dados | Supabase — tabelas projects, action_queue, business_memory, protegidas por Row Level Security |
Gemini + Google ADK + Cloud Run
O agente é definido como um LlmAgent do Google ADK, executado por um Runner com RunConfig(max_llm_calls=10) como limite de iterações. O serviço roda em um container Docker (usuário não-root, porta 8080) implantado no Google Cloud Run.
Uma execução real, ponta a ponta
Evidência de uma chamada real ao serviço implantado — não um mock nem um teste local (o registro completo no Supabase é mostrado acima, na seção anterior):
Requisição
JWT real do Supabase, objetivo em linguagem natural, project_id de um projeto real da InsightValues.
Resultado
HTTP 200 · success: true · verification_status: verified
Ferramentas executadas
get_project_context → create_action → get_action, todas confirmadas com sucesso.
Registro persistido
Linha real em action_queue, rastreável ao execution_id da chamada via o campo sources.
Leitura-após-escrita, não confiança cega
Depois de criar uma ação, o agente é instruído a chamar get_action(action_id) e só reportar sucesso se o registro for encontrado no banco (found: true). A verificação é programática — checa o retorno real da consulta — e não interpretação de texto do modelo.
Decisões que viram contexto
Depois que get_action confirma a persistência, o agente chama write_agent_memory() para registrar a decisão estratégica (o gap identificado, a ação criada e a justificativa) em business_memory. Em execuções futuras, get_project_context() recupera as memórias mais recentes como contexto adicional.
Nota de precisão: a leitura de memórias recentes já é usada em produção; a escrita da memória (write_agent_memory) é correta por revisão de código mas ainda não foi exercitada por um smoke test de produção dedicado.
Identidade e isolamento de dados
JWT, não payload
A identidade do usuário vem exclusivamente do sub do JWT validado — nunca de um campo da requisição que o cliente poderia manipular.
Row Level Security
Todo acesso ao Supabase usa a chave pública + o JWT do próprio usuário — nunca a service_role key. RLS permanece ativo em toda consulta.
Origem fixa
O campo origin de cada ação é sempre "ive_agent", definido pelo runtime — o modelo não pode sobrescrevê-lo.
Sem segredos expostos
Tokens e chaves nunca são logados, retornados na resposta ou versionados no repositório.
O que isto não é
Precisão importa mais que impressionar. IVE não implementa:
- Retry automático ou recuperação autônoma de falhas
- Garantia de exactly-once entre requisições diferentes
- Sessões persistentes do ADK entre chamadas — cada
/runé independente - Aprendizado do agente ao longo do tempo
- Rate limiting por usuário (ainda não implementado)